I understand the value in having absolute centers available for debugging but it has caused me some trouble. It seems that verbose=True is the default condition but this runs counter to our implicit assumptions where we expect IJK to be relative. You're right that if the user wants absolute centers, it should be handled in the post processor. Commands at this level are not gcode so we don't have to support all variations. For that reason, If you're going to generate absolute centers as an option, I'd like to see it enabled as a separate flag instead of bound to the verbose mode.realthunder wrote:Those preambles are not just default values. Depending on the parameters and shapes passed in, it may use other configurations. For example, when you turn off verbose, it will use relative arc center mode (G91.1). The advantage of using absolute coordinate is easy to debug in 3D view. G17, 18, 19 depends on the 'arc_plane' setting. The default being auto means fromShapes will detect which arc plane to use. All in all, if the user want the final gcode to be in center format, won't there be some post processor to handle this? And if so, I think it is better to be explicit about the what modes is being used to avoid confusions to the postprocessor. In fact, if those preambles aren't there, ViewProviderPath won't show the path correctly.sliptonic wrote:Path.fromShapes() seems to be inserting some preamble commands (Command G90 [ ], Command G90.1 [ ], Command G17 [ ]) at the beginning. I don't think it should do this. The pre-amble stuff will all be output by the job itself.
When I set verbose=False, I got correct code but the G91.1 that was added caused its own problems. The Grbl/smoothie motion controller doesn't handle that gcode and always assumes relative centers. So G91.1 is interpreted as G91. This means ALL movement is interpreted as incremental.
Obviously the smoothie post-processor can (and should) be modified to handle or suppress these commands correctly.
FWIW, Operations have both a 'safe height' and a 'clearance height'. Safe height is the generally (at least) the top of the the material. Clearance height is the lowest height needed to avoid colliding with any other obstruction on the machine (vise, clamps, etc.)You can specify the start position, both in Path.fromShapes(), and ViewProviderPath. And if you specify 'retraction' and 'clearance' parameters in fromShapes, you will get the move up, then horizontal and then down path. Although, I think my understanding of 'clearance' maybe wrong here. Please try it and let me know.sliptonic wrote:Path.fromShapes() begins by doing a rapid move to the first position. This is bad since you don't know what the previous position was so you don't know what's in the way.
The path should start by doing a G0 to the clearance height. then a G0 to the first position (XY at clearance height) Then a G1 to the first position at vertical feed.