postprocessor for Grbl +4th axis, THC & touch-off

[Tristan86]

Hello,

You may skip the introduction. I think yet it may be useful to tell my context and challenges, to those that think they coud benefit the relatively long experiences and questions I had

Intro
I have started and almost finished a plasma CNC project, basing my self mainly on "JD Garage"'s blueprints. You may find them easily on youtube

(These blueprints are for sale, pretty, cheap 25 euros or dollars), but beware, from my experience this project takes muuuuch time, much more than what I would expect, even though their explainations are nice. The blueprints and the general design as well have some pros and cons. The EMI issues are barely tackled, even though this is a serious problem, which really takes time, to adress according to serious standards. We might discuss about all of this if you wish. But this forum is not especially the place for this aim)

This JD Garage project offers a XY plane simple build, and the use of Z axis for a probe to keep the right distance between the torch and the material. It also offers a cheap way to get a kind of rotary axis, but only for round tubes and specific cuts to them, using the X motor driver to drive another motor turning round tubes around themselves . I want to use a 4th axis of its own, with a specific driver and motor, and a chuck of four jaws, to cut rectangular tubes too, square tubes at least. However,I did not want to spend too much money on everything. Therefore, Grbl is still relevant, as it has various fork versions, working with Arduino Mega, offering 4 or 5 axis ( even 6 axis with one of them I believe). Among them, I chose until now Grbl Mega 5X, but that may not change a lot its working.
I plan to implement later a THC (and make it of my own perhaps), working of its own. Of its own because GRBL is not able to deal with a THC, but the Z probe touchoff befor each cut would in my opinion make it easy to compensate the lack of consistent Z DRO once the the THC influences the Z motor without Z DRO feedback. A few optocouplers may be able to take the control of the Z driver according to some THC settings, and and give it back to GRBL after each cut finishes.
I have not yet bought SheetCAM, but it looks to me like a better solution than Fusion 360 for instance, as was recommended by JD Garage family. Once you buy, you have it, no number of "activated models" limitation, and you can process rotary tube cuttings with just a few more tens of euros while it looks like Fusion does not offer the 4th or 5th axis CAM in its free version.


Main subject of the thread :

But, I am not sure of the sheetcam post processor that would fit my needs, given this quite complex situation. 3 cartesian axis including probe, one 4th and rotary axis, and later a THC attached to Z motor but independant from GRBL. Especially I know nothing about postprocessors even though I may be willing to learn, and need one able to fit my design.
It happenned that bLouChip shared the postprocessor he developped there : viewtopic.php?p=31191#p31191
and it looked like it was similar to my needs. I saw in the forum some other people deal with grbl postporcessors challenges. So after a few questions to him, he suggested me to open a specific thread where we may discuss the issue and its solutions, hence this post.

I hope this may help some other users. I will be active back in this thread in a few weeks hopefully, and do not know yet of bLouChip' disponibility, but whoever else is willing to contribute to common good and building collective intelligence is of course welcome.

[bLouChip]

Thank you for your fast answer !
...
Just one last question. Where, with which informations and sources, how did you learn how to adapt and write your postprocessor code ?

I had a lot of practice with programming in various languages in my day job years ago, but these days that just qualifies me to be dangerous, not good . So my take on SheetCAM is that Les did quite a nice job designing and building it, especially making SC extensible in several different ways and at different levels of complexity, allowing different skill sets of users to interact and extend it as need be. Once I realized this, I decided to use the scpost as the primary function extending, function customizing interface. Some other interfaces that are more user friendly are Path Rules, Action Points, and Code Snippets, and those can also be used with stock or customized scpost.

The scpost documentation, linked in Options->Machine->Post processor window, is quite good as a reference. I read some of the shipped scpost files to get some sense of patterns and necessary operations, and occasionally I use the Lua language reference linked from the scpost doc. I practiced with SC for about a month before I purchased a lic and recall it being a challenge to digest all of its bells and whistles. I'm sure I watched some youtube about SC also but I can't recall which ones, and the Help tutorials and help doc continue to be useful.

re. grbl as a controller - if you haven't looked at grblHAL yet its worth a look. If I were building another CNC and picking a controller suitable for milling, plasma, and laser processes, I'd almost certainly use grblHAL and its associated hardware/interface boards. I purchased this board earlier this year when I thought I'd be switching over to it, but have since resolved the issue that drove me to consider grblHAL and thus now I'm not in such a hurry to switch, but some day perhaps. grblHAL has THC Z axis management code and integrates with either its own THC board or a commercial unit like a Proma THC 150.

