post processor resources

[polemidis]

Hello, so I decided to give it a 2nd try on working with the PATH for generate g-code for a grlb based plasma machine I built.
My question is what should i read in order to customize the post processor.

My exact need is to replace the G0 Z direction rapid moves with the Z zeroing probing code. After each cut most likely the Torch Height Controller which interferes the Z signals and takes control of the Z movement, will have the Z in an unknown location and definitely not aligned for the next path.
So I would like to insert something like
G38.3 Z-100 F10
G0 L20 P1 Z-1.5
G0 Z0
M3 ....
So the "zero" is 1.5mm above the metal

I have a feeling I have to study python???
A 2nd need is to turn the plasma off (M5) and on (M3) between rapid movements.

Is what I want to do realistic/possible?

[sliptonic]

ello, so I decided to give it a 2nd try on working with the PATH for generate g-code for a grlb based plasma machine I built.
My question is what should i read in order to customize the post processor.

Fantastic! I'm afraid there's not much written yet. In fact, the wiki page about customizing post processors is a bit thin. Actually, it's embarrassingly thin.

But I'll be happy to help!

Probably the best thing is to look at the existing post processor code. The posts are mostly self-contained scripts and not too complicated.

Looking at the GRBL post, the code down to line 140 is setup, defining some globals, and parsing the arguments. Nothing too interesting unless you want to add new arguments.

After that there are just three procedures. export(), linenumber(), and parse(). Linenumber just does what it says, handles the line numbers. All the magic is in export and parse.

Export() handles the big picture and assembles one big-ass gcode string which is the final output. Export() decides whether or not to insert tool change code, spits out unit strings for the machine, headers, comments, etc. Any changes in how the machine behaves between operations is probably going to be here. Starting around #184, it iterates through all the objects in the job, outputs comments, and then passes the individual object (tool change, operation, etc) to Parse().

Parse() does the heavy lifting of converting the object into gcode which it returns to export(). Any changes to how individual commands are output or processed is going to be in Parse. Most likely your changes are going to be here.

The code starting around #249 is key. It's iterating each command (c) in the path object and deciding what to do. You'll need to add logic that understands what's happening in the gcode and does the right thing.

For comparison, look at the parse() routine in the linuxcnc post around #297. It's a bit more sophisticated than grbl. If similar logic existed in grbl, the else clause at #304 is where I'd insert logic to turn off the torch, for example.

Feel free to ask lots of questions or catch me on IRC at #freecad or in the gitter/path room.

[polemidis]

οκ, Ι saw these files. But, my last programming was in high school with Quick Basic. 22 years back While I catch up, if i provide you with the logic can you help me translate it in python?
My 1st approach (but not-ideal) would be with post processor.

A big parenthesis here is that after some thinking I would like be able to add in the regular PATH workbench:
Something that converts the whole Workbench to 2D. Either for laser or plasma. The code is already there, actually is simpler imho!
With 2D somewhere we could add some constants like
a)Initial Height Probing Commands
b) Safe height
c) Plasma cut height
So before it even reach the post processor the PATH will generate useful code. It can use the b) to move in the starting point, run the a) function in the g-code, move into c) height, and run the regular command (like the Face Profile) only that now it adds the M3/M5 at any raise/depression of the tool.
Maybe later a parameter can be added of how often or what is the minimum distance the torch has to travel before it re-zeroes the Z, trying to avoid too many zeroings. Anyway thats just my super simplified thought, i guess there are a lot more to be considered.
The www.sheetcam.com is a good program that someone can use a reference. I also checked the https://github.com/OpenBuilds/cam . I can't make it work, but you can see what i mean. Its https://cam.openbuilds.com/

Closing the parenthesis, and continuing to the quick n dirty post processor


Without understanding yet all these steps inside the post proc. I would add a new argument that just asks if it is for a plasma machine with TorchHeightControl. (its convenient just for me! hahaha). My thought is that with plasma and THC we need only 2D.
So when a user adds the --plasma-thc these happen:

