Modbus and Arduino UNO (or smaller)

For a project in the concept stages, I am looking at a variable number (3-12) of small Arduino units (UNO, or hopefully Nano) spread over a mid-sized area (in electronic terms, small for humans) of 5m x 10m.

I am looking at Modbus over RS-485 to connect the processor modules. Since I have to run power wires, adding a few more for comms isn't a big deal. I looking at the half-duplex MAX485 based boards. Which appears to put me solidly in the master-multislave configuration. That is fine, I can work with it.

What is the preferred library for Modbus? (ie., which library is best supported)
There are two libraries in the Arduino IDE, ModbusMaster and ModbusRTU_Slave. Are they usable, are they any good, should they be avoided? I noticed they are by two different people, but will they work together?

I haven't the space for the larger boards to add additional serial ports and I want to leave the current serial port available for debug output and data transfer with the PC. Will the libraries listed above (either from the suggested list or the two from the IDE library) work with software serial?

I tried the google thing on the latter, but only came up with results from 2010. I'm not sure they apply today, so I am looking for fresh updates.

Any other advice, hints, tips, or suggestions are welcome as well.

What is the preferred library for Modbus? (ie., which library is best supported)

I can only tell for myself, I use a modified version of this library in my ModBus projects:

It has the great advantage that it supports master and slave in one library.

There are two libraries in the Arduino IDE, ModbusMaster and ModbusRTU_Slave. Are they usable, are they any good, should they be avoided? I noticed they are by two different people, but will they work together?

I don't know the two but they should work together as they implement the same standard :-).

I guess the question is more which part of the standard is supported. Most ModBus libraries has some limitations (p.e. the register addresses are not completely free to choose) so it depends on the detail specifications you have if you choose one or another.

I haven't the space for the larger boards to add additional serial ports and I want to leave the current serial port available for debug output and data transfer with the PC. Will the libraries listed above (either from the suggested list or the two from the IDE library) work with software serial?

As far as I know most libraries support SoftwareSerial although I don't recommend to use it. To make ModBus standard conforming you have to follow strict timing constraints. As SoftwareSerial blocks the processor and all interrupts during complete byte transfers it's a nightmare for every timing critical task. I don't know what your Arduino's task will be but if they have to do more than switching on an LED or two forget the software emulation and let the hardware do the task. You can develop the software using some Leonardos (where you have the debugging channel by USB built into the processor) and move to the ATmega328p based models when the software is mature. I've done such a project and this was the only reliable way.

Thanks for the confirmation, Pylon.

pylon:
I can only tell for myself, I use a modified version of this library in my ModBus projects:

https://github.com/smarmengol/Modbus-Master-Slave-for-Arduino

It has the great advantage that it supports master and slave in one library.

Further research away from the Arduino forum, has many many results with the smarmengol being used. As I need to develop both slave and master in the arduino platform, I was thinking this one would suit this project best.

pylon:

adwsystems:
There are two libraries in the Arduino IDE, ModbusMaster and ModbusRTU_Slave. Are they usable, are they any good, should they be avoided? I noticed they are by two different people, but will they work together?

I don't know the two but they should work together as they implement the same standard :-).

I looked at these "libraries". The library may be fine (I don't know), but the examples are very small or very specific (such as reading from a particular model solar panel charge controller). The smarmengol examples and non-forum search results (I'm sorry but I did not find much here) seem likely to compile into more complete set of references.

pylon:
As far as I know most libraries support SoftwareSerial although I don't recommend to use it. To make ModBus standard conforming you have to follow strict timing constraints. As SoftwareSerial blocks the processor and all interrupts during complete byte transfers it's a nightmare for every timing critical task. I don't know what your Arduino's task will be but if they have to do more than switching on an LED or two forget the software emulation and let the hardware do the task. You can develop the software using some Leonardos (where you have the debugging channel by USB built into the processor) and move to the ATmega328p based models when the software is mature. I've done such a project and this was the only reliable way.

