What Function/Pin accepts velocity values from Gcode?

I've been running the proma thc config for a while now on a few different tables. It works great but there are a few tweaks I'd like to make, some I've been successful with, others, not so much.

Config: forum.linuxcnc.org/49-basic-configuratio...hc-config-that-works

This config uses hal to control the Z axis so no up/down commands come from the Gcode. In the initial setup, you define your max velocity parameter for the Z axis and that is the speed at which the z axis probes the material, retracts after a cut and adjusts height based on the THC feedback signals and step size defined.

I spent a bunch of time tracing the logic routes in this config to get an understanding of how this works and the break is done here:net PosZ-cmd axis.2.motor-pos-cmd => stepgen.2.position-cmd. The stepgen.2.position-cmd is getting its position values based on a few sum.2 functions. When I look at what is being passed to stepgen.2.position-cmd, its a coordinate value but no velocity value, the max velocity value is the default.

I found a few gates I could trigger off of to say, when this is triggered, your velocity should be X, when its not triggered, your velocity should be Y. My problem is I don't know where to pass these velocity values.

Can anyone give some insight on how the velocity values get passed or if I'm just missing something simple?

Thanks in advance.

Attached a pic of my latest table build. 4'x4' Plasma

For the Toma, related to Proma THC, there are value's available if you google.
The value's are related to this forum. Many is written about Toma. Toma is masterpiece of code.
Toma is not active i think at the last time. Maybe he thinks, leave me alone.

But the new branche is external offsets. Mr Roddw from this forum know's all about this. His time
is limited.

In short. The linux combination with plasma is almost hd-plasma ready. But there are some difficulties to
eliminate this year. This is sent to you from a non mesa user.

The upper left side of your machine looks very sharp in first sight. But in overall your picture is very good in first sight.
Many users are afraid to post pictures. It is only good to post pictures. For me you did a good hardware job !!!

Thanks for the feedback on the config and the machine. I agree the proma code is an incredible configuration. I've used it on several machines but as you mentioned there are a few tweaks that could make it better.

I've been able to add a THC disable button, increase the timing since my PC is more than capable and swap to trivkins instead of gantrykins since the config implies no home switches and I didnt see a need to use gantrykins.

My next few initiatives were to add a different probe speed, use the spindle at speed function to hold the feed until I can rapid down to cut height after the pierce and upgrade to 2.8 master for the homing sequence for a gantry with dual motors. I'm nearly there with the rapid to cut height but having two different Z speeds was something I couldn't figure out.

I'm going to try a different route to test today by using adaptive feed control. Since the Z sequence I'd like to slow down is all contained within the M3 command I'm going to try turning on adaptive feed to some percentage of the max velocity prior to M3. Then shutting it off immediately after the M3. Hoping to slow down the Z speed for the probe sequence and then speed it back up when the THC takes over.

Will report back if this works.

Side note: I was also thinking to use custom Mcodes m100 and m101 to set the max velocity parameter but unless I understand incorrectly the parameter values are only read at startup.

Grotius wrote:

But the new branche is external offsets. Mr Roddw from this forum know's all about this. His time
is limited.

I'm not sure if my time is limited or I'm lazy!

Actually life has moved on and I'm now building a business so I really need to focus on that rather than hobbies. A number of us have given the external offsets branch a try and have not had much luck but it has taken us onto other things that are working for a couple of others.

Grotius wrote:

In short. The linux combination with plasma is almost hd-plasma ready. But there are some difficulties to
eliminate this year. This is sent to you from a non mesa user.

I have to agree with Grotius here. LinuxCNC has been well behind in plasma control but over the last 12-24 months much greater capability is emerging and PID control is being used to control torch height. Soon the mountain will be conquered and we won't need any external THC hardware, just a way to measure torch voltage and in this regard the USD $69 Mesa THCAD card is hard to beat.

Grotius wrote:

The upper left side of your machine looks very sharp in first sight. But in overall your picture is very good in first sight.
Many users are afraid to post pictures. It is only good to post pictures. For me you did a good hardware job !!!

And yes, it is a nice machine. Well done!

Now in answer to your questions, motion.requested-vel is the velocity requested by the trajectory planner. This is not the same as the gcode F rate as on short, sharp segments, the feed rate cannot be achieved.

So you tell Linuxcnc the feed rate with an F command in your G code and Linuxcnc determines how close it might be able to get to that and sets motion.requested-vel and then the machine tries to achieve that. The current velocity at any given time is available as motion.current-vel.

From there, I would look at the C source code for the THCUD and THC components. THCUD is similar to your Proma

Thanks for the details, I guess the end result is that there is no way for me to manually pass that velocity parameter since the trajectory planner is whats actually determining what can be done based on gcode requested feedrate.

I tried both custom Mcodes for overwriting the max velocity parameter as well as g52 to try and slow down the probe but no luck. Back to the drawing board I guess.

My main issue is not being able to get the torch down to cut height fast enough on cuts that have a limited lead in length. Since I cant have multiple speeds on the Z axis I'm going to go back to chasing the route to push the torch down to cut height prior to starting the lead in.

Side note, I did have success at getting the 2.8 gantry homing sequence to work which was a nice victory.