1 PLC serving as both Modbus master and slave?

I'm using a Automationdirect CLick PLC (c0-02dd2-d). It has 2 RJ12 ports and 1 designated RS485 (we will call this port 3) port. My thought process is this: 1 of the RJ12 ports will be designated as programming only (we will call this port 1). Then 2nd RJ12 port will be designated as RS485 Modbus slave (we will call this port 2) connected to an HMI. The RS485 will be modbus master talking to another device.

I would like to read from port 3, then output the data to the HMI connected on port 2. The HMI would have data entry available to change the data that is being read on port 3 (like changing a setting on the device).

I am running into some kind of collision. I have old setting on my screen, but when I change the settings, it would snap back to the old setting (pulling the old data from port 3 device?)

How do I overcome this?

Confusing, eh?

Port 2 is 232, 3 is 485.
Is this what you are wanting to do?

Port 1 = rs232 for programming
Port 2= rs232 port. Acting as slave to HMI master
Port 3=rs485 port ackting as master to some other piece of equipment?

If so, that should work if properly configured.

g.mccormick said:

Port 2 is 232, 3 is 485.
Is this what you are wanting to do?

Port 1 = rs232 for programming
Port 2= rs232 port. Acting as slave to HMI master
Port 3=rs485 port ackting as master to some other piece of equipment?

If so, that should work if properly configured.

Click to expand...

Port 1 = RS232 for programming
Port 2 = RS485 to the HMI (HMI is the master, PLC is the slave)
Port 3 = RS485 acting as master to another device.

I'm encountering the problem of the PLC reading and writing to the same tag. Port 2 reads and writes to TAG A, and Port 3 reads and writes to TAG A (tag A is a setting that is manipulated through the HMI).

Also, is it possible to have a Modbus slave A receive data from another slave B? Basically pulling the same data as the Master.

First off realize that port2 is a 232 port not 485 port.
https://www.automationdirect.com/ad..._(Stackable_Micro_Brick)/PLC_Units/C0-02DD2-D

If your logic is overwriting a specific tag/variable, you should be adding logic to not allow that to happen. Are you trying to have the hmi value be sent to the other device by the PLC?

Since the Click requires you to manually write the logic for the data exchange, the order they execute will determine which data wins, I assume. Last in the scan should be the winner. So, if you want the HMI to always win, sending it's data to the Click and on to a drive for example...

Read from the HMI, write to the drive, then read from the drive and then write to the HMI... rinse and repeat.

You can't be sure of the timing of when messages complete. I do this sort of thing a lot with radio comms to systems that have local HMIs. I need to be able to adjust what amounts to the same setpoint from multiple different locations. I always end up with a group of tags reserved as setpoints that can be adjusted from either end, and I need to know where it was changed. To do this, I keep a copy of each tag in a "handshake" location.

The HMI reads and writes to the tag that is part of the data packet being sent. The data being received from the master is what I compare to the handshake registers. This way, the local HMI can write to the data that ends up at the master without triggering the "not equal" to overwrite it until the master receives it, does the same handshake logic at that end, and sends it back.

You're most robust method will be to have a handshake resister for each data value that the HMI can write. Watch for it to change (not equal compare instruction between the HMI tag and the handshake tag) and then and only then update the tag that is being sent to the slave as well as the handshake tag.

The data read from the slave may also need handshake tags that can be used with comparisons to control when the tag for the HMI gets updated.

This way the data only gets updated, and gets updated for the master and the remotes only when a change is detected. I tried a couple of different methods for this, and having handshake tags turned out to be the most straightforward. In my situations with radio modems, intermittent comms failures are somewhat commonplace. So the next hurdle is how to make sure it works as intended when a read succeeds but a write fails. This should be necessary with a hardwired system so I am not going to go into what I did for that to further confuse things.

Damage this is hard to explain in text. I need to draw a flow chart of this...