All but one, maybe two, will not be doing any critical timing tasks. One will be performing data logging, so that will having timing requirements, but I may have space to move that to a MEGA (talk about I/O overkill). The rest do not have the space to fit a MEGA, DUE, or ZERO. Looking at the comparison table those are the only boards with two hardware serial ports. Is there a board out there about the size of a Nano that uses a processor with at least two hardware serial ports?

Is there an improve SoftwareSerial available that reduces the limitation you list above (ie., non-blocking of processor and interrupts)?

Is there a board out there about the size of a Nano that uses a processor with at least two hardware serial ports?

No, but the Micro is almost the same hardware as the Leonardo and it has a USB connection (built into the processor ATmega32U4) and an additional hardware serial interface. If you really need the debugging channel, this might be a good fit. If the Micro is to big, Adafruit has a feather also based on the ATmega32U4 which is even a bit smaller.

Take care when selecting the RS-485 adapter boards. Most boards available are only suitable for point-to-point connections and cannot be used on a bus with multiple nodes (because the have fixed termination and bus idling resistors soldered on the board). I built my own hardware as I didn't find a suitable module that wasn't horribly expensive.

pylon:
No, but the Micro is almost the same hardware as the Leonardo and it has a USB connection (built into the processor ATmega32U4) and an additional hardware serial interface. If you really need the debugging channel, this might be a good fit. If the Micro is to big, Adafruit has a feather also based on the ATmega32U4 which is even a bit smaller.

