Proma THC SD or 150 discussion

[bLouChip]

I'm looking for / hoping to exchange usage experience and ideas with folks that are using the Proma Compact THC SD or 150 models. I'm using the SD model on my table with a grbl v1.1i 4 axis controller. The SD is a standalone THC that directly controls Z when it detects a plasma arc, it "hijacks" the grbl STEP and DIR signals, (bypassing them through relays), and directly sends signals (for the same purpose) to the Z motor driver as long as the plasma arc is detected via arc voltage monitoring, monitoring which of course it uses to manage/control Z up and down in its attempt to hold the arc gap constant at the given voltage setting during cutting. Due to this control scheme and design, it seems inevitable that over the course of cutting shapes in a job, that there will be what I call THC induced Z error as seen by the grbl controller when grbl gets Z motor control back from the THC; which happens after the torch arc is extinguished and remains until the torch arc is fired again, then the cycle repeats. In this scheme, grbl better be finished moving Z where it wants it to be else Z STEPs will be lost, fortunately this aspect is somewhat easy to manage in the sequencing of gcode and with pre-cut torch probe zeroing. However, since Z is being moved by the THC during cutting, and since grbl has no idea of direction or distance that it moved, then it is virtually impossible for the THC to relinquish control of Z and have it placed back exactly where it began, especially considering the job of the THC, to move Z up and down in order to maintain arc voltage. Thus, grbl thinks Z is where it last positioned it, however its not there, its near there but not there. Near there is not good enough in the long term, in jobs with many shapes to cut, > 100. Consider that if Z is left out of position by just 0.2mm on each shape cut, usually not + or - but always + or always - relative to previous position, then after 10 shapes Z is out of grbl position by 2mm, and after 100 shapes, 20mm. I suspect people using this THC unit (or similar like DANI THC7SDP) know this operation info and the agonizing Z lower or upper soft limit alarm when the accumulated THC induced Z error exceeds the travel of the Z axis. I like to run with grbl soft limit alarms enabled, it saves many axis limit crashes while jogging or other gcode missteps. But I do understand that running without soft limit enabled is one possible solution if I accept the risk. How best to mitigate either the accumulated or per-shape THC induced Z error is what I'd like to discuss with folks.

The Proma THC 150 model is different in that it does not control Z motor driver directly, it does not hijack Z STEP and DIR signals, rather it communicates "in a well behaved manner" with the CNC table controller via at least 3 output signals: Z UP, Z DOWN, and ARC-OK, there may be more, I'm not sure since I'm not using it. In theory, there shouldn't be THC induced Z error in this control scheme, since grbl is always managing Z and keeping track of position, because the control is closed loop involving the THC monitoring arc voltage and telling grbl what direction to move Z. So for folks using this model, I'd like to know if they like it, if it does work like that and work well. DANI makes a clone of this model also. grblHAL is designed for this type of THC unit.

Back to the pesky THC SD model, I have attempted to mitigate the THC induced Z error with a digital THC Z Anti-Dive circuit, which hijacks the THC Z STEP and DIR signals in cases of it otherwise diving Z into the cutting surface, such as when XY cornering and stopping. This circuit also allows SC Path Rules 'on ... corner', 'before end', and even 'on start' to help mitigate THC Z diving, but the circuit's main function is to hijack (block) the THC Z signals automatically based on monitoring realtime XY speed as grbl manages speed with motion acceleration and deceleration. Getting all of this dialed in so it results consistently at or less than 0.2mm of Z error/shape cut has proven to be daunting to say the least. The Proma THC SD SPD setting (its STEP frequency) and DLY setting (its Z signal hijack delay) are finicky and seem to need adjustment for in a wide range of XY feedrates, such as > 2000mm/m vs. those less, but that's a ballpark demarcation line. My most recent "fix" to the THC induced Z error is learning to live with it and avoiding Z probe and retract alarms by homing the Z axis every 10 to 20 shape cuts. I have adjusted my scpost to plant $HZ grbl Z homing commands in the gcode to do this, and it's proven to be mitigating the problem by nullifying the Z error before it accumulates large enough to trip an alarm. See my scpost V26.5 for this code. It seems kludgy but it works quite well to erase the error for another 10 - 15 cuts and then repeat; this is in addition to the usual Z zeroing via torch probe (ohmic or floating head) cycle on a per-cut basis. The plasma cut quality is exceptional, so I have no other reason to replace this scheme. However, if I build another plasma table, I will use a THC that is either integrated into or well behaved with the CNC controller.

That's my story. Please let me know if you have similar or other experiences with these standalone THC Z motor hijackers, or if you have similar problems even with the integrated and well behaved models.

Thanks,
Lou

[bLouChip]

cross linking to same discussion in plasmaspider forum: https://plasmaspider.com/viewtopic.php?p=233927#p233927

[bLouChip]

I made an improvement to my THC Z Anti-Dive Circuit (ADC) which made the THC Z STEP blocking more symmetrical in terms of STEP count on the way in to and out of a sharp XY corner. This made a significant difference in lowering the amount of THC Induced Z Error (THC-IZE).
See the full test and results documented here: https://plasmaspider.com/viewtopic.php?p=234032#p234032

take care,
Lou