Path.Area: Welcome, to the new era!

Here's the place for discussion related to CAM/CNC and the development of the Path module.
Forum rules
Be nice to others! Respect the FreeCAD code of conduct!
realthunder
Veteran
Posts: 2190
Joined: Tue Jan 03, 2017 10:55 am

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

Post by realthunder »

ian.rees wrote:Sorry, I don't mean to nit pick. I'm just not understanding a situation where a vector wouldn't specify a unique direction, but a map from magic numbers to directions would (and I don't like C style enums creating meaning :)).

A more Pythonic solution to the algorithm only handling vectors that are "on axis" is to accept a vector (perhaps of 3 ints), but throw if it's not in a direction that the algorithm can handle. That way, if someone extends the algorithm later to accept a wider range of directions, the interface doesn't need to change.
Well, I like to be more extendable as well. It's just that I failed to imagine the possibility of any direction control other than those axial ones. But I may be wrong here, and I'll be happy to change it if someone can hint any possible use case.
ian.rees wrote:Where would it be more work to use the "XPositive" strings directly as you mentioned? In other words, there's nothing "positve Y"-ish about 3, so the code must be branching depending on literal values somewhere. IIRC, the data storage behind PropertyEnum can take care of the translation back-and-forth between ints and strings if it's a C++ domain issue.
Hmm... you seem like a guy that won't get bored by this little story I am going to tell you. Path.Area is pure C++ implementation. Its python object is just a thin wrap. Because of the need to expose large amount of parameters, I come up with a marco library to help the tedious task of exposing the same thing in multiple places, function argument, settings, properties, python wrappings, doc strings, etc. In my code, there is very little direct references to individual parameters, only groups. BTW, the library is in src/Mod/Path/App/ParamsHelper.h with full document, and all Path.Area's parameters are defined in AreaParams.h, if you are curious. In the process, I had my first try of boost.postprocessor, and I was having too much fun with it. It wasn't until I tried to add the string enumeration support that I realized that I went too far. It would have been better to mix pure macro iteration with meta type structure, at least for the enumeration. There are more than a dozen of enum parameters in Area. I made an attempt, but the code looked ugly, so it's been scratched. And my interests has since been shifted to other things. It is still on my to do list, though.
Try Assembly3 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
ian.rees
Posts: 696
Joined: Sun Jun 15, 2014 3:28 am
Contact:

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

Post by ian.rees »

realthunder wrote:
ian.rees wrote:A more Pythonic solution to the algorithm only handling vectors that are "on axis" is to accept a vector (perhaps of 3 ints), but throw if it's not in a direction that the algorithm can handle. That way, if someone extends the algorithm later to accept a wider range of directions, the interface doesn't need to change.
Well, I like to be more extendable as well. It's just that I failed to imagine the possibility of any direction control other than those axial ones. But I may be wrong here, and I'll be happy to change it if someone can hint any possible use case.
Perhaps I'm not understanding how this parameter is used - but what about manual+CNC machines that aren't setup with the controlled axes orthogonal? For example a mill with the quill tilted, or a lathe with a compound slide not at 90 degrees?
realthunder wrote:Hmm... you seem like a guy that won't get bored by this little story I am going to tell you.
Ha! Well, I hope that's a good thing at least in this context ;)

I had a very quick look at the macros in ParamsHelper.h (interleaving this with other things) - seems like a good tool for the bulk task. However, I would still encourage making the Python API robust in it's own right. Maybe that means some specialised code in a few places to hide the C++ and Python sides from each other.
User avatar
bill
Posts: 376
Joined: Fri Jan 09, 2015 9:25 pm

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

Post by bill »

Hello Ian and realthunder,

I just accidentally closed the wrong window with my lengthy explanation version; so, here are the highlights

I see your points and agree with them 99-percent Ian.
These are "magic numbers"! They are not necessarily vectors. You could use vectors for simple 3-ax machine running linear.
These magic numbers are defining a state; or more accurately a DIRECTIVE of how to generate path vectors (is this the intent/correct realthunder); i.e. METADATA for lack of a better word.

Here is the missing 1-percent.
cncaxis.png
cncaxis.png (6.35 KiB) Viewed 2333 times
If a machine has a fourth axis; in this case A-axis, you will be looking for that magic number (list/enumeration or whatever you want to call it).

