Path.Area: Welcome, to the new era!

Here's the place for discussion related to CAM/CNC and the development of the Path module.
User avatar
sliptonic
Posts: 1549
Joined: Tue Oct 25, 2011 10:46 pm

Re: Path.Area: Welcome, to the new era!

Postby sliptonic » Sun Apr 23, 2017 3:29 pm

realthunder wrote:
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.
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.
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.

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.
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.
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.
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.)
realthunder
Posts: 1018
Joined: Tue Jan 03, 2017 10:55 am

Re: Path.Area: Welcome, to the new era!

Postby realthunder » Sun Apr 23, 2017 4:26 pm

sliptonic wrote: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
So how about this, I'll set verbose=false as default, and remove all default preambles, such as G91.1 and G17 stuff, and only add those settings when they are not default.
sliptonic wrote: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.)
The current 'retraction' parameter can be consider as 'safe height', however the 'clearance' is not correct. The question is, how can one determine which 'height' to retract to? Do other CAMs generate different retraction height? The only way I can think of is to perform intersection operation on each horizontal rapid move path and use safe height for any intersection encountered. Hmm...I just remembered that I actually thought of implementing that some time back, and forgot about it somehow until now.
Try Assembly3 (latest version 0.10.2) along with my custom build of FreeCAD at here.
And if you'd like to show your support, you can donate through patreon, liberapay, or paypal
User avatar
sliptonic
Posts: 1549
Joined: Tue Oct 25, 2011 10:46 pm

Re: Path.Area: Welcome, to the new era!

Postby sliptonic » Sun Apr 23, 2017 6:44 pm

realthunder wrote:
sliptonic wrote: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
So how about this, I'll set verbose=false as default, and remove all default preambles, such as G91.1 and G17 stuff, and only add those settings when they are not default.
Are you still suggesting that verbose implies absolute arc centers and non-verbose implies relative centers? I think I would turn on verbose mode in order to better understand what's happening. If that causes different code to be generated, it'll be confusing.

The default mode (whether verbose or not) should create relative center arcs and the viewprovider should render them correctly without any additional gcodes in the path.

If a separate 'absoluteArcCenters=True' parameter is added, it should also include the G91.1 command.

sliptonic wrote: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.)
The current 'retraction' parameter can be consider as 'safe height', however the 'clearance' is not correct. The question is, how can one determine which 'height' to retract to? Do other CAMs generate different retraction height? The only way I can think of is to perform intersection operation on each horizontal rapid move path and use safe height for any intersection encountered. Hmm...I just remembered that I actually thought of implementing that some time back, and forgot about it somehow until now.
In most of the operations I've coded, I use clearance height and the beginning and ending to get the cutter into position and move it out. Otherwise, I'm using Safe height. In operations that work on panel sheets that might have multiple solids referenced. All moves within a Panel would be at safe height. All moves between panels would be at clearance height.
The only exception is drilling. Drilling cycles distinguish between the height that the drill moves from location to location and the height that it retracts to between peck cycles.
realthunder
Posts: 1018
Joined: Tue Jan 03, 2017 10:55 am

Re: Path.Area: Welcome, to the new era!

Postby realthunder » Sun Apr 23, 2017 7:10 pm

sliptonic wrote:The default mode (whether verbose or not) should create relative center arcs and the viewprovider should render them correctly without any additional gcodes in the path.

If a separate 'absoluteArcCenters=True' parameter is added, it should also include the G91.1 command.
Sounds good, I'll do just that. Verbose is still the default, but will generate relative arc center unless 'absolute_arc_center' is true, something like that.
sliptonic wrote:In most of the operations I've coded, I use clearance height and the beginning and ending to get the cutter into position and move it out. Otherwise, I'm using Safe height. In operations that work on panel sheets that might have multiple solids referenced. All moves within a Panel would be at safe height. All moves between panels would be at clearance height.
The only exception is drilling. Drilling cycles distinguish between the height that the drill moves from location to location and the height that it retracts to between peck cycles.
[/quote][/quote]I need to think about this first.
Try Assembly3 (latest version 0.10.2) along with my custom build of FreeCAD at here.
And if you'd like to show your support, you can donate through patreon, liberapay, or paypal
User avatar
sliptonic
Posts: 1549
Joined: Tue Oct 25, 2011 10:46 pm