Stores every Z detected value to a variable "Z_check"
Check every new Z and compares it with Z_check.
When its of smaller value and its of a G1,
It adds the zeroing() function to the post g-code
Raise the Z to 1.5mm
Starts the torch (M3).
Continue its normal flow
Else If its equal
Continue its normal flow
Else if it is bigger then
stop the torch (M5)
Raise to a safe height
Endif
Store the Z value to the Z-check.

What do you think about this simple way? Of course I must not create multi level passes etc. Would that work just for now?

The various Z values through the regular code are not important with the THC if the torch is on since it just ignores them (the THC has the final word on the Z)

[sliptonic]

οκ, Ι saw these files. But, my last programming was in high school with Quick Basic. 22 years back While I catch up, if i provide you with the logic can you help me translate it in python?

I'm far from the strongest programmer around here but I'll do my best. Others may laugh at my futile attempts and show us both how to do it right

My 1st approach (but not-ideal) would be with post processor.

A big parenthesis here is that after some thinking I would like be able to add in the regular PATH workbench:
Something that converts the whole Workbench to 2D. Either for laser or plasma. The code is already there, actually is simpler imho!
With 2D somewhere we could add some constants like
a)Initial Height Probing Commands
b) Safe height
c) Plasma cut height
So before it even reach the post processor the PATH will generate useful code. It can use the b) to move in the starting point, run the a) function in the g-code, move into c) height, and run the regular command (like the Face Profile) only that now it adds the M3/M5 at any raise/depression of the tool.
Maybe later a parameter can be added of how often or what is the minimum distance the torch has to travel before it re-zeroes the Z, trying to avoid too many zeroings. Anyway thats just my super simplified thought, i guess there are a lot more to be considered.
The www.sheetcam.com is a good program that someone can use a reference. I also checked the https://github.com/OpenBuilds/cam . I can't make it work, but you can see what i mean. Its https://cam.openbuilds.com/

Closing the parenthesis, and continuing to the quick n dirty post processor

A 2D CAM workbench doesn't interested me. The discussion comes up from time to time and if someone builds one, I'll happily look. The community will decide whether or not it should be included. Experimenting with different approaches is always encouraged and good ideas win out. Bad ideas die out. As it should be.

The reason I'm resistant is that it's a step backwards and usually causes more trouble than it removes.
People seem to look for the functionality because they are used to working on 2D geometry directly. Applications like sheetcam do that and when most of us learned CNC, that was the approach. But honestly, it's a leftover from when computers were less powerful and 3D wasn't an option.

We aren't cutting 2D objects - even a sheet of paper has thickness. The objects we're making are 3D so the models that represent them should be 3D. That makes it possible for CAM applications to get smarter. The third dimension carries very important information that CAM can use to automatically set things like safeheight, step-down, clearance, etc. Without a 3D model, that information is still required but the user has to supply it in other ways. (by manually configuring the operations)

Furthermore, 2D geometry is ambiguous. If I import 2D geometry, I can reasonably infer that the outer closed wire is a perimeter but what about inner wires? Do they represent engraving lines or cut lines? Again, the user ends up supplying information that should be coded into the model.

Once a proper 3D model is available, I guarantee setting up CAM is faster than setting it up from a 2D representation. It makes sense because the ambiguity has been removed and the computer can do most of the work. Even more importantly, the result is less error prone.

Don't misunderstand me. I think FreeCAD needs better tools for working with imported 2D geometry. If someone wanted to build a workbench dedicated to converting 2D imported data into correct 3D models, I'd probably kiss 'em on the lips but I don't think it belongs in Path. That's a modeling task not a CAM task. It might be us CAM developers who work on it because we need it but that's different.

Without understanding yet all these steps inside the post proc. I would add a new argument that just asks if it is for a plasma machine with TorchHeightControl. (its convenient just for me! hahaha). My thought is that with plasma and THC we need only 2D.
So when a user adds the --plasma-thc these happen:

Stores every Z detected value to a variable "Z_check"
Check every new Z and compares it with Z_check.
When its of smaller value and its of a G1,
It adds the zeroing() function to the post g-code
Raise the Z to 1.5mm
Starts the torch (M3).
Continue its normal flow
Else If its equal
Continue its normal flow
Else if it is bigger then
stop the torch (M5)
Raise to a safe height
Endif
Store the Z value to the Z-check.

