The thing you need to understand is that there is NO standard for serial interface protocol for sensors.
Your RS-485 bus needs to communicate with a common protocol that ALL the nodes understand- they ALL need to work on a common protocol.

You need a node that translates each sensor signal into A COMMON PROTOCOL

 

The thing you need to understand is that there is NO standard for serial interface protocol for sensors.
Your RS-485 bus needs to communicate with a common protocol that ALL the nodes understand- they ALL need to work on a common protocol.

You need a node that translates each sensor signal into A COMMON PROTOCOL

Thank you so much for the thorough explanation. So if I converted my sensor signals (whether they are 1-Wire, UART, I2C or other) into RS-485 signal would it work? If I need a HUB - RS-485 that allows me to manage this, could you provide me with links to inexpensive devices?

 

Thank you so much for the thorough explanation. So if I converted my sensor signals (whether they are 1-Wire, UART, I2C or other) into RS-485 signal would it work? If I need a HUB - RS-485 that allows me to manage this, could you provide me with links to inexpensive devices?

For RS-485 the concept of "Hub" is not really appropriate, think "Bus" instead, which is really just the 3 wires that connect all the devices together.
You just connect all the devices to the bus, along with some termination and "idle line bias" resistors and that's it.
The only detail is that all the devices connected to the bus must be RS-485 compliant- This is a physical/electrical thing only- RS-485 does not specify ANYTHING about codes, baud rates, parity, etc.
For many simple projects, I make up my own protocol that does just what I need and nothing more. (hint- use human-readable ascii hex for data - makes debugging SO MUCH easier)

 

The very cheap and cheerful ATTiny85 could be a solution with this project on GitHub.

 

Each Physical connected (RS485 in your diagram) device must have some version of the Modbus application layer (a Mater or Slave program).

The Modbus application layer interface eliminates the need to directly communicate with the raw sensor. It usually repackages the raw data into a easily usable format of addressable 'registers' for computing and manipulation.

Here I have a AC energy management device (it's 3-phase but I'm only monitoring a 1-phase L12 power connection) to monitor a solar powered Inverter power usage.

There are obviously many types of raw sensors in the device for voltage and current measurements but it provides the packaged data products that I really need via Modbus.
Here is the Modbus specifications of the Energy Sensor.
https://github.com/nsaspook/vcan/blob/em540_modbus/em500-cp-v1r3-eng.pdf

The same PIC32MK controller I linked in a previous post can communicate with the device as a Master via a RS485 physical layer link using a few software application layer routines to poll the monitor and use the data for energy tracking.
https://raw.githubusercontent.com/nsaspook/vcan/em540_modbus/firmware/src/modbus_master.h
https://raw.githubusercontent.com/nsaspook/vcan/em540_modbus/firmware/src/modbus_master.c

/*
 * send and receive MODBUS templates for 3-phase energy monitor EM540
 * https://www.gavazzionline.com/pdf/EM540_DS_ENG.pdf
 * https://gavazzi.se/app/uploads/2022/03/em500-cp-v1r3-eng.pdf
 */
const uint8_t
// transmit frames
modbus_em_id[] = {MADDR, READ_HOLDING_REGISTERS, 0x00, 0x0b, 0x00, 0x01}, // Carlo Gavazzi Controls identification code
modbus_em_version[] = {MADDR, READ_HOLDING_REGISTERS, 0x03, 0x02, 0x00, 0x01}, // Firmware version and revision code
modbus_em_data[] = {MADDR, READ_HOLDING_REGISTERS, 0x00, 0x00, 0x00, 24},
modbus_em_config[] = {MADDR, WRITE_SINGLE_REGISTER, 0x10, 0x02, 0x00, 0x01}, // System configuration, Value 1 = ?3P? (3-phase without neutral)
modbus_em_passwd[] = {MADDR, WRITE_SINGLE_REGISTER, 0x10, 0x00, 0x00, 0x00}, // Password configuration, set to no password = 0
// receive frames
em_id[] = {MADDR, READ_HOLDING_REGISTERS, 0x00, 0x00, 0x00, 0x00, 0x00},
em_version[] = {MADDR, READ_HOLDING_REGISTERS, 0x00, 0x00, 0x00, 0x00, 0x00},
em_data[] = {MADDR, READ_HOLDING_REGISTERS, 0x00, // number of 16-bit words returned
    0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
    0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
    0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
    0x00, 0x00}, // crc
