MPG encoder count by 4?

I am wiring up my MPG... This is a single ended MPG so it take +5v, 0v, and returns A Pulse and B Pulse... It is counting (so that is great) but in multiples of 4 so 0,4,8,12... (in both directions so 0,-4.-8.-12 and so forth).

I tried changing W10,11,13 from right (default) to left but when I do that I get no counting at all...

should I just account for this in my HAL MPG Increment calculations or is this mis-count a sign of something else wrong?..

Current wiring (because I am using the Spindle encoder for this) is :
* A Pulse - TB3-7
* neg (0v) - TB3-9
* B Pulse - TB3-10
* Positive (+5v) - TB3-12

and I haven't set anything up in the HAL yet, so I am just looking at the data coming out of HAL Configuration's Watch Tab on Encoder 08/09 (the two encoders share the same values because its the last or 10 encoders, the other 8 being on my 7i89 card).

Thanks

What card are you using? Does it have dedicated MPG pins like the 7i76e?

It is a 7i76e and I am using the spindle encoder pins.

Thanks

jhandel wrote: It is a 7i76e and I am using the spindle encoder pins.

Thanks

Why not use the pins that are dedicated for running MPGs?

Several reasons.
1) not running in software mode 2 (not sure how to set the mode actually

2) using all the inputs for other things (5 axis machine with ATC, so lots of inputs)

3) I’m using an encoder port (spindle encoder) not sure why it shouldn’t work (or maybe it is)

As I understand it the encoders are different. Maybe you have found the difference! Maybe you can mult2 by 0.25 before using the encoder count output but I think there would be a lot of hal overhead to get to the right data type. Maybe it would be cleaner to write a custom component that only output a count on every 4th step? that would be pretty simple using integer division.

eg

The high speed encoders lack the 1x mode that the MPG
encoders support, so with a 100 PPR MPG dial you will get
400 counts per turn. One thing to do if you use a high speed
encoder for a MPG is to scale the jog increment by 1/4. This does
mean that every MPG detent crossed will result in 4 smaller jogs.

A better way is to use the 7I76Es built in MPG encoders
that do support 1X mode by default so you get 1 count per detent.
You do this by setting the sserial port mode to 2 by adding a
statement like "sserial_port_0=20xxxx" in the loadrt hm2_eth
config string. If you only have one MPG , you will only lose 2
digital inputs by doing this

open "custom_postgui.hal"

setp encoder.0.x4-mode 1

change with:

setp encoder.0.x4-mode 0

linuxcnc.org/docs/html/man/man9/encoder.9.html

fery15sty wrote: open "custom_postgui.hal"

setp encoder.0.x4-mode 1

change with:

setp encoder.0.x4-mode 0

linuxcnc.org/docs/html/man/man9/encoder.9.html

I am not sure that works with the Mesa-card based encoders, but I'll give it a look..

Thanks

PCW wrote: The high speed encoders lack the 1x mode that the MPG
encoders support, so with a 100 PPR MPG dial you will get
400 counts per turn. One thing to do if you use a high speed
encoder for a MPG is to scale the jog increment by 1/4. This does
mean that every MPG detent crossed will result in 4 smaller jogs.

A better way is to use the 7I76Es built in MPG encoders
that do support 1X mode by default so you get 1 count per detent.
You do this by setting the sserial port mode to 2 by adding a
statement like "sserial_port_0=20xxxx" in the loadrt hm2_eth
config string. If you only have one MPG , you will only lose 2
digital inputs by doing this

Thanks, I was thinking about the 1/4 increments as an option. I mostly wanted to make sure this was expected behavior and wasn't a sign I screwed something up in the wiring...

I really am using almost all of my inputs so moving to software mode 2 would require combining some inputs (like limits) and loosing fidelity on input data..

Thanks for the suggestion, and sharing how to switch to Software Mode 2..