What do you think about this simple way? Of course I must not create multi level passes etc. Would that work just for now?

The various Z values through the regular code are not important with the THC if the torch is on since it just ignores them (the THC has the final word on the Z)

Posts are meant to be hacked and customized. You can make a new copy of the post and put it in your macro directory. Just give it a unique name that ends in '_post.py'. What you've outlined is pretty easy to do and as an experiment, certainly worth it. I wouldn't even worry about the argument unless you want to use the same postprocessor yourself without the thc function.

Before we talk about coding the argument or merging the fix into master, I'd want to understand more about what's going on: Are you probing so often because the material thickness may not be constant or because the path you're processing has variable z depth? In other words, why not probe once at the beginning and assume the same depth for all operations that follow?

A rough stab at pythonification of your logic follows. Nothing checked or tested

Starts around line #260 of the grbl post.

Code: Select all

            # Now add the remaining parameters in order
            for param in params:
                if param in c.Parameters:
                    if param == 'F':
                        if command not in RAPID_MOVES:
                            outstring.append(param + format(c.Parameters['F'] * 60, '.2f'))
                    elif param == 'T':
                        outstring.append(param + str(c.Parameters['T']))
                    else:
                        outstring.append(param + format(c.Parameters[param], precision_string))
                        if param == 'Z' and command in ['G1', 'G01']:
                            if c.Parameters[param] < z_check:
                                outstring.append('GCODE THAT DOES PROBING')
                                outstring.append('GCODE THAT RAISES Z to 1.5mm')
                                outstring.append('M3')
                            elif c.Parameters[param] > z_check:
                                outstring.append('M5')
                                outstring.append('GCODE THAT RAISES Z SAFEHEIGHT')
                            z_check = c.Parameters[param]


            # store the latest command
            lastcommand = command

[Mbeh]

There is an Inkscape 2D laser plugin call KM-Laser Bundle that work on that principle. This plugin generates very efficient gcode for Linuxcnc. https://github.com/KnoxMakers/KM-Laser.

[polemidis]

Before we talk about coding the argument or merging the fix into master, I'd want to understand more about what's going on: Are you probing so often because the material thickness may not be constant or because the path you're processing has variable z depth? In other words, why not probe once at the beginning and assume the same depth for all operations that follow?

I assume the material is constant thickness.
The reason is that plasma cutting generates tremendous amount of heat that wrap the metal. And because the plasma flame cuts nicely only at a very specific height in tenths of a mm. Too close and the top is narrow, too far the top is wider. Imagine the profile of a flame.
The other reason is that with homemade plasma cutters -which are not overbuild- most likely there is going to be at least 1mm height difference on various spots on the table. I believe in mineI have even a quarter inch. The need is only on every new torch start, just setting the initial height (usually in 1.5mm but it depends the plasma) as during the cut the THC measures the voltage of the arc at 10Khz(!!!) and controls the Z


About your arguments on 2D you are right, I get your perspective. But the need for 2D comes to play because of the specific need of the plasma, that the THC takes full control of the 3rd dimension. Plus the height probe zeroes the Z,
So even its a 3D object, the Z dimension control goes not to the user, but to these automations

Thank you for your help, I will check it out later tonight!!

[sliptonic]

The reason is that plasma cutting generates tremendous amount of heat that wrap the metal. And because the plasma flame cuts nicely only at a very specific height in tenths of a mm. Too close and the top is narrow, too far the top is wider. Imagine the profile of a flame.
The other reason is that with homemade plasma cutters -which are not overbuild- most likely there is going to be at least 1mm height difference on various spots on the table. I believe in mineI have even a quarter inch. The need is only on every new torch start, just setting the initial height (usually in 1.5mm but it depends the plasma) as during the cut the THC measures the voltage of the arc at 10Khz(!!!) and controls the Z

This is interesting but there are two different things going on. Both of them have a similar solution (in this case) but a better solution might consider them independently.

The first is the heat-induced warping. The actual warp is going to depend on material, shape, and probably other factors that can't be predicted ahead of time. The solution you propose is to probe at the start of each cut. Cool

The second is accounting for static deformation either in the material or the bed. This is similar to the problem with 3D printer bed leveling. The ideal solution would be to probe a grid and then adjust the z depth of the gcode to compensate.