em_config[] = {MADDR, WRITE_SINGLE_REGISTER, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00},
em_passwd[] = {MADDR, WRITE_SINGLE_REGISTER, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00};

 

View attachment 293956
Each Physical connected (RS485 in your diagram) device must have some version of the Modbus application layer (a Mater or Slave program).
View attachment 293957
The Modbus application layer interface eliminates the need to directly communicate with the raw sensor. It usually repackages the raw data into a easily usable format of addressable 'registers' for computing and manipulation.

Here I have a AC energy management device (it's 3-phase but I'm only monitoring a 1-phase L12 power connection) to monitor a solar powered Inverter power usage.
View attachment 293960
There are obviously many types of raw sensors in the device for voltage and current measurements but it provides the packaged data products that I really need via Modbus.
Here is the Modbus specifications of the Energy Sensor.
https://github.com/nsaspook/vcan/blob/em540_modbus/em500-cp-v1r3-eng.pdf

The same PIC32MK controller I linked in a previous post can communicate with the device as a Master via a RS485 physical layer link using a few software application layer routines to poll the monitor and use the data for energy tracking.
https://raw.githubusercontent.com/nsaspook/vcan/em540_modbus/firmware/src/modbus_master.h
https://raw.githubusercontent.com/nsaspook/vcan/em540_modbus/firmware/src/modbus_master.c

/*
* send and receive MODBUS templates for 3-phase energy monitor EM540
* https://www.gavazzionline.com/pdf/EM540_DS_ENG.pdf
* https://gavazzi.se/app/uploads/2022/03/em500-cp-v1r3-eng.pdf
*/
const uint8_t
// transmit frames
modbus_em_id[] = {MADDR, READ_HOLDING_REGISTERS, 0x00, 0x0b, 0x00, 0x01}, // Carlo Gavazzi Controls identification code
modbus_em_version[] = {MADDR, READ_HOLDING_REGISTERS, 0x03, 0x02, 0x00, 0x01}, // Firmware version and revision code
modbus_em_data[] = {MADDR, READ_HOLDING_REGISTERS, 0x00, 0x00, 0x00, 24},
modbus_em_config[] = {MADDR, WRITE_SINGLE_REGISTER, 0x10, 0x02, 0x00, 0x01}, // System configuration, Value 1 = ?3P? (3-phase without neutral)
modbus_em_passwd[] = {MADDR, WRITE_SINGLE_REGISTER, 0x10, 0x00, 0x00, 0x00}, // Password configuration, set to no password = 0
// receive frames
em_id[] = {MADDR, READ_HOLDING_REGISTERS, 0x00, 0x00, 0x00, 0x00, 0x00},
em_version[] = {MADDR, READ_HOLDING_REGISTERS, 0x00, 0x00, 0x00, 0x00, 0x00},
em_data[] = {MADDR, READ_HOLDING_REGISTERS, 0x00, // number of 16-bit words returned
    0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
    0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
    0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
    0x00, 0x00}, // crc
em_config[] = {MADDR, WRITE_SINGLE_REGISTER, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00},
em_passwd[] = {MADDR, WRITE_SINGLE_REGISTER, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00};

For the devices that I have illustrated before, that I own... can I still complete the project? In practice, how can I structure a Modbus Application Layer? Via code with the PyModbus library is it possible?

I can't figure out if, given these devices, I can do this Modbus RTU communication, I have to buy something else.

 

For RS-485 the concept of "Hub" is not really appropriate, think "Bus" instead, which is really just the 3 wires that connect all the devices together.
You just connect all the devices to the bus, along with some termination and "idle line bias" resistors and that's it.
The only detail is that all the devices connected to the bus must be RS-485 compliant- This is a physical/electrical thing only- RS-485 does not specify ANYTHING about codes, baud rates, parity, etc.
For many simple projects, I make up my own protocol that does just what I need and nothing more. (hint- use human-readable ascii hex for data - makes debugging SO MUCH easier)

So from what you are telling me the sensors must already support RS-485 communication? Did I basically do everything wrong?

