Mesa modbus and pktUart

No i have 16 I/O as seen in mb2hal config
but in c code have 7 just for test only
Correct is 16 but i dont know if must write it in hex or dec base..
What is correct 0x0f or 16?

From these 2 modules which will work?
grobotronics.com/ttl-to-rs485-module.html?sl=en
or this
www.devobox.com/en/usb-to-serial/1264-ma...o-rs-485-module.html
How to wire pins with 7i80hd?

The RS-485 adapter should work, wiring would be:

PktURDataPin  <= RO   
PktUTDataPin   => DI
PktUTNDrvEnPin => DE
GND => RE

Note the N in PktUTNDrvEnPin

(the firmware must be built with this pin in the pinout file to have the
proper drive enable polarity)

Did you look at the relayboard.mod example?
Its probably closer, not for addresses but for bit I/O:
(look an the input definition)


/* Modbus definition file for a 4-channel relay board found on eBay */

/*
The format of the channel descriptors is:

{TYPE, FUNC, ADDR, COUNT, pin_name}

TYPE is one of HAL_BIT, HAL_FLOAT, HAL_S32, HAL_U32
FUNC = 1, 2, 3, 4, 5, 6, 15, 16 - Modbus commands
COUNT = number of coils/registers to read
*/

#define MAX_MSG_LEN 16   // may be increased if necessary to max 251

static const hm2_modbus_chan_descriptor_t channels[] = {
/*  {TYPE,    FUNC, ADDR,   COUNT, pin_name} */
    {HAL_BIT, 1,  0x0000, 8,     "state"},
    {HAL_BIT, 2,  0x0000, 8,     "input"},
    {HAL_BIT, 5,  0x0000, 1,     "relay-0"},
    {HAL_BIT, 5,  0x0001, 1,     "relay-1"},
    {HAL_BIT, 5,  0x0002, 1,     "relay-2"},
    {HAL_BIT, 5,  0x0003, 1,     "relay-3"},
};


/* Optionally #define DEBUG to aid with troubleshooting.
   Use 3 to see a lot of information about the modbus
   internal workings. 1 is default (errors only)                    */

 

What is SCFFIFO error ?

A SCFFIFO error means too many (>16) transmit frames are queued

Perhaps triggered by a xxxx.mod or hal error

It might also be this bug:

 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.

modname.update-hz is 0 by default i have not changed so this not the reason for error

I updated the older issues with the latest bug list:

github.com/LinuxCNC/linuxcnc/issues/2506