The Micro will likely work. I have some space, but not enough for an UNO even. I guess the catch to the product comparison chart is that some of the boards have a USB and some have hardware serial ports. Sometimes they are the same port (UNO) and sometimes different (Micro)? I ask because I have only work with the Pro Mini and the UNO (I have two MEGAs but haven't put them to work yet).

pylon:
Take care when selecting the RS-485 adapter boards. Most boards available are only suitable for point-to-point connections and cannot be used on a bus with multiple nodes (because the have fixed termination and bus idling resistors soldered on the board). I built my own hardware as I didn't find a suitable module that wasn't horribly expensive.

I was pondering building out my own MAX485 based modules, because I don't like the connectors on most of the cheap RS485 boards. They only have a 2 pin screw terminal for the comm connection, and nothing or pin connector for connecting to incoming power and ground. I have found a few that include a 4 pin screw terminal connection. I will need to look further into those to see if they have the same issue.

Sometimes they are the same port (UNO) and sometimes different (Micro)?

You can see it that way, yes.

The UNO, Nano, Mini and many others are based on the ATmega328p. To be able to connect them to a PC (USB) they need a USB2serial adapter chip. The UNO uses an additional processor (ATmega16U2) while others use a specialized chip (p.e. FTDI).
The boards based on the ATmega32U4 (Leonardo, Micro and others) doesn't need that adapter because the main processor has a USB interface. This has a lot of advantages but also some drawbacks. As the different processor also changes some other stuff the selection of the board should be made with all the needs you have on the board in mind. Just one example: On the UNO/Nano/Mini you can use any GPIO as the source of a pin change interrupt while the Leonardo/Micro has only about 6 of the available. There are many such nuances that may influence your selection so get all your needs listed, then make the correct selection.

why do you want to use Modbus? I understand why rs485, but why Modbus RTU over it?

Juraj:
why do you want to use Modbus? I understand why rs485, but why Modbus RTU over it?

Mostly because a library with the "addressable" UART and bus negotiation are already exists. I just hope it is any good (ie., 10x less work to learn it than to make something myself). Which pretty much applies to the entire reason I chose the Arduino platform.

pylon:
Take care when selecting the RS-485 adapter boards. Most boards available are only suitable for point-to-point connections and cannot be used on a bus with multiple nodes (because the have fixed termination and bus idling resistors soldered on the board). I built my own hardware as I didn't find a suitable module that wasn't horribly expensive.

I'm finding the same thing. I could just desolder them, but having them jumperable sounds better.

Are there other options for a software base serial port? I have found references (but not links) to a NewSoftSerial library that is posted to mitigate the issues you listed with SoftwareSerial.

Are there other options for a software base serial port? I have found references (but not links) to a NewSoftSerial library that is posted to mitigate the issues you listed with SoftwareSerial.

NewSoftSerial and AltSoftSerial are interrupt based and therefor doesn't block the processor for the same long time periods but they are still software emulations and have problems with higher baud rates.

I recommend to use a hardware serial interface for any communication that should be reliable.

I am headed down the path of using AltSoftSerial (from the library manager) and the smarmengol Modbus library (from your link above).

I'm going to start with just 1 master and 1 slave over TTL. I believe I should be able to move up to 2 slaves using TTL, just for program proof-of-concept testing. From there I will add in the RS-485 modules.

Question on Modbus or smarmengol Modbus: One aspect of the master is to be datalogger or data collector of sorts. The master will need independent memory space to store the register values read from each slave. How big can I make the uint16_t au16data array?

I am headed down the path of using AltSoftSerial (from the library manager) and the smarmengol Modbus library (from your link above).

You have to change the library in this case as it doesn't support AltSoftSerial out of the box.

I believe I should be able to move up to 2 slaves using TTL, just for program proof-of-concept testing.

No, you might damage the TX pins.

Question on Modbus or smarmengol Modbus: One aspect of the master is to be datalogger or data collector of sorts. The master will need independent memory space to store the register values read from each slave. How big can I make the uint16_t au16data array?

There is no fixed limit, that depends on how much RAM you use for your other stuff. Data logger sound as if you're using an SD card for storage? The SD library needs almost a third of the available RAM of an UNO just for buffering.

pylon:
You have to change the library in this case as it doesn't support AltSoftSerial out of the box.

Dang! What about NewSoftSerial?

I have just drafted the program for the first slave, sans communication routines. Next is to draft the program for the master. When I get there I will start another thread, unless you are aware of a thread on it. I could not find one here. I could be trying the combination as early as next week.

pylon:
No, you might damage the TX pins.

Tying the to slave TX pins together could be an issue. Diodes maybe?

pylon:
There is no fixed limit, that depends on how much RAM you use for your other stuff. Data logger sound as if you're using an SD card for storage? The SD library needs almost a third of the available RAM of an UNO just for buffering.

I have an all in one program that doesn't fit in an UNO. That is part of the reason I'm headed this route (the other reason is wiring and modularity). Once I break it up I think it will fit. Worst case, I can upgrade the master to a MEGA. It is the only one that has the space for a board larger than an UNO.

Tying the to slave TX pins together could be an issue. Diodes maybe?

You could try pulling the line up and connecting the TX pins of the slaves by diodes so that they may pull it down. I definitely recommend against that.

I have an all in one program that doesn't fit in an UNO.

I'm talking about RAM not flash memory. Sure the Mega has more of both memory types.

pylon:
You could try pulling the line up and connecting the TX pins of the slaves by diodes so that they may pull it down. I definitely recommend against that.

pylon:
I was thinking diodes on the outputs, then pull down resistor at the diode anode-RX pin connection. I google diode or gate. I wonder if I have a 74xx OR or NAND gate chip around.

I'm talking about RAM not flash memory. Sure the Mega has more of both memory types.

It doesn't fit in either the RAM nor the Flash. The program is over 200% of the UNO. I built and tested it in pieces on an UNO then combine all the parts into one sketch. The usage numbers the compiler returned were a hoot!

adwsystems:

pylon:
You have to change the library in this case as it doesn't support AltSoftSerial out of the box.

Dang! What about NewSoftSerial?

I have just drafted the program for the first slave, sans communication routines. Next is to draft the program for the master. When I get there I will start another thread, unless you are aware of a thread on it. I could not find one here. I could be trying the combination as early as next week.

I have reached the point where I need to move from the development MEGAs to the interim UNO and Nanos. I started threads on the testing of the communications.

smarmengol Modbus and SoftwareSerial

smarmengol Modbus and AltSoftSerial

SoftwareSerial works a little, but it not reliable (misses receiving or sending more than occassionally)

AltSoftSerial doesn't work at all. I expected that, but am not sure how to modify the library to make AltSoftserial work. Any help on either is greatly appreciated.

I don't think it's wise to open so many different threads for the same project. I answered in your other thread, so I will stop reading this one.