GE RX3i with both ModbusTCP and SRTP Communications

Hi all,

I'm having a few issues sorting out communications from my GE RX3i (IC695CPE310) to both GE QuickPanel View HMI (using Native GE SRTP Driver) and SCADA (using ModbusTCP and communication requests).

Basically individually I have gotten them both working, but when combined I have race issues, ie if I update a setpoint in the HMI it gets clobbered by the setpoint existing in SCADA.

My program in the PLC first does a COMM_REQ to read registers from the Modbus Server, copies this data to a internal setpoint tag, then at the end of the cycle does the opposite, does a COMM_REQ to write the data back to the Modbus server. This all works fine.

But how do I incorporate HMI reading/writing the same internal tags? I'm not sure how to make sure the latest value is the one that gets through.

Hopefully that makes some sort of sense, and that someone has had similar issues in the past, any questions feel free to ask!

Why is the PLC the ModbusTCP Client and SCADA the server? Why not the other way around?

The PLC is the SRTP server to the HMI's Client. Why not the same relationship with the SCADA?

Yes this would be the easier way maybe, but the PLC is talking ModbusTCP via an RTU to the SCADA. So RTU is acting as Modbus Master, then it's actually DNP3 to SCADA. Unfortunately this is a requirement. But I have managed to sort this part out. Its when I add in the HMI that is starts getting a bit messy. Hopefully this is still a solveable problem.

Do I understand correctly that all comms between your SCADA and your PLC are initiated by the PLC via the COMM_REQs? I also assume that the QP writes directly to the same Setpoint registers that you use for the SCADA reads and writes.

It sounds like when the QP writes a new value to a SP register in the PLC, the SCADA COMM_REQ subsequently (albeit asynchronously) reads in it's old SP data and then overwrites the new SP value that was previously written by the QP. If that is the case, then you might be able to detect when a SP register changes within your PLC via a compare to the SP array's previous scan's value and force the new SP value to be written to the SCADA whenever a SP register changes. Basically, you would be forcing a write on exception to your SCADA.

It's awkward, but if that's the way it has to be...

Set up one bit that the SCADA can set to tell the PLC that it has data it wants to write to the PLC.

On a regular basis have a COMM_REQ in the PLC read that bit.

If the bit is not set, the PLC can execute another COMM_REQ (or multiple COMM_REQs if necessary) to write all of data required to keep SCADA updated.

Lather, rinse, repeat...

If the bit is set, instead of the PLC writing data to SCADA, it issues a COMM_REQ to read the data from SCADA and copies what it reads to the working memory.

That should keep the SCADA current with what's in the PLC and only make changes when necessary.

Hmm ok I thought I might have to do something like that.

The only issue is, how do I write the bit in SCADA when it has any data to write (I'm using ClearSCADA by the way)? For example someone clicks on a control, do I have to intercept this and then set a write bit? I can't think of any other way.

This might be a bit of an issue because the client has a bunch of templates that I can't modify and need to use....

If you can't modify the SCADA, then you may have to compare the block of data you read from SCADA against the last block you wrote to it for any changes.

The SCADA can probably display a lot more values than it can write to, so you shouldn't have to compare the entire block of data, only those items that SCADA can modify.

Steve.....you are a genius!!!

On the scan back from the RTU to the PLC, for every setpoint, just added a NE_REAL instruction, looking at the Registers I last sent, and the Registers coming back, if not equal then SCADA has changed, and update PLC tag.

This gives HMI opportunity to write to PLC tag without being overwritten.

Many thanks!

Thank you for the kind words. Glad I could help.