Proma THC, Mach 3 sheetcam settings help

Hi,

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.

  1. 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.
  2. 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.
  3. 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?

Thanks



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.

Let me know if I missed something.
compare Mach3 plasma THC with scriber and backlash compensation.zip (7.55 KB)
Mach3 plasma THC with scriber and backlash compensation.scpost (11.8 KB)
mach3 scpost test1.tap (3.71 KB)

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.

Thanks again.

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).

  • I may have misunderstood you originally about desiring to have a > 500mm proximity radius to last torch probe cycle before running another. 500mm of course is a long distance, so if necessary, just adjust it smaller as desired for a proximity radius.
    mach3 scpost test1.tap (2.9 KB)
    Mach3 plasma THC with scriber and backlash compensation.zip (2.72 KB)
    Mach3 plasma THC with scriber and backlash compensation.scpost (12.5 KB)

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.