using a hand wheel encoder

andypugh wrote:

dannym wrote:

Big fan of the XHC HB04 wireless MPG pendant.

One drawback of these is that they are USB and so are subject to timing issues with the non-realtime parts of the system.

This is not likely to be a problem with the MPG as all that might happen is some pulses coming late. Missing a key-up event on a continuous jog is rather more of a potential issue.

Just something to be aware of rather than a reason not to consider them.

I don't see how. There is a lag, but the lag in the USB is far less than the lag in a large mill system. That is, in an ordinary physical handwheel, there can be no lag between turning the wheel and leadscrew angle.

In a CNC mill, there's acceleration issues, and nothing prevents you from physically spinning the wheel faster than the axis can keep up.

Now on the XHC's Mach3 driver, when I say "the driver sucks!" it's because it drives the axis at a fixed speed, if you turn faster, the axis won't speed up more, and steps are actually honest-to-god lost. If you spin X+ 5 turns real fast, then X- slowly the same 5 turns, you will end up with X more negative than your starting point because it discarded the motion it couldn't keep up with. But AFAIK the communication link gave all the pulses, the dumb driver didn't accommodate all of them and simply discarded rather than caching the motion it didn't keep up with.

IIRC I tried speeding up the axes' jog rates but the jerking in single-step was stupidly high, and it conflicted with practical use of the keyboard jogging. I don't know if it's a Mach3 engine problem or the XHC designers didn't know what they were doing. It needs to recalculating a new trajectory like 10x/second and only use high speed when the target location is far away, and not create more than 1/10th of sec of fixed trajectory plan at once because the target can change.

So that problem need not repeat in LinuxCNC, that's a Mach3 problem. I don't think the XHC link lost pulses.

Actually, well, the protocol was documented by users and IIRC it sends pulses, not absolutes- which means if the XHC is held in a position where it loses comm and rotated, it would break the relationship between handwheel absolute position and machine, and the driver wouldn't be able to fix that. But the DRO on the pendant would stay correct.

I have a original handwheel on my machine panel that I wired up to the encoder inputs of a 7i84 card.
When testing I need to move the MPG 4 ticks to get the count-value increased by one.
So obviously my handwheel is 25ppr and supposed to be 4x evaluated. How do I configure 7i84 for 4x count mode?

One way it can be done is with setsserial (man setsserial) but first you need the full name of the
7I84s non-volatile encoder mode parameter. To determine this, start linuxcnc and find the 7I84
parameter that ends in "nvencmode0" and reply with the full name here

BTW:
Sserial remotes that support MPGs have 24 encoder modes,
default mode is 0 which is 1X forward mode. Mode 1 is 1X reverse mode.
4 is 4X forward mode, 5 is 4X reverse mode, 2 is 2X forward mode and 3
is 2X reverse mode, 9 is up/down forward mode and 13 is increment/decrement mode.

The encoder connected my MPG is: hm2_7i80.0.7i84.0.1.enc0.count

Using setsserial (following guide on setsserial manpage) I set hm2_7i80.0.7i84.0.1.nvencmode0 to 4, then powercycled boards and restarted linuxcnc.
I verified with Halshow that the parameter was set to 4.

But still I need to turn my handwheel 4 ticks to get one count, exaclty as before the parameter change.

You will need to power cycle the 7I84 for the EEPROM setting to be used for the encoder mode setting

I was editing my post at the same time as you answered. By restarting boards i meant powercycling.

did you power cycle the field (24V) power?

Yes
And to be sure, I now powercycled all power to the whole machine and waited some time with power off.

And you are using mpg enc0?