THC Up/Down Step rate adjustment

[fireup924]

How can I control the step rate of the Z axis in Up/Down mode? It seem it has only one speed. I'm using with RP2040

[terjeio]

Currently the step rate is fixed at 1 KHz. Not sure if I should use accelerated/decelerated moves instead - similar to jogging.

[bLouChip]

my 2 cents... THC Z feedrate is important, needs to be operator adjustable at least for cases of extreme range of XY feedrate. Consider cases cutting corrugated 26ga. sheetmetal w XY feedrates 5000+mm/min; or aluminum 10ga. diamond plate diamond side up. Consider a new config setting (optional) which allows THC Z feedrate to be auto adjusted as a factor of XY feedrate. I'm not sure if the relationship is linear or exponential, but experiment with linear first.

Seems as though Z axis accel/decel would have to be respected else you risk losing steps which means loss of known position. Position not so important during THC closed loop feedback motion, but certainly very important in all other aspects of Z motion in the job.

[fireup924]

accelerated/decelerated similar to jogging would be great.

[terjeio]

Consider a new config setting (optional) which allows THC Z feedrate to be auto adjusted as a factor of XY feedrate. I'm not sure if the relationship is linear or exponential, but experiment with linear first.

$682 is added in the latest commit, it is a percentage of the real-time XY feed rate - used both for up/down and voltage control, default is 5%. The 5% default and what I assume is a linear relationship is adopted from Langmuir THC documentation.

Up/down control now uses continuous motion that is cancelled when the up/down signals are deasserted, on cancellation the motion is decelerated to a halt. Note that the Z-axis acceleration and/or THC hysteresis must be set high enough to not trigger the opposite motion after the THC triggered motion is complete.

I am considering halting or raising a alarm if the up/down signals get messed up - either when asserted simultaneousely or when stuck. They should also be checked before starting THC? What do you think?
The Langmuir implementation has a setting for the minimum programmed XY feedrate for which THC will be enabled, I wonder if this should also be implemented?

[bLouChip]

$682 is added in the latest commit, it is a percentage of the real-time XY feed rate - used both for up/down and voltage control, default is 5%.

That's good, but seems like 5% of XY feed is very low. I read the Langmuir description of this feature, and their example of Z4" / XY48" (actually 8.3%). However, considering accel/decel factor that you seem to be implementing, most of the time THC is adjusting Z it's less than the XY factored rate anyway. I believe you should use a default factor which equates closer to the value you had been using, 1KHz = 1000 steps/sec = 5mm for Z @ 200steps/mm which is typical. Consider 3000mm/min as avg XY feed, = 50mm/sec XY feed. 5/50 = 10% as a factor on avg equal to your previous 1KHz.

The Langmuir implementation has a setting for the minimum programmed XY feedrate for which THC will be enabled, I wonder if this should also be implemented?

I didn't see minimum, rather I read Langmuir had a maximum 'clamping' Z feed of 60 IPM, = 1524mm/min. That seems low also. Consider cutting corrugated 22ga sheetmetal, with near 45* corrugated inclinations, that's likely cutting at least at 3000mm/min even at 30A. That may be the most extreme case. Seems like 3000mm/min should be the max clamping, most Z configs should be able to handle that, again these are short bursts. Consider using $112 for the max clamping feedrate, that way less likely to overdrive the motor and lose steps, which means loss of Z position accuracy over time.

Note that it's not possible to convert THC Z motion to normal grbl coordinated XYZ motion, as all axes will move at the slowest axis max feedrate. Thus, I'm assuming you are using your own accel/decel trajectory calcs when driving THC Z.

[terjeio]

However, considering accel/decel factor that you seem to be implementing, most of the time THC is adjusting Z it's less than the XY factored rate anyway.

Stepper parameters are taken from the $1x2 settings.

I believe you should use a default factor which equates closer to the value you had been using, 1KHz = 1000 steps/sec = 5mm for Z @ 200steps/mm which is typical.

The default can be changed, but some testing should be done first? I have started building a plasma machine so hopefully I will be able to do it myself soon.

The Langmuir implementation has a setting for the minimum programmed XY feedrate for which THC will be enabled, I wonder if this should also be implemented?

I didn't see minimum, rather I read Langmuir had a maximum 'clamping' Z feed of 60 IPM, = 1524mm/min.

See the Torch Speed CUTOFF Setting section in the Langmuir documentation. Perhaps I have interpreted it incorrectly?

Consider using $112 for the max clamping feedrate, that way less likely to overdrive the motor and lose steps, which means loss of Z position accuracy over time.

The calculated feed rate is clamped to max. for Z.

