7i96S mesa_modbus encoder count interference

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.

somuchforfree wrote:

Code:

# spindle load loadrt spindle-load ports=hm2_7i96s.0.pktuart.0 setp spindle-load.00.address 1 setp spindle-load.00.baudrate 9600 setp spindle-load.00.rxdelay 255 setp spindle-load.00.txdelay 10 addf spindle-load.00 servo-thread setp spindle-load.00.update-hz 10 loadrt conv_u32_float count=1 addf conv-u32-float.0 servo-thread net spindle-load-float conv-u32-float.0.in <= spindle-load.00.state 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.

This works as in "encoder does not jump", but it also doesn't update the Modbus values... so we're getting there I think.

Not sure whats going on but I do know there's a bug with setting the update rate

You can set pins with setp:

halcmd: setp hm2_7i96s.0.encoder.sample-frequency 100000
halcmd:

Also is it the actual encoder count pin that is corrupted or something else
further down the chain. Thia may help to recreate the issue