HoldingTags Dressup ignores feedrates

Here's the place for discussion related to CAM/CNC and the development of the Path module.
GeneFC
Posts: 67
Joined: Sat Mar 19, 2016 3:36 pm
Location: Punta Gorda, FL

Re: HoldingTags Dressup ignores feedrates

Postby GeneFC » Fri Feb 03, 2017 3:33 pm

I use LinuxCNC almost daily. As ChrisB says, the feed rate is modal. LinuxCNC complains only if there is no feed rate at all before it is required for an operation. At the same time, LinuxCNC can accept a feed rate in every line. (Only one per line, not more.)

The history of G-Code goes back more than 60 years, when memory was very limited and expensive. Shortcuts leaving out every possible repetitive byte, such as the "X" or "Y", or the "F", were considered clever and good practice. (I coded in raw machine op-codes back in the 1970's. The space-saving tricks we used would get someone fired today.)

Today those shortcuts offer no practical benefit and make the final code very difficult for humans to read.

Personally, I prefer to always keep the full number of decimal places, all of the axis labels for moves, and lots of feed rates, even if those are redundant and unnecessary.

Gene
chrisb
Posts: 1668
Joined: Tue Mar 17, 2015 9:14 am

Re: HoldingTags Dressup ignores feedrates

Postby chrisb » Fri Feb 03, 2017 7:37 pm

GeneFC wrote:Today those shortcuts offer no practical benefit and make the final code very difficult for humans to read.
For an end user it seems to be a matter of taste (and probably usage). While I can understand Gene's view I like to have only the essentials and I like to see only what changes.
The end user sees only the output of the post processor and since we can switch there in either way I don't see any problem from that end.
From a systematic view this might be different but I cannot really see such an important design issue that I can vote reliably for one side. So I rely with a wonderful clear conscience that the developers will make a good decision.
mlampert
Posts: 288
Joined: Fri Sep 16, 2016 9:28 pm

Re: HoldingTags Dressup ignores feedrates

Postby mlampert » Fri Feb 03, 2017 8:28 pm

I think you guys are talking about the post processor output here. There is a setting in the linuxcnc processor about only outputting changed parameters or all parameters with each g-code command.

The question at hand is the internal representation of Path.Command - and I think I have to retract my request. Upon further thinking about it I don't think It is possible with the current Path.Command structure to make it a full command. A Path.Command as it is today cannot stand on its own and always has to be viewed in the context of all its predecessors. Any of the previous commands could have changed the reference plane, absolute/relative positioning, or rotated one of the planes around one of the axis.

In other words, unless we entirely change Path.Command to something different - the only parameters required and necessary within a Path.Command are those that change. From that perspective my previous assumption on the implementation of the dressups was correct.

As sliptonic pointed out, what ends up in the output g-code is the responsibility of the post processor. And as it can remove unchanged parameters from the output it can also insert them. There should be no loss in personalising the output as it is today.
VVilhelnn
Posts: 1
Joined: Thu Feb 09, 2017 1:58 am

Re: HoldingTags Dressup ignores feedrates

Postby VVilhelnn » Thu Feb 09, 2017 2:22 am

Hi Guys,

I have too been hit by this issue, looking at the code; I can see that there is a fundamental issue with the assumption of who is doing what... In PathCountour.py and in PathProfile.py object "PathKurveUtils" is used this object creates its own gcode taking into acocunt feed rate.

HoldingTags Dressup code seems to take the path information (WIRE) basically discarding any previous gcode which includes feedrate information. Then it creates a new wire and process it taking into account holding tags. Finally passing the new edge segments to object PathGeom to create the gcode in ObjectDressup.createPath with a call like

Code: Select all

commands.extend(PathGeom.cmdsForEdge(edge, segm=segm))


All seems fine and a good approach BUT BUT... PathGeom.cmdsForEdge doesn't have any code to deal with feed rates at all. Question Is the future to move away from PathKurveUtils and add feedrate knowledge to PathGeom? or should PartDressupHoldingTags start using PathKurveUtils?? As of now the postprocessor doesn't' seem to be involved in adding feed rate. Also if I don't use any post processor at all does this mean that I loose feed rate information (why?)

am I in the right path here? no pun intended...
sliptonic
Posts: 597
Joined: Tue Oct 25, 2011 10:46 pm

Re: HoldingTags Dressup ignores feedrates

Postby sliptonic » Thu Feb 09, 2017 3:21 pm

VVilhelnn wrote:Hi Guys,

I have too been hit by this issue, looking at the code; I can see that there is a fundamental issue with the assumption of who is doing what... In PathCountour.py and in PathProfile.py object "PathKurveUtils" is used this object creates its own gcode taking into acocunt feed rate.

For clarity, please don't call this 'gcode' At this point in the process, we're talking about Path Commands. You're correct that Contour, Profile, etc use PathKurveUtils to derive this but it is used to build a Path of Commands. The Path will eventually be processed by a post-processor to get gcode but PathKurveUtils will not be involved at that point.

HoldingTags Dressup code seems to take the path information (WIRE) basically discarding any previous gcode which includes feedrate information. Then it creates a new wire and process it taking into account holding tags. Finally passing the new edge segments to object PathGeom to create the gcode in ObjectDressup.createPath with a call like

Code: Select all

commands.extend(PathGeom.cmdsForEdge(edge, segm=segm))


All seems fine and a good approach BUT BUT... PathGeom.cmdsForEdge doesn't have any code to deal with feed rates at all. Question Is the future to move away from PathKurveUtils and add feedrate knowledge to PathGeom? or should PartDressupHoldingTags start using PathKurveUtils?? As of now the postprocessor doesn't' seem to be involved in adding feed rate. Also if I don't use any post processor at all does this mean that I loose feed rate information (why?)

am I in the right path here? no pun intended...


Yep, I think this is essentially correct. The only false assumption I see is equating the Path Commands with gcode. I guess that's why you're thinking about not using a post processor. That would be a mistake. Your post could be very simple, like dumper, but I think it's important to build a workflow that makes a clear distinction between the two. While the Path Commands and gcode are very similar now, that might change. For example, we're already talking about including the velocity information with every command.

As for PathGeom and PathKurveUtils, I can't really say what should happen in the future. There's a lot of things in the PathKurveUtils code that I don't like (global imports for one) so I'd like to see us move away from that older Heeks code toward a cleaner implementation. On the other hand, it's been pretty useful and reliable so far.