How does the bus connect the various sensors in practice, physically, with the wires and the breadboard?

Excuse the ignorance again. Have mercy.

 

So from what you are telling me the sensors must already support RS-485 communication? Did I basically do everything wrong?

No - we didn't say that - what was said is that you need to design the interface between the sensor and the databus.
The sensor will probably be analogue, and you connect to the bus via a UART and RS485 line transceiver.

How does the bus connect the various sensors in practice, physically, with the wires and the breadboard?

@nsaspook gave you a very good diagram in Post #25.
The 0V connections for all the sensors should go to earth.

 

For the devices that I have illustrated before, that I own... can I still complete the project? In practice, how can I structure a Modbus Application Layer? Via code with the PyModbus library is it possible?

I can't figure out if, given these devices, I can do this Modbus RTU communication, I have to buy something else.

Lets try a bad analogy.
RS-485 communication is like a road. it's great but useless for transportation (data from sensors) without vehicles (data packets). When we have vehicles on the road, there must be rules to how vehicles operate on that road.Those rules are the Modbus Master/Slave protocol.

Sure, the PyModbus library are the Modbus rules for the BB but there must also be a device with Modbus rules on the sensor slaves. So yes, you need to buy something (slave modbus interfaces) that can likely combine some of the client blocks on your illustration.

 

Or you can think of it as a telephone line, but with 6 telephones all connected at the same time.
The first thing your protocol has to do is to make sure that all 6 sensors don't speak at once. MODBUS deals with this by only allowing the sensors to answer questions. The controller asks the question and the peripheral)responds. Peripherals are not allowed to speak at any other time.
Then the next thing is to make sure that the controller and peripherals are all speaking the same language. It wouldn't work if the controller was speaking English and the peripherals spoke Swahili. So both need to understand that when the controller sens 0x01,0x03,0x00,0x01 it is asking for the data from peripheral #1.
Finally each peripheral needs to know what number it is. You don't want two peripherals answering at the same time. Imagine if you had 6 telephones and two of your subscribers were both called John. If you ask John for his data, you get two responses simultaneously and you can't understand either answer.

 

Lets try a bad analogy.
RS-485 communication is like a road. it's great but useless for transportation (data from sensors) without vehicles (data packets). When we have vehicles on the road, there must be rules to how vehicles operate on that road.Those rules are the Modbus Master/Slave protocol.

Sure, the PyModbus library are the Modbus rules for the BB but there must also be a device with Modbus rules on the sensor slaves. So yes, you need to buy something (slave modbus interfaces) that can likely combine some of the client blocks on your illustration.

Ok now it's clearer to me ... but at this point I wonder .. Should I buy a device with Modbus rules on the slave sensors (therefore on my sensors), for each sensor?

If so, at this point the link would be for example:

Sensor ---> Converter for RS-485 serial communication ---> Controller Modbus Slave --> BUS RS-485 --> Master BBB

Is it correct?

 

Ok now it's clearer to me ... but at this point I wonder .. Should I buy a device with Modbus rules on the slave sensors (therefore on my sensors), for each sensor?

If so, at this point the link would be for example:

Sensor ---> Converter for RS-485 serial communication ---> Controller Modbus Slave --> BUS RS-485 --> Master BBB

Is it correct?

If your sensor has a RS-485 interface that will work but most cheaper sensors like the DHT11 One-Wire won't have that. Each Controller Modbus Slave should be selected for the needed sensor interface.

 

Each Controller Modbus Slave should be selected for the needed sensor interface.

In case I want to use this serial communication, could you link me some economic interface module (or Controller Modbus Slave ) that I can combine with some sensors? Can you ,please, explain me some use cases for experimental purpose on a BREADBOARD?

If I can't do this is quite a problem for me. In case then I don't use RS-485 serial communication and leave this choice aside, I can still use the PyModbus library to simulate a Modbus communication without serial transmission using dht11 and other "normal" sensors? Hope yes.

 

Let's see if this will help to clear up any confusion.

RS-485 BUS is the physical layer, usually requiring only two wires, A and B. The data signal in A is the complement of that in B. A ground wire is not required.