Thus, I'm assuming you are using your own accel/decel trajectory calcs when driving THC Z.

Correct, Z is driven directly via a separate step generator.

[bLouChip]

See the Torch Speed CUTOFF Setting section in the Langmuir documentation. Perhaps I have interpreted it incorrectly?

Okay, got it, read it. This setting is also referred to as "XY Feedrate Anti-Dive %", see Masso controller G200 code, A parameter. This should certainly be implemented, I actually thought it already was ! I recommend you name the feature "XY Feedrate % for Z Anti-Dive". This is a huge plasma process cut quality feature.

Understand that I bought all the grblHAL hw (Phil's BOB) but have yet to implement it; this was a few years ago when you and I worked on the G94 G1XAF rotary feedrate bug. grblHAL was my backup plan to implement if I couldn't get source code for my grbl v1.1i 4 axis fork from MillRightCNC. They were happy to work with me, gave me the source code, so I fixed what I already had setup as a controller. I do use the Teensy 4.1 chip running grblHAL for office/bench testing, no machine connection ;) In my grbl 4 axis controller, I implement Z Anti-Dive with TTL logic, integrated with my Proma THC SD (autonomous THC).

I agree with your other Plasma THC design improvements. Good luck with it. Perhaps this winter I will finally build Phil's BOB for grblHAL and retrofit to my muti-process CNC, MillRight MegaV XL (900x900x100), runs laser, plasma, milling processes.

[fireup924]

I tried the new version (Build 20250829) but it does not produce any pulses on the Z-axis when up/down signal are active.

Status show that input signal is working as it reports: THC:0.0,ATED or THC:0.0,ATEU

[terjeio]

I tried the new version (Build 20250829) but it does not produce any pulses on the Z-axis when up/down signal are active.

Fix committed, the RP2040 uses polling to drive the Z motor and I forgot to enable that for up/down mode when changing from fixed step frequency. BTW are you compiling with the Web Builder?

Okay, got it, read it. This setting is also referred to as "XY Feedrate Anti-Dive %", see Masso controller G200 code, A parameter. This should certainly be implemented, I actually thought it already was ! I recommend you name the feature "XY Feedrate % for Z Anti-Dive".

It was implemented but not for up/down mode, added in the latest commit. Threshold is set by $356 (Plasma THC VAD threshold), default is 90%. Turn on threshold is hard coded to 99% - taken from LinuxCNC specs.

[bLouChip]

It was implemented but not for up/down mode, added in the latest commit.

up/down mode... That explains why I was confused on $356 VAD having former implementation. I now see the 'Mode' column of the feature description table, it's not labeled '0,1,2', I guess it will be soon ;)

Please confirm for me and others, up/down mode (2) is for semi-autonomous THCs like Proma 150, which have their own DRO and button/programming for most of the $353-355, 357 features, self-contained, independent of grblHAL. At least that has been my understanding.

Your doc clearly put $356 VAD clearly in that same category, but it didn't register with me since I was logically thinking the THC doesn't know the XY feedrate, so it must be a doc omission, why would it not apply to mode 2. Well, now we all know that it does apply as of your latest fix. Thanks. :)

So for further clarification for me and perhaps others please, for THC modes 0 and 1... are these only for @phil-barrett THC module/project ?

[terjeio]

Please confirm for me and others, up/down mode (2) is for semi-autonomous THCs like Proma 150, which have their own DRO and button/programming for most of the $353-355, 357 features, self-contained, independent of grblHAL.

Can confirm - it is for THCs that provide up/down signals to the controller. For THCs that take over control of the Z motor, or for setups that does not use THC, mode 3 can be used (only Arc ok input is required).

So for further clarification for me and perhaps others please, for THC modes 0 and 1... are these only for #6?

The readme is out of sync, updated now... Mode 0 is THC disabled, 1 is voltage controlled THC inplemented in grblHAL. Voltage mode reads analog input via the HAL and has no dependency on what kind of hardware that provides the input. Some controllers supports analog input via integrated MCU AD convertes, some via I2C connected AD converters (such as Phil's board), some both. The RP2040 driver can also read input from a Mesa THCAD2 converter, I may add support for this to more drivers later. Other means for reading analog input can be added as needed provided that the board has the required port(s) available. One could be to use I2S over optical cable...

[fireup924]

Fix committed, the RP2040 uses polling to drive the Z motor and I forgot to enable that for up/down mode when changing from fixed step frequency.

Thanks, seems to work now.

BTW are you compiling with the Web Builder?

I'm compiling using VisualMicro + VisualStudio with the Arduino Compiler. I have some C++ libraries that I need to add on top of grblHAL.