HoldingTags Dressup ignores feedrates

Here's the place for discussion related to CAM/CNC and the development of the Path module.
roivai
Posts: 5
Joined: Thu Feb 02, 2017 5:29 pm
Location: Oulu, Finland

HoldingTags Dressup ignores feedrates

Postby roivai » Thu Feb 02, 2017 6:06 pm

Hello,

This is my first post here. I've been following the Path development for a while now and I want to thank everyone involved. I find this workbench already usable with my simple milling tasks! I updated to the latest git master yesterday (last one was from month ago or something) and noticed that the old holding tags options were gone from the profile and it was replaced by the new dressup. The dressup was nice, the automatic generation worked nicely. However, when I post processed the dressup, I noticed that feedrates set by the tool controller were ignored. I'm using linuxcnc post processor. Is there something I missed from settings or is this some sorta bug? BTW, I tried registering to Freecad bug tracker, but failed to see the visual captcha image. Again am I doing something wrong or is there issues with the tracker? I see it issues some PHP warning about timezone..

Thanks for help,
Pekka

Original gcode from Profile:

Code: Select all

(Profile001 :TC001)
(Compensated Tool Path. Diameter: 6.5)
G0 F0.000000 Z13.000000
G00 X4.700000 Y16.300000
G00 Z18.000000
G01 F200.000000 X4.700000 Y16.300000 Z5.500000
G01 F400.000000 X4.700000 Y-8.449000 Z5.500000
G03 F400.000000 I3.249000 J0.000000 X7.949000 Y-11.699000 Z5.500000
...


Gcode from Dressup:

Code: Select all

G0 X0.000000 Y0.000000 Z13.000000
G0 X4.700000 Y16.300000 Z13.000000
G0 X4.700000 Y16.300000 Z18.000000
G1 X4.700000 Y16.300000 Z5.500000
G1 X4.700000 Y-8.449000 Z5.500000
G3 I3.250708 J0.000708 K0.000000 X7.949000 Y-11.699000 Z5.500000
...


OS: Debian GNU/Linux 8.6 (jessie)
Word size of OS: 64-bit
Word size of FreeCAD: 64-bit
Version: 0.17.9933 (Git)
Build type: Unknown
Branch: master
Hash: 6c3b78e97bbb8653e1189038c99682becef71626
Python version: 2.7.9
Qt version: 4.8.6
Coin version: 4.0.0a
OCC version: 6.7.0
mlampert
Posts: 292
Joined: Fri Sep 16, 2016 9:28 pm

Re: HoldingTags Dressup ignores feedrates

Postby mlampert » Thu Feb 02, 2017 7:10 pm

This is really interesting. The operations, including the dressups, have no notion of the feed rate, it comes from TC. There is the current issue where you have to set the feed rate first for them to take effect, or recompute the operations.
Did you try marking the ops for recompute and recompute the document? Does it change anything?

If not, would you be able to post your file?
roivai
Posts: 5
Joined: Thu Feb 02, 2017 5:29 pm
Location: Oulu, Finland

Re: HoldingTags Dressup ignores feedrates

Postby roivai » Thu Feb 02, 2017 8:12 pm

Thanks for your reply.

I tried to recompute everything, but did not help. I am able to reproduce this with a very simple box having a profile around it. I is attached.

tagstest.fcstd
(12.49 KiB) Downloaded 8 times


By looking at the Profile itself by "Inspect G-code" I see following:

Code: Select all

(Profile :TC)
(Compensated Tool Path. Diameter: 5.0)
G0 F0.000000 Z15.000000
G00 X102.500000 Y0.000000
G00 Z23.000000
G01 F200.000000 X102.500000 Y0.000000 Z0.000000
G01 F400.000000 X102.500000 Y50.000000 Z0.000000
G03 F400.000000 I-2.500000 J0.000000 X100.000000 Y52.500000 Z0.000000
G01 F400.000000 X0.000000 Y52.500000 Z0.000000
G03 F400.000000 I0.000000 J-2.500000 X-2.500000 Y50.000000 Z0.000000
G01 F400.000000 X-2.500000 Y0.000000 Z0.000000
G03 F400.000000 I2.500000 J0.000000 X0.000000 Y-2.500000 Z0.000000
G01 F400.000000 X100.000000 Y-2.500000 Z0.000000
G03 F400.000000 I0.000000 J2.500000 X102.500000 Y0.000000 Z0.000000
G00 Z15.000000


By inspecting the dressup, I see:

Code: Select all

G0 X0.000000 Y0.000000 Z15.000000
G0 X102.500000 Y0.000000 Z15.000000
G0 X102.500000 Y0.000000 Z23.000000
G1 X102.500000 Y0.000000 Z0.000000
G1 X102.500000 Y50.000000 Z0.000000
G3 I-2.500000 J0.000000 K0.000000 X100.000000 Y52.500000 Z0.000000
G1 X82.450000 Y52.500000 Z0.000000
G1 X77.450000 Y52.500000 Z5.000000
G1 X72.550000 Y52.500000 Z5.000000
G1 X67.550000 Y52.500000 Z0.000000
G1 X32.450000 Y52.500000 Z0.000000
G1 X27.450000 Y52.500000 Z5.000000
G1 X22.550000 Y52.500000 Z5.000000
G1 X17.550000 Y52.500000 Z-0.000000
G1 X0.000000 Y52.500000 Z0.000000
G3 I0.000000 J-2.500000 K0.000000 X-2.500000 Y50.000000 Z0.000000
G1 X-2.500000 Y0.000000 Z0.000000
G3 I2.500000 J0.000000 K0.000000 X0.000000 Y-2.500000 Z0.000000
G1 X17.550000 Y-2.500000 Z0.000000
G1 X22.550000 Y-2.500000 Z5.000000
G1 X27.450000 Y-2.500000 Z5.000000
G1 X32.450000 Y-2.500000 Z-0.000000
G1 X67.550000 Y-2.500000 Z0.000000
G1 X72.550000 Y-2.500000 Z5.000000
G1 X77.450000 Y-2.500000 Z5.000000
G1 X82.450000 Y-2.500000 Z0.000000
G1 X100.000000 Y-2.500000 Z0.000000
G3 I0.000000 J2.500000 K0.000000 X102.500000 Y0.000000 Z0.000000
G0 X102.500000 Y0.000000 Z15.000000
mlampert
Posts: 292
Joined: Fri Sep 16, 2016 9:28 pm