[bLouChip]

I'm attempting to modify my grbl post to also handle rotary and I have a few questions.

1) I'm not sure if its a good approach to use a common scpost for both XYZ (nonRotary) and XYZA (Rotary) jobs. I would prefer to of course, reason being that all of my custom post code is in one place since I suspect 95% of it is common to both use cases. Perhaps Les or someone please advise if not. Seems like I read somewhere or recall from a training video that selecting "Flatsheet" in the Rotary-Plasma plugin was a processor-heavy way of generating toolpath for XYZ jobs, so I wouldn't plan on running the Rotary-Plasma plugin for XYZ jobs. If it's processor-heavy regardless, would it help at all if I use a var. that is set external in Options or in Set Variable Operation to condition the rotary logic in my scpost ? but still unconditionally have the the necessary plugin loader code, assuming that is compile time stmt.

Code: Select all

package.path = sc.Globals:Get().thisDir .. "/plugins/RotaryPlasma/?.lua"
require("rotaryhelper")

2) where is the internal variable toolOffset assigned ? I see it used in OnRapid() and OnMove() when posting Z, such as

Code: Select all

   post.ModalNumber (" Z", (endZ + toolOffset) * scale, "0.0000")

And does it relate somehow to the object in the rotary chuck, such as the distance from the center of rotation ?

Or does this stmt from LinuxCNC plasma rotatif.scpost get the distance from center of rotation to surface or OD ?

Code: Select all

local matZ = sc.QueryDll(qryCHKEND, endY, dllId)

I'm trying to understand how to handle torch touchoff/probing code. My CNC's Z motion is only 90mm, but I can lower the rotary chuck to allow for much larger diameter pipe and rectangular objects. So I may need to start the job with WCS Z zero on the (or a) surface of the rotating object to compensate for my Z never being able to extend to center of rotation; I thought I understood somewhere that SC expects or assumes Z is zeroed on the line which is the center of rotation of rotary axis A or B, and the scpost examples I'm looking at seem to suggest that also, or at least something other than surface of rotating object.

3) I'm attempting to use both "LinuxCNC plasma rotatif.scpost" and "Mach3 rotary.scpost" as examples of known good rotary scpost code. Perhaps there are better examples to study ?

4) In some gcode I've generated with Mach3 rotary.scpost, and using the simple case of "Round pipe" object in the Plasma-Rotary plugin, I don't see how the dimension for WallThickness is applied, it seems the generated Z motion only accounts for PipeDiameter which is ID, I have to use the OD dimension for PipeDiameter in order to get the right Z motion distances.

Thanks for handling.

[Les Newell]

The flat sheet option will make the rotary post just use X,Y,Z. It is a bit more CPU intensive than using a dedicated post but you probably won't notice a difference unless you are doing a lot of very complex artwork with thousands of moves. It only affects the time it takes to run the post processor. It does not affect path generation.

The rotaryhelper is package is loaded at compile time (when you start SheetCam or when you open a new post) so you can't change it at runtime.

2) where is the internal variable toolOffset assigned ? I see it used in OnRapid() and OnMove() when posting Z, such as

It is generated by SheetCam just before OnToolChange. If I remember correctly for plasma it is always 0. For milling/routing it is the tool length offset from the tool definition.

Or does this stmt from LinuxCNC plasma rotatif.scpost get the distance from center of rotation to surface or OD ?
local matZ = sc.QueryDll(qryCHKEND, endY, dllId)

It gets the current distance from the center of rotation to the surface. For round tube it will always be the radius but for square/rectangular it will depend on the tube angle (SheetCam Y axis position). For flat sheet it will return 0.

Rotary posts use the center of rotation because of the problem with the surface height being dependent on angle for square/rectangular tube.

I'm trying to understand how to handle torch touchoff/probing code. My CNC's Z motion is only 90mm, but I can lower the rotary chuck to allow for much larger diameter pipe and rectangular objects

If you do a torch probing cycle, the cycle can automatically allow for changes in the chuck height. Once you have found the surface of the tube you can find the distance to the center of rotation using sc.QueryDll(qryCHKEND, endY, dllId).