MODBUS is a communications protocol. You need intelligence in a controller (such as a microcontroller, MCU) in order to send and receive MODBUS commands. In order to be compliant, commands and messages must be compatible across all devices. You do not have to adhere strictly to the MODUS protocol. You can roll your own protocol.

The SENSOR INTERFACE can be any communications interface, including straight analog. One function of the MCU is to interface with the sensor using whatever means is available on the sensor. Data is stored in the MCU. On request of a command on the RS-485 BUS, the MCU has to identify and decode the command. If the command is a valid request for data, the MCU sends the data out via its Serial Communications Interface (SCI, also known as UART.)

The RS-485 Transmitter is simply a differential line driver. There is no signal encoding involved.
There are many RS-485 transceivers available in different styles and pinouts. SN75176 is one of the earliest ones. LT1785 and MAX485 are other examples.

Thus, all the protocol intelligence has to be in the MCU, not the sensor. It does not matter what interface is used in the sensor.

 

What should become obvious is that each bus client has to be unique. It has to have an ID number associated with it. This ID is stored in the MCU and used to identify any command addressed to this sensor.

Hence, every command will have a device ID embedded in the command.
The client device will respond to the command with a message that also has its ID embedded in the message.

With peer-to-peer network, every message will have a sender ID and destination ID embedded in the message.

 

In case I want to use this serial communication, could you link me some economic interface module (or Controller Modbus Slave ) that I can combine with some sensors? Can you ,please, explain me some use cases for experimental purpose on a BREADBOARD?

If I can't do this is quite a problem for me. In case then I don't use RS-485 serial communication and leave this choice aside, I can still use the PyModbus library to simulate a Modbus communication without serial transmission using dht11 and other "normal" sensors? Hope yes.

You want to build things on a breadboard when you don't even understand how the process works? Crawl before you try to walk, hope doesn't work.

I'm done with this.

 

Let's see if this will help to clear up any confusion.

RS-485 BUS is the physical layer, usually requiring only two wires, A and B. The data signal in A is the complement of that in B. A ground wire is not required.

MODBUS is a communications protocol. You need intelligence in a controller (such as a microcontroller, MCU) in order to send and receive MODBUS commands. In order to be compliant, commands and messages must be compatible across all devices. You do not have to adhere strictly to the MODUS protocol. You can roll your own protocol.

The SENSOR INTERFACE can be any communications interface, including straight analog. One function of the MCU is to interface with the sensor using whatever means is available on the sensor. Data is stored in the MCU. On request of a command on the RS-485 BUS, the MCU has to identify and decode the command. If the command is a valid request for data, the MCU sends the data out via its Serial Communications Interface (SCI, also known as UART.)

The RS-485 Transmitter is simply a differential line driver. There is no signal encoding involved.
There are many RS-485 transceivers available in different styles and pinouts. SN75176 is one of the earliest ones. LT1785 and MAX485 are other examples.

View attachment 294016

This is really a very clear explanation. Thank you so much for your reply and clarification. I still have some doubts though.

I have a transceiver ,which I could use for as you say and I have sensors.

Therefore, I am missing the MCU that "translates" the data (in case you can recommend something functional for this case) and the BUS communication which is not very clear to me.
In the end, based on what I would like to create, the end result should be something like this??
So my RS-485 Converters are no longer needed?

 

You want to build things on a breadboard when you don't even understand how the process works? Crawl before you try to walk, hope doesn't work.

I'm done with this.

You are right, I know very well. Unfortunately I have little time for various reasons and I am sorry to have disturbed and annoyed you. Thanks anyway for your time, you've been a great help

 

You are right, I know very well. Unfortunately I have little time for various reasons and I am sorry to have disturbed and annoyed you. Thanks anyway for your time, you've been a great help

I'm just tired of saying the same thing over and over while you seem to be stuck in a rut after getting good advice from many. You're almost there.

 

The serial data stream follows UART signalling protocol, for example, start bit, 7 bits data, parity, one stop bit.



The RS-485 transmitter does not alter the serial data stream. It converts the single-ended UART data stream into differential outputs.



Data is not just one character. Data is in a message of any number of characters. The intelligence is embedded in the entire message. You need an MCU in order to interrogate the message. In other words, a packet of characters is sent on each transmission by the controller and by the client.

Thus, having a UART sensor is not sufficient. You still have to embed the data in a packet.