Any time I hear a need to adjust g-code to account for real-world limitations of the tool, machine, or material I start thinking 'dressup'. That's what I'm starting to think here. Both of these could be implemented as dressups and would have broader application than just plasma cutting. The regular grid-probe is probably better handled as a feature of the controller but maybe not. It is, after all, the same technique gcoderipper uses to cut uneven surfaces.

About your arguments on 2D you are right, I get your perspective. But the need for 2D comes to play because of the specific need of the plasma, that the THC takes full control of the 3rd dimension. Plus the height probe zeroes the Z,
So even its a 3D object, the Z dimension control goes not to the user, but to these automations

Not really. The thc needs to adjust the z depth of cut but not fully control it. It's tweaking the depth but not establishing safe height or clearance.
Imagine that you're re-working a part like below to cut the slots but avoid crashing into the bosses. The THC is going to compensate the cut for each slot but it's all on the user to set up the safe height and clearance height. With a 3D model, this is trivial. With a 2D model it might be impossible (imagine 500 slots instead of 2 and bosses all over the place).

snapshot.png (9.99 KiB) Viewed 1027 times

[polemidis]

Not really. The thc needs to adjust the z depth of cut but not fully control it. It's tweaking the depth but not establishing safe height or clearance.
Imagine that you're re-working a part like below to cut the slots but avoid crashing into the bosses. The THC is going to compensate the cut for each slot but it's all on the user to set up the safe height and clearance height. With a 3D model, this is trivial. With a 2D model it might be impossible (imagine 500 slots instead of 2 and bosses all over the place).

I am new to plasma, and to CNC in general, but I have the impression that in plasma cutting the stock material is almost always a flat sheet of metal. Maybe I am wrong I do not know this field well. Maybe because plasma is not as clear cut as other methods, it can leave some dross than need grinding.
Anyway, no need to argue more on that

So what is your proposed way to be able to use PATH with plasma operations? through the post processor?
About dressup, I haven't experience with that I have to look it up.

[sliptonic]

So what is your proposed way to be able to use PATH with plasma operations? through the post processor?
About dressup, I haven't experience with that I have to look it up.

Plasma cutting, like any any other kind of CNC work, is going to have some special considerations and require proper setup. In that regard, it's no different than the others.

I think a customized post-processor is certainly needed. That alone should make it reasonably functional for basic plasma work.

Dressups are, as far as I know, a FreeCAD unique concept. They are a special kind of operation that adds refinement to an existing operation in order to account for real-world aspects of machines, tools, and processes. The classic case is 'holding tabs' to keep a part from flying off the table when separated from the surrounding stock. Rather than add holding tab functionality and options to every possible operation, we apply a holding tab 'dressup' to the operation after the fact. The dressup modifies the base path to add the tabs. It's, I think, an elegant solution.

Plasma cutters probably don't need holding tabs (unless you want to leave the parts lightly attached to the stock for some reason) but might make use of the dog-bone dressup to add over-cuts to inside corners.

I've heard rumors that some plasma software will move to a penetration point, then circle for a period to pre-heat the material before descending and beginning the penetration cut. This would be a perfect place for a dressup. Your probing routine might be another one.

Dressups are new features that would need to be merged into FreeCAD. I'm very happy to help with that.

Another thing I think would be great is a wiki page dedicated to discussing plasma configuration in Path.

[polemidis]

I've heard rumors that some plasma software will move to a penetration point, then circle for a period to pre-heat the material before descending and beginning the penetration cut. This would be a perfect place for a dressup. Your probing routine might be another one.

Not for plasma, but for a flame torch (acetylene), plasma cannot preheat it just cuts right away.
Anyway. Lets say that the post processor will work
This is a simple operation with leadinout.

Screenshot from 2018-05-16 16-23-39.png (32.86 KiB) Viewed 949 times

I changed the leadout parameter to tangent so I recognize it easier. You can see that it is messy and the lead in/outs are all over the place. Is this a problem on the code? What can I do to help with this? without that working right the post-processor fix is useless.

The file is onhttps://github.com/goscommons/Grapples/ ... ront.fcstd