In some gcode I've generated with Mach3 rotary.scpost, and using the simple case of "Round pipe" object in the Plasma-Rotary plugin, I don't see how the dimension for WallThickness is applied

This controls the cut geometry and only has any effect when you use 'Map drawing to inside'. Due to the geometry of a pipe the hole will have a taper. If you want to make a hole that allows something to fit all the way through, you need to make sure the inner geometry is correct. On the surface the hole will end up larger.

it seems the generated Z motion only accounts for PipeDiameter which is ID

Huh, I never noticed that the graphic is wrong. The pipe diameter setting is the OD, not the ID. Sorry about that.

[bLouChip]

Les,
many thanks! You nailed answers to all of them!
SC is such a great sw app, very well done.
I'm glad SC put you on a trajectory to retire soon, but we're going to miss you.
take care,
Lou

[bLouChip]

just FYI, I now have a working version of my grbl scpost adapted to rotary, posted here: viewtopic.php?p=31252#p31252
I'm still testing it, so use with caution, I recommend you dry run the gcode before a live cut.

[djreiswig]

I've played around with creating a rotary post for my machine, but haven't built the chuck yet. Someday...
I tried to dissect the default posts but was never really sure what was different between the flat sheet posts and the rotary posts. It doesn't look like there are too many differences. Since you're the rotary expert, what are they?
It looks like Les's reply above explains quite a bit of the functions, but it would be helpful for me and probably others to have an explanation of what needs to be added to perform the rotary conversion. Like what all of the Querydll calls do.

[bLouChip]

@djreiswig- you're too kind, I'm far from an expert, more like dangerous, but thank you anyway. I'll be glad to write down what I have learned and post here, will do in a separate text file later today.

I'm still testing my scpost with rotary, so not sure if I'm through all the traps yet but perhaps close, at least for Flatsheet, Round Pipe, and Rectangle Tubing; I've not tested for I-Beam or Custom profiles yet and really don't have plans to unless someone is interested. I had to rely on Les to lead the way the past 2 weeks, we exchanged several emails to get me through some of the dll understanding(lack thereof) that you elude to. The good news is that some of that detail is not relevant in a normal adaptation of rotary. My adaptation of rotary to my former non-rotary scpost is a bit different than most in at least 2 ways:
1) I'm using a Z zero point of rotary object surface, not center of rotation (axis); the Rotary-plasma plugin/helper returns values from center of rotation. I'm using the surface because my machine was born with a short Z axis.
2) I took a few coding steps to make it easy to use my scpost either with the Rotary-plasma plugin or without it. "With the plugin" means you must have the plugin license or the scpost as-is doesn't work, "WITHOUT the plugin" simply means that you can comment out only the two Rotary-plasma plugin/helper statements at the end of the scpost and it still works for non-rotary normal use cases without further scpost editing; that just makes for easier maintenance of the scpost in my opinion since 95% of it is common between both rotary and non-rotary use cases.

[djreiswig]

I'm interested to see what you come up with. I'm also interested in both cases you laid out. Especially #2, since I will be using a post for both cases. I could create 2 posts, but as you say, most of the code is the same.
I'll have a better look at your post later.

[bLouChip]

@djreiswig - attached is my annotated scpost to explain the additions to make it rotary enabled, and 'ambidextrous' as to having Rotary-plasma plugin Enabled or not. Recall that this scpost is relative to Z0 at the surface of the rotary object, but I believe I have made those stmts obvious in comments and further annotation. The red ink is the additional annotation and associated rotary scpost code.

[djreiswig]

Thanks. I looked at it briefly. It looks fairly complicated. I'll dive into it a little more later.

[bLouChip]

darn, I'm sorry; I didn't intend for it to be complicated, just the opposite, was hoping to simplify it.
I added some further annotation to the write-up, in blue ink, and reposting here.
I was more explicit with those code statements that are rotary optional in general, those that are only necessary because of my scpost using Z0 on the surface of the rotary object, and those that are necessary due to having one scpost to work with and without the Rotary-plasma plugin/helper.
Please don't hesitate to ask if further questions.

[djreiswig]

By complicated, I meant there is a lot going on, not it's messy. I just scanned it quickly on my phone. I made a lot of custom modifications to my post as well, so I'm sure you would probably say the same thing. I'll check it out more later.