Re: Path.Area: Welcome, to the new era!

Postby sliptonic » Sun Apr 23, 2017 7:49 pm

realthunder wrote:I need to think about this first.
o.k. cool. Feel free to catch me on IRC or PM if you want to discuss. I don't think there's much (or maybe anything) you need to worry about at this point. I might be able to handle all the clearance moves in the python code.
User avatar
sliptonic
Posts: 1549
Joined: Tue Oct 25, 2011 10:46 pm

Re: Path.Area: Welcome, to the new era!

Postby sliptonic » Mon May 01, 2017 11:55 pm

@realthunder,

Is something broken in the pocketing mode? I'm just getting back to things again and I can't get any pocket operations to produce output. Even the sample code from page 1 of this thread fails to produce output. There's no error in the console and fromShape() returns a path but it only contains a G90 and G17.
User avatar
sliptonic
Posts: 1549
Joined: Tue Oct 25, 2011 10:46 pm

Re: Path.Area: Welcome, to the new era!

Postby sliptonic » Tue May 02, 2017 5:35 am

I made some pretty good progress today and uncovered a couple more bugs. Let me know if you'd like me to start dumping these into Mantis for tracking.

First, If I set both retraction and clearance as parameters for fromShapes(), The initial move is correct as seen below:
snapshot.png
snapshot.png (16.73 KiB) Viewed 698 times
However, if a startpoint vector is given, the initial rapid to clearance height doesn't happen. Instead, it to the clearance height over the start point. This would be a crash.
snapshot-1.png
snapshot-1.png (16.66 KiB) Viewed 698 times
Next, the results of setting the orientation parameter appear to be reversed. ie, orientation == 1 gives me a CCW path even though documentation says 1 should be CW. However, There's more going on here. The above path is created from ten 'slices' passed in as a list of shapes. The first 9 slices have the resulting path reversed in orientation but the last one is correct.
realthunder
Posts: 1018
Joined: Tue Jan 03, 2017 10:55 am

Re: Path.Area: Welcome, to the new era!

Postby realthunder » Tue May 02, 2017 6:25 am

sliptonic wrote:I made some pretty good progress today and uncovered a couple more bugs. Let me know if you'd like me to start dumping these into Mantis for tracking
I am working on a big feature of FC, and is about to finish it. I'll take a look at the bugs later, maybe in a day or two. If they can be fixed quickly, then no need to fire the ticket. I'll let you know.
Try Assembly3 (latest version 0.10.2) along with my custom build of FreeCAD at here.
And if you'd like to show your support, you can donate through patreon, liberapay, or paypal
User avatar
sliptonic
Posts: 1549
Joined: Tue Oct 25, 2011 10:46 pm

Re: Path.Area: Welcome, to the new era!

Postby sliptonic » Tue May 02, 2017 7:30 pm

Another thing I'd like your input on:
Now I can do SectionCount = -1 to get all the sections as controlled by the Stepdown parameter. Or I can do SectionCount = 1 and a SectionOffset to control the height of the section. What I really want is more control of where the sections are taken. I'd like to pass in a list of offsets and get sections back at all of them. Could SectionOffset be a list?
realthunder
Posts: 1018
Joined: Tue Jan 03, 2017 10:55 am

Re: Path.Area: Welcome, to the new era!

Postby realthunder » Tue May 02, 2017 7:39 pm

sliptonic wrote:Another thing I'd like your input on:
Now I can do SectionCount = -1 to get all the sections as controlled by the Stepdown parameter. Or I can do SectionCount = 1 and a SectionOffset to control the height of the section. What I really want is more control of where the sections are taken. I'd like to pass in a list of offsets and get sections back at all of them. Could SectionOffset be a list?
You can do it using script. Path.Area(...).makeSections(heights=[...]). Checkout the python docstring for help. I thought you've called that method before? And in case you've missed my previous post. Please also try calling makeSections(project=True ...) to see if it can replace TechDraw.findShapeOutline. It is a complex operation, and I am expecting some problems here.
Try Assembly3 (latest version 0.10.2) along with my custom build of FreeCAD at here.
And if you'd like to show your support, you can donate through patreon, liberapay, or paypal