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
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.