Possible to access a HAL OUT pin for jog count backlog
- DauntlessA
- Offline
- Junior Member
-
Less
More
- Posts: 21
- Thank you received: 5
30 Jul 2025 22:09 #332575
by DauntlessA
Possible to access a HAL OUT pin for jog count backlog was created by DauntlessA
For axis or joint jogging, there are HAL IN pins for jog-counts. For example, for axis jogging there is axis.L.jog-counts IN S32.
When movement is permitted (enable pin high, in manual mode, not at a soft limit etc) a change to the jog-counts pin will cause movement.
Since the jog is incremental, normally the value of the pin is increased incrementally by the control method (such as a jog wheel), not set to a specified value.
This means that there is potential for a backlog of incremental jog movements to be accumulated, if the rate at which the incremental logs are executed in one direction exceeds the rate at which the jog counts pin has changed.
This manifests as a continuous jog which ends once the backlog has been cleared.
My question is, is there currently any way of accessing the number of counts which make up this 'backlog'?
Or accessing an analogous value such as the DTG for the joint/axis if the backlog of jog counts is summed?
This data should exist in some form in the motion planner, so it should be possible to get it into a HAL OUT pin.
GStat does seem to have a get_jog_increments function, but since the other arguments reference GStat's internal jog parameters, so I think this just returns what was set by the set_jog_increments function.
In summary (as far as I know), there is an IN pin for jog counts, but no OUT pin which actually indicates how many counts are 'queued' in the motion planner.
Is it possible to make this into a HAL pin in a current installation?
Or what might be changed in the current motion planner to make this value a Stat/GStat attribute or HAL pin?
Thanks!
When movement is permitted (enable pin high, in manual mode, not at a soft limit etc) a change to the jog-counts pin will cause movement.
Since the jog is incremental, normally the value of the pin is increased incrementally by the control method (such as a jog wheel), not set to a specified value.
This means that there is potential for a backlog of incremental jog movements to be accumulated, if the rate at which the incremental logs are executed in one direction exceeds the rate at which the jog counts pin has changed.
This manifests as a continuous jog which ends once the backlog has been cleared.
My question is, is there currently any way of accessing the number of counts which make up this 'backlog'?
Or accessing an analogous value such as the DTG for the joint/axis if the backlog of jog counts is summed?
This data should exist in some form in the motion planner, so it should be possible to get it into a HAL OUT pin.
GStat does seem to have a get_jog_increments function, but since the other arguments reference GStat's internal jog parameters, so I think this just returns what was set by the set_jog_increments function.
In summary (as far as I know), there is an IN pin for jog counts, but no OUT pin which actually indicates how many counts are 'queued' in the motion planner.
Is it possible to make this into a HAL pin in a current installation?
Or what might be changed in the current motion planner to make this value a Stat/GStat attribute or HAL pin?
Thanks!
Please Log in or Create an account to join the conversation.
- andypugh
-
- Offline
- Moderator
-
Less
More
- Posts: 23415
- Thank you received: 4976
31 Jul 2025 12:00 #332595
by andypugh
Replied by andypugh on topic Possible to access a HAL OUT pin for jog count backlog
To not answer your question....
If the backlog of counts is causing a problem, you can enable:
joint.N.jog-vel-mode IN BIT
When FALSE (the default), the jogwheel operates in position mode. The joint will move exactly jog-scale units for each count, regardless of how long that might take. When TRUE, the wheel operates in velocity mode - motion stops when the wheel stops, even if that means the commanded motion is not completed.
If you can find where in the motion code the "backlog" exists then you could connect it to one of the supplied "debug" parameters:
github.com/LinuxCNC/linuxcnc/blob/master...motion/motion.c#L556
These are already set up in the code, you just need to assign values to (for example) emcmot_hal_data->debug_float_0 to see that number in the HAL.
(and recompile LinuxCNC)
If the backlog of counts is causing a problem, you can enable:
joint.N.jog-vel-mode IN BIT
When FALSE (the default), the jogwheel operates in position mode. The joint will move exactly jog-scale units for each count, regardless of how long that might take. When TRUE, the wheel operates in velocity mode - motion stops when the wheel stops, even if that means the commanded motion is not completed.
If you can find where in the motion code the "backlog" exists then you could connect it to one of the supplied "debug" parameters:
github.com/LinuxCNC/linuxcnc/blob/master...motion/motion.c#L556
These are already set up in the code, you just need to assign values to (for example) emcmot_hal_data->debug_float_0 to see that number in the HAL.
(and recompile LinuxCNC)
Please Log in or Create an account to join the conversation.
- DauntlessA
- Offline
- Junior Member
-
Less
More
- Posts: 21
- Thank you received: 5
01 Aug 2025 01:05 #332615
by DauntlessA
Replied by DauntlessA on topic Possible to access a HAL OUT pin for jog count backlog
Andy,
Thanks so much!
I had a dig through some of the motion planner, and it seems when an incremental jog is commanded by the GUI using NML, then this is the associated case in:
github.com/LinuxCNC/linuxcnc/blob/master...otion/command.c#L841
If the incremental jog is accepted, if it is a joint jog (free mode), it seems to handle all of the logic there, with the target position assigned as follows:
Whereas, if it is an axis jog (teleop mode), it will call the functionin:
github.com/LinuxCNC/linuxcnc/blob/master...c/motion/axis.c#L279
So, for both joint and axis, the way the position is assigned is essentially the same, it modifies either the value of or by the value of the jog incremental offset.
These would be the hal pins... which actually already exist as and !
I thought I'd tried the axis ones already but I must've forgotten to home the sim and since I had the joint jogging pins connected as well I didn't realise I wasn't using teleop
But yeah, the 'backlog' of incremental jog-counts is just converted into a teleop or free mode motion planner position (which explains why a backlog acts just like a continuous jog).
And, yes, I did sort of avoid saying why I was looking into this (sorry!), wanted to see if this way would work first!
I was looking at meister 's camjog widget
github.com/multigcs/riocore/blob/main/ri...ons/camjog/camjog.py
It jogs via jog-counts (which is definitely the best way to do this), but the only drawback is that it can move in a dogleg if one joint or axis takes longer than the other to reach the destination.
But, if you compare the 'jog DTG' (my test assumes both have the same max velocity) for x/y (or the joint equivalent), you can scale down the velocity of the joint/axis which has the smaller DTG according to its proportion against the joint/axis which has the larger DTG, and then use that to scale the milltask joints/axis max_vel pins.
And the other required logic is that if at least one of the joints/axes is within positional tolerance of the target position, the velocities of both the joints/axes need to be set back to 100%.
Anyway, this is sort of trying to force free or teleop mode to act like coordinated mode. It's quite similar to anglejog, actually,
but it acts later by calculating the 'Jogging DTG' from existing counts with the same scale (from camjog) and modifying the velocities to follow the resultant instead of calculating the counts itself.
I'll try and flesh out the component a bit more now I know it works.
Also, I still can't figure out why joint jogging is still doglegging It's not a big deal for me as long as axis jogging works but I want to know why it's not working
Thanks so much!
I had a dig through some of the motion planner, and it seems when an incremental jog is commanded by the GUI using NML, then this is the associated case in
motion/command.c
github.com/LinuxCNC/linuxcnc/blob/master...otion/command.c#L841
If the incremental jog is accepted, if it is a joint jog (free mode), it seems to handle all of the logic there, with the target position assigned as follows:
/* set target position for jog */
if (emcmotCommand->vel > 0.0) {
tmp1 = joint->free_tp.pos_cmd + emcmotCommand->offset;
} else {
tmp1 = joint->free_tp.pos_cmd - emcmotCommand->offset;
}
Whereas, if it is an axis jog (teleop mode), it will call the function
void axis_jog_incr(int axis_num, double offset, double vel, long servo_period) {}
axis.c
github.com/LinuxCNC/linuxcnc/blob/master...c/motion/axis.c#L279
if (vel > 0.0) {
tmp1 = axis->teleop_tp.pos_cmd + offset;
} else {
tmp1 = axis->teleop_tp.pos_cmd - offset;
}
So, for both joint and axis, the way the position is assigned is essentially the same, it modifies either the value of
free_tp.pos_cmd
teleop_tp.pos_cmd
These would be the hal pins... which actually already exist as
joint.N.free-pos-cmd
axis.L.teleop-pos-cmd
I thought I'd tried the axis ones already but I must've forgotten to home the sim and since I had the joint jogging pins connected as well I didn't realise I wasn't using teleop
But yeah, the 'backlog' of incremental jog-counts is just converted into a teleop or free mode motion planner position (which explains why a backlog acts just like a continuous jog).
And, yes, I did sort of avoid saying why I was looking into this (sorry!), wanted to see if this way would work first!
I was looking at meister 's camjog widget
github.com/multigcs/riocore/blob/main/ri...ons/camjog/camjog.py
It jogs via jog-counts (which is definitely the best way to do this), but the only drawback is that it can move in a dogleg if one joint or axis takes longer than the other to reach the destination.
But, if you compare the 'jog DTG' (my test assumes both have the same max velocity) for x/y (or the joint equivalent), you can scale down the velocity of the joint/axis which has the smaller DTG according to its proportion against the joint/axis which has the larger DTG, and then use that to scale the milltask joints/axis max_vel pins.
And the other required logic is that if at least one of the joints/axes is within positional tolerance of the target position, the velocities of both the joints/axes need to be set back to 100%.
Anyway, this is sort of trying to force free or teleop mode to act like coordinated mode. It's quite similar to anglejog, actually,
but it acts later by calculating the 'Jogging DTG' from existing counts with the same scale (from camjog) and modifying the velocities to follow the resultant instead of calculating the counts itself.
I'll try and flesh out the component a bit more now I know it works.
Also, I still can't figure out why joint jogging is still doglegging It's not a big deal for me as long as axis jogging works but I want to know why it's not working
Please Log in or Create an account to join the conversation.
Time to create page: 0.109 seconds