Mesa modbus and pktUart

Seems to be related also to this
forum.linuxcnc.org/27-driver-boards/5432...v2d-firmware?start=0

If after startup set update-hz to 0.0001 or something non zero problem seem to stops..
Is this division by zero bug?

Yes, this is a long known bug, never set the update rate to 0.

This is the reason for crazy data readings on encoders ?
I make now a config that encoder.count and encoder.velocity goes crazy to see if it stops by setting update-hz to non zero

Yes problem of noise in encoders resolves by non zero value to update-hz
verified by different configs that produced random data to different encoders.
All random data stop to encoders if update-hz is non zero but stop and modbus device to work.
 

If i set non zero update-hz problem of crazy data reading on encoders stop
but also stops working modbus device so no solution here..

If you ever set the update rate to 0, you can never change it again or the driver will hang (this is a known bug)

I start with 0.1 in hal file setting and does not work
if change it to 0 from halshow starts working but encoder reads crazy data.
Also if change functions order in vhdl pin file changes affected encoder number and pins.
Seems to be bug in vhdl because the functions order affects the encoder that is affected
in one config affected encoder.00.input-a and b
and in other config encoder.04.velocity and count.
Also when modbus device working the encoder reads crazy data when not working
by removing power supply/unwiring or stop it by setting update-hz to non zero
the same time stops the problem to encoder.
Seems like electric noise problem internaly in fpga
The same module works ok with mb2hal so it is not the module

The error when setting the update rate to 0 is that you cannot change it
after this has been done:

   "If you ever set the update rate to 0 (maximum), changing to a
    non-zero rate will not work (communication stops)"

I have no issue with the ioc32 running at 9600 baud at a .1 second update rate.

 The bug is in either Mesa modbus or the PKTUART driver, not the VHDL.
Most likely the drivers idea of the amount of read data does not match
the actual amount returned, so data from one module is mixed with the
previous or subsequent modules data.

It could also conceivably be a memory/stack issue in the modbus or PKTUART driver.

 

I have start with 0.1 setting and does not work.
Reads only the inputs at startup but can not set outputs neither led in ioc32 blinks.
I was thinking the works but because saw input pin lighting in halshow but when try
to set out pin not works neither
data transfer modbus led blinking in ioc32

Are you saying you have the update rate set to 0 in the hal file?

(and 0 is bad as it triggers the divide by 0 bug)

I don't see an issue with .1 second update rate
(I have used that value but probably set it later)

It looks like much of this may be related to the divide by 0 bug in the driver


 

No it is not divide by 0 bug.I have tested that fix in mesa_modbus.c.tmpl code but problem not fixed.I have set update-hz 0.1 in hal file and does not work.
Only 0 works but if modbus is working encoder reads crazy data.
Encoder stop read crazy data only if modbus
does not work.
Can't work both encoder and modbus.
But the problem appears when there are 5 encoders not only 4