Design decision for modbus integration.

I wonder if you can assist with a design dilemma.

There is a digital output bit on a wireless device somewhere.

Our data logger/remote device controller that doubles as a Modbus master sets/unsets this bit based on a change in a register (which would have been triggered from a separate slave process - i.e. a generic PLC).

However, this data logger will also be updating the state of all pins/bits to the same Modbus master.

If we use the same register for both types of updates there would be contention and a possible race condition with different processes updating the same bit! One to set it, and the other to report it.

Am sure this sort of problem must have been solved before and wondered what the convention was. Do we use separate registers perhaps?

thx.

Could you re-state the problem again ? I think I count three devices: one master and two slaves.

But I'm not sure what your fourth sentence means. There are some pronoun/antecedent clarity problems.

However, this data logger will also be updating the state of all pins/bits to the same Modbus master.

Click to expand...

It might be that you can resolve your problem because there will be a different Modbus Function Code involved, or... well, I don't understand the problem so I can't guess about it.

Hi

There are 2 devices.

1. A Data Logger with a Modbus master that also runs a small modbus slave and manages a pool of wireless devices

2. A generic PLC that has Modbus

We wish the generic PLC to have the ability to use its control loop to set/unset bits that we expose via the Modbus master.

If we see a state change in the register we'll execute the AT commands to set the corresponding physical bit

However, the logger as a matter of course will be polling all actual states and updating registers associated with them.

So we end up with a scenario where our data logger could be updating the state of a register at the same time that a generic PLC is.

One process is reporting states. The other is controlling states.

It sounds like three devices to me.

1. The data logger - Modbus master.
2. The "small Modbus slave" run by the data logger
3. The generic PLC - Modbus slave or master?

My interpretation is that you are trying to have two Modbus masters communicating with a single slave. That's possible, but many potential traps.

Hi

I'm assuming the PLC will be a slave only.

The Modbus master (only one) could be a 3rd device if we wanted.

The data logger will of course have 2 small slave processes - one to respond to register changes; and the other to report physical states.

The problem as I see it is that the logger will be updating the same register as the PLC - the register represents the physical pin right?

info link,

GWY-000
GWY-900

We're both speaking English and I understand every single word in your posts, but with each successive post I find myself getting more confused.

The Modbus RTU protocol gives the terms "Master" and "Slave" specific meanings. A master initiates exchanges of data between two devices. A slave can only respond to commands from the master.

Communications between two processes running on the same computer typically don't use Modbus to exchange data.

Ok now we are progressing - apologies for my improper terminology!

In the scenario I give, the PLC then becomes the Master. But then how does/should the logger update the registers on the master with its values?

Here is a simple scenario:

- A wireless device has a pump relay (binary) and a tank sensor (analog).
- Our device needs to make available to the PLC the value of the tank sensor and also to change the actual state of the binary pin if the PLC's logic requires it.
However, this still leaves the question of what to do about reporting the state of the binary bit?

Hmmm. I think it might be becoming clear. The Master polls the slave for values. If the reported values are only available via polling the slave, then the logger only responds to requests from the Master - hence no ambiguity. Does this sound right?

Actually no, I am still lost. The data logger doesn't necessarily know about the Master, so the master needs to change a register on the slave to get it to set the binary state. So we are back to two processes updating the same register and causing a potential race condition.

To simplify:

1. There is a device that reads and updates values on a set of physical devices.
2. There a second device that tells the first device to make an update
3. There is the register that is used to tell the first device to set/unset the state of a physical device
4. There are the registers used to report the state of the physical devices

So the process/CPU that makes the request to change a state is different to the one that reflects the state changes - despite the fact they are using the same register (I'm assuming).

Is this a known problem and/or what conventions are used to deal with it?

Having dug somewhat deeper here, the problem can be stated like this:

We have a modbus slave (yes a slave, not a master - i was confusing client <-> server and slave <->master).

R/W Registers on the slave need to be updated by the device based on the status of some wireless devices it is polling/controlling.

However, an external master may also update the registers - say to request to open a relay on one of the wireless nodes.

So the scenario I struggle with is you have one register on one slave being updated by two different processes. The internal device and an external master. One is requesting a change of state, whereas the other is reflecting a change of state.

Somehow the process responding to state changes needs to know whether to take action (i.e. if the request is from an external master) or not.

usually the register that you read for status is not the same as the register that you use for control

is this correct in what you are trying to do


Note: in the wireless device the same register is in use
in the modbus Device different registers are in use

Thanks for the replies. Here are the flows as I see them:

1. Master modbus -> Slave RTU (via register) -> Slave process (AT commands etc.) -> 1..N XBee RTDs

2. XBee RTD -> Slave RTU (via ZigBee/AT protocol) -> Slave register (expose for Masters to read)

The risk is that the asynchronous handler that handles all register updates won't know wether it it is flow 1 or flow 2 and therefore whether or not to continue as in flow 1. So this is the essential problem. We need a way to flag the source/role of the register update.

It did strike me that for flow 2 we could use a temporary storage and update both this and the register - when a writable register gets changed, if its value differs from the temporary storage, we would assume flow 1. If it was the same, we'd assume flow 2 and do nothing.

Am hoping this problem is not unique and has been addressed before in an elegant manner.

Have you thought about a state machine?

Usually communication system ("Xbee" especially) has a communication state
eg
Waiting for line to be clear
transmitting message to a node
waiting for reply
receiving reply

Yes, a state machine is exactly what we need. Am curious though if this problem is one that is well established? Am surmising most PLC slaves perform synchronous operations based on their register states and therefore overcoming it.

For our purposes a slave register change does not correspond to a state change - rather it is the reflection of a change or the request for a change. In the middle, the actual change may fail - i.e. an RTD is unavailable - and so we have the complexity of reporting errors to the master.