Re: HoldingTags Dressup ignores feedrates

Postby mlampert » Thu Feb 02, 2017 9:58 pm

most peculiar - you are entirely correcct. It seems the F parameters are embedded in each Path.Command. I misunderstood that when I wrote the holding tags. I thought the post processor extracts the feed rates and speed from the TC, but it doesn't.

This also explains the behaviour discussed in https://forum.freecadweb.org/viewtopic.php?f=15&t=20282

I'll file a bug, thanks for reporting!
chrisb
Posts: 1838
Joined: Tue Mar 17, 2015 9:14 am

Re: HoldingTags Dressup ignores feedrates

Postby chrisb » Thu Feb 02, 2017 10:23 pm

I would like to see it the way you assumed, namely that the tool controller issues one F command. If a machine needs it, the post processor can take care of it. That is much clearer in terms of relationship between Job's elements and GCode.
My post processor takes care of it by eliminating the repeated F elements but that seems to be a repair at the wrong end.
sliptonic
Posts: 621
Joined: Tue Oct 25, 2011 10:46 pm

Re: HoldingTags Dressup ignores feedrates

Postby sliptonic » Thu Feb 02, 2017 11:21 pm

I prefer explicit vs implicit.

With the F parameter on every command, it's explicit. You KNOW the feed rate for an individual command is. Without it, the feed rate is only implied based on previous commands.

Likewise, we could make the same argument that XYZ parameters should only be included in the command if they've changed from the previous command. That's very 'gcode' but it makes writing dressups a lot harder because you have to reconstruct the context of a command from what came before.

Remember, the commands are not the gcode. Gcode is what comes out of a post-processor. The commands are just our internal representation of the path and only resemble gcode incidentally.
chrisb
Posts: 1838
Joined: Tue Mar 17, 2015 9:14 am

Re: HoldingTags Dressup ignores feedrates

Postby chrisb » Thu Feb 02, 2017 11:49 pm

Accepted! The argument that we can see the state at every position of the job got me.
I am usually thinking in terms of machining: switch the spindle off, change the tool, set the gears and switch it on. And it holds the speed until I change it again.
mlampert
Posts: 292
Joined: Fri Sep 16, 2016 9:28 pm

Re: HoldingTags Dressup ignores feedrates

Postby mlampert » Thu Feb 02, 2017 11:53 pm

From a dressup perspective you have to track the previous command anyway, at least from personal experience I can't say there's a benefit either way.

Not having the feed rate in each Path.Command probably means less work - having to add the Feed rate into each command means we need Feed rate logic in each operation we implement. Holding tags for instance creates some potentially quite elaborate moves in all 6 directions - which feed rate to apply? On a 45 degree descent, is it the horizontal or the vertical, the bigger one or the smaller one, average, square root ....

Having some form of centralized feed rate assigner would simplify all those because they only have to get implemented once. The post processor could still add the sticky feed rate into each g-code.

However, currently a Path is a complete object. Meaning I can take a Path object, or the output from it and copy it with a text editor into some other context/environment and it will stay valid (assuming the same tool is being used). Taking the feed rate out of each Path.Command introduces a bigger dependency on its context (albeit a not very big one).

To be honest I can argue either way and it doesn't really matter, what matters is how the system behaves, not its internal representation.

There is one thing though - if we decide to keep the feed rate with each command (and deal with the dynamics in a different way), I want Path.Command to become a strictly defined class. No more optional and arbitrary parameters, each Path.Command has a well defined set of parameters and they will all be explicitly set with numerical values (otherwise I'm gonna start sticking None in there again ;) ). Deal?
herbk
Posts: 351
Joined: Mon Nov 03, 2014 3:45 pm
Location: Windsbach, Bavarya (Germany)

Re: HoldingTags Dressup ignores feedrates

Postby herbk » Fri Feb 03, 2017 7:29 am

Hi Chris,
And it holds the speed until I change it again.
Wich machine controler you use?
It's not on each machinecontroler like that, e.g. LinuxCNC wants the F in each line. I'm not 100% sure (because I have not tested it explicitly), but i remember a time where FreeCAD produces a gcode with only one F argument at the beginning off the gcode and LinuxCNC gives me an error message "missing speed rate".
Gruß Herbert
chrisb
Posts: 1838
Joined: Tue Mar 17, 2015 9:14 am

Re: HoldingTags Dressup ignores feedrates

Postby chrisb » Fri Feb 03, 2017 11:35 am

herbk wrote:Wich machine controler you use?

It's a Philips control (good old stuff which will be replaced sone day with a linux cnc). As far as I know it is like that with Heidenhain, Sinumeric and (probably) Fanuc as well. The GCode description which I have says the same. There is the distinction between "modal" commands and "non modal", meaning that the modal stays set until it is changed explicitely. The speed can be set together with a G1 or some other command, but it doesn't have to be repeated every time.