Red Lion G3 as Modbus Slave(RTU)

[BTalbot]

I'm trying to help out a customer who's using a G306M (Crimson2) to talk as a RTU slave to an ABB unit. I do not have the hardware, so I'm just looking for suggestions. I have also contacted Red Lion support, but wanted to throw it out here in hopes someone has "been down this road before".

Here is his comments:
1. My Modbus master “PLC” has two Modbus message commands set up in it.
a. The first does a 03 read from slave 7, address 401000, one word. This message is executed every 5 seconds.
b. The second does a 16 write to slave 7, address 401000, one word. This message is executed every 5 seconds.
2. When I power up or execute a send from Crimson to HMI, a value of “0” appears in the PLC at 401000. (proving that the 1a was successful as it took the “0” showing on the screen of the HMI and read it into PLC)
3. When I touch the Integer Text object on HMI, and enter a value of 55 and hit enter, within 5 seconds the PLC shows a value of 55 in register 401000. Again, 1a was successful.
4. If I access the PLC with my programming software and change the value in 401000 to 0, (which is what happens with the controller during automatic function when a certain event occurs – it changes the setpoint value from whatever the HMI had wrote to it, to a value of 0), the PLC shows the value of 0 in 401000 but within 5 seconds, it changes it back to 55 again. The value on the HMI never changes from 55.
a. So, to prove that the 55 is getting read back into the PLC again from the HMI, I disconnected the Modbus cable between HMI and PLC and repeated step 4. Guess what? The PLC retained the value of 0 that I entered via the programming software. No bug in the PLC program! Also, the value of 55 remains on the HMI with the disconnected Modbus cable which leads me to believe the HMI is retaining this value in internal memory. Then I reconnected the Modbus cable and within 5 seconds, the value of 0 in the PLC gets written over with a value of 55.

 

[JeffKiper]

Do you have the tag as retentive? Look under the tag properties

 

[BTalbot]

Yes I have verified the tag is set up as non-retentive

 

[Eric Nelson]

Sounds like the read is occurring before the write. If PLC data has priority, then the write must occur before the read. Maybe they can add some code to ensure it happens in the correct order?



-Eric

 

[Eric Nelson]

If PLC data has priority, then the write must occur before the read.

On second thought, I take that back. If the write occurs first, then you can't change data via the HMI

This is confusing to me, as I usually have the HMI as the master.

I think the PLC needs to read the data from the HMI AND the automatic setpoint change, then determine which one has priority. The winning value then gets written to the HMI.



-Eric

EDIT: I'm thinking when the automatic setpoint change occurs, it should execute an immediate write, to update the HMI, instead of the cyclic write.

 

[BTalbot]

We got around this by using a trigger in the tag to do the magic
(even Crimson 2 has a lot of power!)