Conflict in STRP protocol to Rx3i?

Ozpeter

Member
Join Date
Aug 2014
Location
Virginia
Posts
124
This is probably going to be a dumb question. (and given my fat fingers in typing STRP .. I'm already off to a good start)

Imagine if you will that I have two Pro-Face HMI panels and that each has a momentary button on a screen. Each Pro-Face talks independently to an Rx3i PLC via SRTP. But each button wants to write to the same %M address inside the PLC when it is pressed.

What will happen?
  1. Will I reliably get the %M in the PLC to turn on and off when the button on either Pro-Face is pressed?
  2. Or will the (lack of) pressing the button on one Pro-Face interfere with the opposite action on the other Pro-Face?

My assumption is some form of the latter situation combined with a dose of asynchronous random timing that may make the desired action sort of work sometimes. But is my assumption correct?
 
Last edited:
This is probably going to be a dumb question. (and given my fat fingers in typing STRP .. I'm already off to a good start)

Imagine if you will that I have two Pro-Face HMI panels and that each has a momentary button on a screen. Each Pro-Face talks independently to an Rx3i PLC via SRTP. But each button wants to write to the same %M address inside the PLC when it is pressed.

What will happen?
  1. Will I reliably get the %M in the PLC to turn on and off when the button on either Pro-Face is pressed?
  2. Or will the (lack of) pressing the button on one Pro-Face interfere with the opposite action on the other Pro-Face?

My assumption is some form of the latter situation combined with a dose of asynchronous random timing that may make the desired action sort of work sometimes. But is my assumption correct?

I cant see any reason why it wouldnt work; however why not have a 'grant acess' button on each screen that can be locked/ unlocked at each screen- therefore ensuring only 1 HMI is writing to variables at any one time?


Regards

Daniel
 
I cant see any reason why it wouldnt work; however why not have a 'grant acess' button on each screen that can be locked/ unlocked at each screen- therefore ensuring only 1 HMI is writing to variables at any one time?
It's the "momentary" part that is troubling me. When you press on a momentary button it continuously writes a 1 to the PLC and when you release it, it writes a zero to the PLC. I don't know the SRTP protocol well enough to know if that writing of the zero is continuous or a one off affair.

If it is one-off I am OK, if it is continuous then the situation needs to be addressed some how.
 
The "momentary" specification means that each HMI writes a 1 to the %M address when an operator touches the screen object (mouse down event) and writes a 0 to the same address when an operator releases the screen object (mouse up event).
I can see some potential confusion if an operator at one HMI were to touch the screen object, and while his finger is still on the object an operator at the other HMI were to touch and release the same object. The first operator would think that the bit is still on when it is actually off.
Edit after reading your post #3:
Whether it is one-off or continuous is based on the HMI more than the protocol. In all of the HMIs I've had the opportunity to peek under the hood at, the writing of the 1 and 0 are one-off events.
 
Last edited:
The "momentary" specification means that each HMI writes a 1 to the %M address when an operator touches the screen object (mouse down event) and writes a 0 to the same address when an operator releases the screen object (mouse up event).
I can see some potential confusion if an operator at one HMI were to touch the screen object, and while his finger is still on the object an operator at the other HMI were to touch and release the same object. The first operator would think that the bit is still on when it is actually off.
Edit after reading your post #3:
Whether it is one-off or continuous is based on the HMI more than the protocol. In all of the HMIs I've had the opportunity to peek under the hood at, the writing of the 1 and 0 are one-off events.

But that depends on how the Rx3i handles multiple SRTP connections. It could aggregate them as an OR (if one button is on, then the bit is on), or it could aggregate them as an AND (if one button is off, then the bit is off) or it could just be last SRTP packet processed wins (The bit is on off on off on off …)
 
I'm pretty sure the PLC's methodology will be "last packet wins". I have seen several instances of multiple HMIs connected to the same PLC and have never run across any issues.
I'm equally sure that pushbutton events are one-off. Making "write" commands continuous is a waste of bandwidth. Back in the days when serial communications were the state of the art, the one-off model was the rule out of necessity to obtain a reasonable response time. I don't think the HMI manufacturers changed the model with the switch to faster communication speeds inherent in Ethernet.
Just as Modbus TCP is serial Modbus RTU wrapped up in an Ethernet protocol, SRTP is GE's serial SNP wrapped up in Ethernet.
 
I'm pretty sure the PLC's methodology will be "last packet wins". I have seen several instances of multiple HMIs connected to the same PLC and have never run across any issues.
I'm equally sure that pushbutton events are one-off. Making "write" commands continuous is a waste of bandwidth. Back in the days when serial communications were the state of the art, the one-off model was the rule out of necessity to obtain a reasonable response time. I don't think the HMI manufacturers changed the model with the switch to faster communication speeds inherent in Ethernet.
Just as Modbus TCP is serial Modbus RTU wrapped up in an Ethernet protocol, SRTP is GE's serial SNP wrapped up in Ethernet.

It probably makes sense for a single packet write on button press and another on button release, and last packet wins.

What may be confusing me is that I was also dealing with an Ignition HMI and I saw their momentary PBs do repeated writes to the PLC over OPC UA. This played hell with my logic that was expecting a single rising edge. This may have been an OPC UA artifact (or a configuration artifact), but it has made me nervous about things.
 

Similar Topics

Hello All, Looking to get a better understanding behind an issue that I had earlier today with a PIDE Instruction that was not changing it's CV...
Replies
3
Views
1,226
Good day all. I am trying to connect via RS-232 port to a SLC-5/03. I get it to autoconfig in RSlinx while creating the driver however, it then...
Replies
8
Views
2,005
Studio 5000 - strange error , "conflict exists in project verification state" I am trying to upload a test project to our 5069 controller we use...
Replies
7
Views
4,546
I have a camera system in a die that I am writing the program for. I have two tracks and capture two consecutive parts. The part out locations...
Replies
14
Views
5,243
Hello all, I have two identical cells. Each have a PLC, HMI, Laser etc. The IPs are also identical so for instance both PLCs are 192.168.10.1...
Replies
10
Views
4,437
Back
Top Bottom