jog increment - problems

linuxcnc 2.8.4-1

Requirement:

    MPG wheel for finer control of lathe Z axis
    momentary SPDT switch for faster Z +- traverse.

Relevant part of hal:

setp axis.z.jog-enable TRUE
setp joint.1.jog-enable TRUE
setp halui.axis.jog-speed 500
setp halui.joint.jog-speed 500
setp halui.joint.1.increment 0.01
setp halui.axis.z.increment  0.01

# btn-pinkie and btn-base2 are connected to momentary switch, to traverse -ve or +ve
net my-jogminus halui.axis.z.minus halui.joint.1.minus <= input.0.btn-pinkie
net my-jogplus  halui.axis.z.plus  halui.joint.1.plus  <= input.0.btn-base2

net mpg-a encoder.0.phase-A <= parport.0.pin-17-in
net mpg-b encoder.0.phase-B <= parport.0.pin-16-in

setp axis.z.jog-scale 0.01
setp joint.1.jog-scale 0.01
net encoder-count joint.1.jog-counts axis.z.jog-counts <= encoder.0.counts

What I had expected:

traversing via jogging increment-plus/minus (i.e. when instructed by btn-pinkie or btn-base2) to do so in steps of halui.joint.1.increment or halui.axis.z.increment.

What I observed:

Z value on Axis display increments to the displayed 3 decimal places (0.001) rather than the 0.01 I intended. This is both when homed and not homed.

(The figures encoded are not necessarily intended for practical purposes).

What am I doing wrong, and how can I achieve what I intend?
 

I don't know a solution, but the error is in waht you expect from `halui.joint.N.minus` and `halui.joint.N.plus`. The description on the man-page  says: pin for jogging joint N in negative direction at the halui.joint.jog-speed velocity.

This means the axis will move as long as your button is pressed, which does not have any relation to the jog increment. This function can be seen as pressing the continuous jog-function in your UI. 

If you want to jog with precise increments, you should use the pins 'halui.joint.N.increment-minus' and 'halui.joint.N.increment-plus'. with the description: a rising edge will will make joint N jog in the positive/negative direction by the increment amount. However, this does not allow for continuous jogging.



 

Further reading and thinking had led me to conclude my interpretation was wrong, and I was asymptotically reaching your conclusion.

I am now looking at if it's possible to use a stepgen component to trigger increment-plus/minus when an external switch is flipped. Considering my current state of ignorance this could take some time.

frogandspanner wrote:

linuxcnc 2.8.4-1

Requirement:

    MPG wheel for finer control of lathe Z axis
    momentary SPDT switch for faster Z +- traverse.


 

If I understand your post, you want:

• Selector switch to choose an axis
• Selector switch to choose jog increment
• MPG to command an incremental jog
• Momentary buttons to command continuous jog

That's how I set up my machine recently, and I've got a working config if you want it.  Mine is more complicated than what I think you want as I needed another component to adjust the jog-speed scale between linear and a rotary axis.

In addition, my MPG will also adjust the feed & speed overrides,as well as the jog-speed (for continuous).

I based my MPG on a superb example found in the forum:
forum.linuxcnc.org/47-hal-examples/42913...ple-mpg-hal-s#213032

Using that as a base I then expanded & added the other logic.

NOTE 1: I've arranged my HAL logic in to multiple files - it's easier to find the section I need, but it may be difficult for a novice to follow.  Best advice I can give is to install VSCode and open the multiple files in split-screen so its easier to see connections which span files.

NOTE 2: the 'loadrt' and 'addf' for all components are in a separate HAL file.  It's not necessary to post it (it's long and complicated) as you can just make a list of all components in the two files I've attached and add them as needed to the loadrt part of your file(s).

NOTE 3: the bulk of the logic is in MPG.hal.  The continuous pushbuttons are in IO.hal, and the signals are 'used' in MPG.hal

NOTE 4: there is a hal component (blink.comp) in IO.hal that isn't part of the standard LCNC component library.  I found it buried on the forum from years ago and it's insanely useful for turning something on/off (like an LED) at regular intervals.  You won't need it for your MPG logic, but figured I'd mention it in case you tried to look it up in the LCNC docs (it isn't there).

NOTE 5: if you're using a commercial MPG, I've found that the 'cheap' ones (non-USB) all use the same 12-position selector switches, regardless of if they're marketed as 4-axis, 5-axis, or 6-axis.  With a bit of wiring fandango, you can easily add more connections to each selector switch - thus permitting additional axes, functions, or increments.

Let me know if you need any of it explained.

-R

 

>If I understand your post, you want:

> Selector switch to choose an axis
> Selector switch to choose jog increment
> MPG to command an incremental jog
> Momentary buttons to command continuous jog

Not quite.

I am currently only controlling lathe Z. (In future I plan another MPG &c for the x axis).
I use an MPG to increment/decrement (halui.axis.z.minus halui.joint.1.minus).
I have a momentary switch to slew + or - at a higher rate than I can crank the MPG.
I want the high-speed slew to go up/down in the same increments as the MPG - just faster.

I think I understand now: the momentary buttons will be a 'fast' MPG?  i.e. a steady-rate of incremental moves?

Something to consider is that when you jog in increments the motion may be jerky.  If you have a lathe with a high-inertia carriage you might not like the resulting movements.

Can I ask about your use-case where a 'normal' continuous jog wouldn't be desired, but a steady-rate fast incremental jog would be preferred?

This part I don't understand:
I use an MPG to increment/decrement (halui.axis.z.minus halui.joint.1.minus).

Why are you using a MPG with halui to jog?
MPGs are usually used with motion's joint/axis.L.jog-counts
linuxcnc.org/docs/2.9/html/man/man9/motion.9.html#AXIS%20PINS

The reason for thinking of rapid incremental is that when I stop rapid traverse I want the position to be in the same increments as used by the MPG. e.g. if I rapid traverse to -0.0007 and I am using increments of 0.001 on the MPG I would like the position (actual and enumerated) to be rounded to -0.001 so that I can then use the MPG to move to 0.000.

Perhaps my question was tainted by my thoughts on implementation.

I apologise to others for not getting back to their suggestions yet, but for me this work is a learning process, so I am happy to follow any blind alleys I might construct as this is what learning is about.

I found an example somewhere which I blindly followed, such is the price of ignorance.

I'll have a look at your suggestion (although as the present method works I'll put that on the back burner).