I think, to define a motion/movement on the A-axis using vectors, would now require minimum two (2)vectors and maybe minor kinematic calcs.

From what I know, (I dont have an A-axis yet) typically, movement of A-axis is defined by rotation: degrees, radian, etc.; at least in one case I am sure.

Thats where realthunder's extensible list could simply include rotary action/definition; thats why I have to agree with 99-percent of what he is saying!

Hope this can be of some value!
realthunder
Veteran
Posts: 2190
Joined: Tue Jan 03, 2017 10:55 am

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

Post by realthunder »

bill wrote:Here is the missing 1-percent.
I can't say I understand your description about the A axis movement, but yeah, that's basically what I mean, that it's kind of difficult to use a vector to represent the desired the direction. When it says XPositive, it is not a strict (1,0,0) direction. It means ignore the Y, Z axis, and check only for start.x < end.x, although I am not 100% sure this is what user wants either.
ian.rees wrote:However, I would still encourage making the Python API robust in it's own right. Maybe that means some specialised code in a few places to hide the C++ and Python sides from each other
Yes, I'll do it for sure, maybe soon.
Try Assembly3 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
Veteran
Posts: 3457
Joined: Tue Oct 25, 2011 10:46 pm
Location: Columbia, Missouri
Contact:

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

Post by sliptonic »

realthunder wrote:
sliptonic wrote:Yes. That will work but vFeed and hFeed need to be separate.
What GCode controls the feedrate separately? All I found is one F in G1?

BTW, please checkout my PathArea branch. It's a new one, it'll be better if you do a fresh checkout. I've added step down handling. A new parameter 'orientation'' in Path.fromShapes controls the move direction. 0 no control, 1 CW, 2 CCW. CW/CCW refers to the outer loop direction. Inner loop (holes) direction is reversed. The same parameter is exposed to PathShapeFeature, so you can play around using GUI. I am in the process of adding the straight line pattern.
Is it possible that you have CW and CCW exactly reversed? That seems to be the result I'm getting. Otherwise the behavior is looking good.
User avatar
sliptonic
Veteran
Posts: 3457
Joined: Tue Oct 25, 2011 10:46 pm
Location: Columbia, Missouri
Contact:

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

Post by sliptonic »

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.

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.
snapshot.png
snapshot.png (21.4 KiB) Viewed 2268 times
chrisb
Veteran
Posts: 53925
Joined: Tue Mar 17, 2015 9:14 am

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

Post by chrisb »

I am not sure if this is standard behaviour, so please let me know if your machines behave the same:
Doing a rapid move G0 in a horizontal+vertical direction on the machines I know moves alway vertical first, if it goes up and moves it last, when it goes down.
A Sketcher Lecture with in-depth information is available in English, auf Deutsch, en français, en español.
GeneFC
Veteran
Posts: 5373
Joined: Sat Mar 19, 2016 3:36 pm
Location: Punta Gorda, FL

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

Post by GeneFC »

chrisb wrote:I am not sure if this is standard behaviour, so please let me know if your machines behave the same:
Doing a rapid move G0 in a horizontal+vertical direction on the machines I know moves alway vertical first, if it goes up and moves it last, when it goes down.
The machines I know are completely stupid. They do only what the controller tells them to do. In the case of LinuxCNC all moves directed in a single line of instruction are blended and occur simultaneously to yield a straight path. This is true for G0 or G1 moves.

If a sequential move is desired, say, vertical then horizontal, the commands must be issued separately.

Gene
realthunder
Veteran
Posts: 2190
Joined: Tue Jan 03, 2017 10:55 am

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

Post by realthunder »

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.
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.
Try Assembly3 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
Veteran
Posts: 3457
Joined: Tue Oct 25, 2011 10:46 pm
Location: Columbia, Missouri
Contact:

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

Post by sliptonic »

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.
ok. This makes sense.
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.
Just checking in. I haven't had much time to work on this lately but I'm wanting to get back to it. Since we're not using PathArea much beyond my limited testing, is there any reason to hold off merging your latest changes?

If you want to wait, could I get you to rebase off master? There was a minor change in commit: a75a98ef279e9e067abf5cef3a6de6f09fba2c94 that affected Area.
Post Reply