7i96S mesa_modbus encoder count interference

Hello,

we have set up an MPG jog wheel on the encoder on our 7i96S' TB2 pins 7 - 11 which works really well except it sometimes "misses" 1 or 2 increments of a full rotation but other than that it's been a real pleasure to use after getting it set up...

Yesterday we wanted to add Modbus to read the spindle load from our VFD. So we got an Arduino and an RS485 transceiver board out, wrote a little sketch to read an analog input, tested it with a USB - RS485 adapter, worked beautifully, so far, so good.
Flashed the 7i96sd_pktv2.bin, compiled our own little mesa_modbus component reading one value, didn't get it to work at first, so we tried the 7i96sd_pkt.bin, didn't make much of a difference. So we got the scope out and eventually fixed several small mistakes including but not limited to slave address 0 instead of 1 and swapping A/B on the RS485 transceiver... maybe it was a little too late in the night early in the morning for ambitious projects
One scale component and a little fiddling around in the HAL later and we got a working spindle load indicator.

So we home the machine and the machine starts jogging on its own. A peek into halshow tells us that the encoder count is rapidly decreasing and going into large negative numbers. At first I thought I fried something while doing late night wiring hack jobs but just by disabling our mesa_modbus component, the spook was gone and we could reliably jog the machine without any problems.

Going out on a few limbs here, could the mesa_modbus component somehow write into a memory region where the encoder stores info on its count?



P. S. Andy, thank you for your work on the mesa_modbus component! Surprisingly quick setup and much less of a pain than expected We might write up a little tutorial once we got the whole thing working.

Is it possibly just noise related?
that is, what happens if you set:

setp hm2_7i96s.0.encoder.00.filter true
setp hm2_7i96s.0.encoder.sample-frequency 100000

 

Thanks for the quick reply! Will test and report back but enabling/disabling the mesa_modbus was the only thing we changed, nothing else. Wiring stayed the same.

There reason I suspected electrical interference/ too fast encoder filter settings
is that you said the MPG missed counts and that the encoder appears to count,

 (a memory overlap would not be likely to count (slew) but rather have crazy numbers)
 

I re-enabled the mesa_modbus component.
The encoder seems to jump on every update. update-rate 1 Hz will jump every second, 0.5 once every two seconds, etc...

If I set the update-hz in the HAL to anything but 0, it will jump around. Changing it in halshow to 0 or a different value doesn't help, it will change the rate at which it's jumping but it will never stop.

If I set the update-hz in the HAL to 0 or leave it unset, it jumps around at first, but I can set it to something else and it won't jump around. Setting it back to 0 makes it jump again.

Actually I think found a fix for our problem.

Putting the setp for the update-hz after the loadrt scale count=2 makes it work. Moving it up one line so it's right before it makes it break.

PCW post=301477 userid=481Is it possibly just noise related?
that is, what happens if you set:

setp hm2_7i96s.0.encoder.00.filter true
setp hm2_7i96s.0.encoder.sample-frequency 100000

I don't have a .sample-frequency in my parameters, just counter-mode, filter, index-invert, index-mask, index-mask-invert, scale and vel-timeout.

A little bit of playing around with filter on/off didn't seem to make a difference.

Maybe something with the addf order?

hm2_7i96s.0.encoder.sample-frequency
is a pin, not a parameter

Note that you cannot change the update rate dynamically
if it has ever been set to 0

Here is my list of known mesa-modbus bugs:

    Current Mesa Modbus issues:

    
    BUGS:
    At startup there can be "call/response function number missmatch"
    error popups or sig11 (segv)s due to the fact that the PKTUART is
    not cleared at startup, so random numbers of garbage characters
    may be present in the RX FIFOs, leftover from the last LinuxCNC run.
    
    A temporary workaround is to run this before launching linuxcnc:
    
    mesaflash --device cardname --addr ipaddr --wpo 0x6800=0x00010000
    
    (writing 0x10000 to 0x6800=pktuartr_mode_reg clears the RX FIFOs)

    If you ever set the update rate to 0 (maximum), changing to a
    non-zero rate will not work (communication stops)
    
    There is a check for TX overflow in the PKTUART code that's
    in the wrong location (TX section) so will print bogus error
    messages with particular outgoing messages.
    
    FEATURES:
    
    Channel setting should not be global but in the .mod file
    to support more than one device.
    
    It would be good to have the error timeout/recovery
    time programmable.
    
    For multiple reads/writes it would be good to have the
    possibility of mixed types,
    This means for modbus devices that support table reads,
    all I/O for a device could be done in a single read and a single
    write.



 

Now that I commented a conv_u32_float back in, it jumps around in the snippet above, but does not when I move the setp right after the loadrt for the conv_u32_float.

That's all the testing I can do for now, let me know if I should try anything else.

Right, I always get those mixed up... how do I set a pin from HAL? Wouldn't let me do it with setp.

Changing it in halshow to your suggested 100000 didn't help though.