I have a home-built plasma table running a UC400ETC, Gecko 540, and a generic brake out board to hook up the Proma 150 THC. I’m using Mach 3 and sheet cam software.
I have managed to get the Proma talking to Mach 3 and I have managed to get it adjusting the height pretty decent.
Items I want to sort and I’m sure it is just in the setting or post processer.
I place the torch at zero, when I hit start and the torch is at zero it doesn’t automatically rase the head it will just drag across to the first pierce point.
During the cutting process it will finish a cut, Z axis will rise to 20mm (as per the rapid setting) rapid across to the next pierce point. The torch height will lower to 3.5mm (what is set for pierce height) then raise again to 20mm then lower and touch off before rising again to the 3.5mm (+ the 2.2 for the switch offset) pierce height then commence the cut.
AND it seams to be touching off for cuts closer then 500mm.
I have selected Mach3 plasma with scriber and backlash compensation as the post processor and have only adjusted the switch offset only.
Do I have the correct post processor? What setting am I missing?
All 3 issues should be fixed in the attached version.
The lines added and changed in the original version are flagged with “–LDC”…
re. refDistance, the original was accumulating the cut length and rapid distances for compare to refDistance, to determine if a torch probe cycle is necessary. I changed the compare to be a radius from the last torch probe XY position, which is proximity to refDistance.
re. Z raising to 20mm (safeZ) after lowering to pierce height, that is a global binary var refHome, default was true, which causes the safeZ motion; needs to be false for torch probe cycles to occur.
Thank you.
The above was a little over my head to start with but once I downloaded the files saved and clicked on them it all makes sence. I looked at the edited postporcessor and see what you have done there.
On viewing the G code it looks like it will be spot on. I will be running the machine tonight so will let you know.
no problem, you’re welcome.
I was a bit in a hurry the other day, and I recalled seeing some odd stuff in the .scpost, so I took another look this morning and fixed up the oddities. Please let me know if I broke anything, of course hopefully not.
there were two OnArc() functions defined, only the last one wins as far as being called. It was probably written with that intent since the last definition was hard coded to use ArcAsMoves() always. So I commented this out, and defined a new global var machArcAsMoves, where 0 will use G2/G3 arc motion and any positive value will invoke Sheetcam’s ArcAsMoves() to use G1 motion. But know that if using ArcAsMoves() G1 motion, then global vars slowRadius (effectively) and slowPercent will not be used, as was the case in the original version.
Therefore now, with slowRadius = 19 and machArcAsMoves = 0, the code is by default in a state to use arc G2/G3 motion and make use of slowRadius and slowPercent.
dist var dead code was commented out as a result of dist now being proximity to last torch probe cycle.
commented out conditional stmt in OnRapid() which was incorrectly suppressing motion to pierce height on the first pierce due to wrong logic.
var offZ, a number, was used as a boolean which will always test true if its is not nil, so even a value of 0 will test as true, contrary to the behavior of C lang. Also in the same “if” stmt, not necessary to test var firstRef since ModalNumber() will suppress posting the line if Z is very very large (3e38 or something like that, indicating SC has not initialized the axis var with a valid work area coordinate).
added a fix to restore XY position precision after a torch probe cycle, in Reference() function.
This will avoid grbl and most other controllers error33, thrown on arcs that don’t pass the 0.005mm tolerance of begin and endpoint falling on the arc path. These are pretty common to occur on lead-in arcs since that is usually the next XY motion after a torch probe. It is also conditioned more frequently on CNC configurations where the XY motion mm/STEP is quite large (>> 0.005mm/STEP), such as mine which is 0.0175mm/STEP. Mach3 plasma THC with scriber and backlash compensation.scpost (13 KB) mach3 scpost test1.tap (3.14 KB)
Thanks, It’s been a hot minute since I have checked this forum. everything seems to be working fine but I will run the new script. I did adjust the radius on the prob as I found if there was a lot of cuts in row this would become an issue.
I have been chasing an intermittent fault that I have traced back to a lose neutral so I can start really fine tuning now.
Hi, I have been running this post processor with much issue of late however I have noticed something that I’m not sure if it’s a Sheetcam setting or Mach3 issues.
When the machine initiates a cut it will lower from the 20mm rapid height to the 3.5 of 4 mm programmed pierce height, initiate the arc, lower to 1.5mm then to 0mm till touching the material then the THC seam to take over. If I set the minimum Torch height on Mach3 that will limit the torch height touching after piercing. I have tried setting the THC to well above the desired height however it will still go to 0mm.
This will do the same after it has “touched off as well”
If you are still using the pp attached here, then based on the gcode snip you just posted, ‘switchOffset’ var in the pp is set to 2.0mm, make sure that is correct and matches your floating torch mount distance, including the switch actuator overrun which occurs during the probe operation. If that distance is too short, it can cause the symptom you describe.
Second- the pp has code to skip torch touchoff prior to pierce when the current position is within proximity of the previous touchoff. ‘refDistance’ var in the pp sets the proximity distance. Use 0 if you want a torch touchoff on every pierce and while debugging an issue like you describe. If this distance is too large, it can cause the symptom you describe.
hold on- I see something else in your gcode snip- after the pierce and delay, you are lowering the torch to cut height at a speed of 200mm/m, that’s too slow. Your THC has a time delay setting in it (DLY) and its too short of a delay for that Z speed. It’s taking 0.5 secs for Z to move from PH to CH, after the 1.0 sec pierce delay. So if your THC has less than 1.5 sec DLY value, that’s a problem, its taking over and driving the torch down. Either make the THC DLY value 3.0 or make the plungeRate 2400mm/m, normally you should have plunge be rather quick if using such a long PD.
Thanks Lou. That all makes a lot of sense. My Compressor pump finally gave it up on me and I have to go away for proper work for a day or too but I’m keen to adjust these setting and see how it goes.
I built this from the ground up and have just got by with trial and error so far. Some of the suggested setting I have found on the net were way too fast or slow, so I have got it working and just let it be. I think this issue has only really come up when I raised the pierce height for the thicker materials which makes sense to the adjustment you have advised.
To tell the truth in Mach3 I did the motor tuning when I first commissioned the machine so they could use some adjusting too.
Thanks again
