Pre-alpha testing is proceeding with my lab gear. When I have no apparent bugs in the major code paths, I'll turn the alpha loose. Soon.
2 Likes
The "fix" is now real, and public, as a beta. Please give it a shot:
2 Likes
I am testing this out currently. Initial tests look great. Thank you so much!
1 Like
Hi guys! This something related only with IA logix driver or it's something that will happen with several OPC servers?, kepserver for example.
Regards!
All users of the Rockwell CIP services for tag access will suffer if any element of a data type or AOI is set to "External Access: None".
Additionally, users of the Rockwell CIP services for tag access that strictly follow their published instructions (the linked data access manual) will be unable to optimize AOI data types and I/O module data types.
Rockwell uses undocumented services with its RSLinx drivers that I do not think any other company is using. But I haven't looked closely at what Kepware does. But even without those, there are opportunities for higher performance.
IA has a policy against using reverse engineering in drivers, where I do not. Ergo, my module's speed advantages due to looking under Rockwell's hood. So to speak.
1 Like
Good day, Phil,
Sorry for resurrecting a very old forum thread 
By any chance, do you know the Rockwell Document describing the security vulnerability of AOI's that cause a slower communication? Was it mentioned in some release note? So far, I cannot find any direct mentioning of this problem on the Rockwell site.
We are in the process of creating a standard for PLC and SCADA development and a more efficient addressing to UDT's should be definitely described in it. A reference to the source document would cut all of the arguments.
I would really appreciate any tips.
Thank you.
There is no such vulnerability that I'm aware of. Physical memory access APIs in Logix firmwares prior to v21 are implicitly insecure, but were never documented at all. Some vendors, including IA, used them for performance in their drivers. And had their legs clipped at their knees when v21 was released.
As for Rockwell not documenting the nuances of access to their AOI data types and various other object APIs, that is purely commercial exclusion. A legitimate position to take to limit exposure to technical support calls. ("You're doing what? That's not supported." <Click>.)
Hey Phil, I'm a bit embarrassed to ask, but how in Perspective do you recommend issuing commands from SCADA to xyz_cmd registers, and having them reset themselves from SCADA (without PLC writing to them) so as to avoid race conditions? This still confuses me.. would you suggest tag value change scripts to do this resetting?
For all my commands from the HMI write a 1 to a tag, then let the PLC reset it back to 0 once that command is "processed". Think like a reset button, or start and stop commands. I avoid using momentary buttons for 2 reasons. I've seen the unlatch/write to zero fail many times resulting in strange behaviors, and secondly it allows for slow periodic tasks to process commands reliably. So even if you have a 5 second periodic task, setting a value to 1 then the PLC resetting it is guaranteed to work compared to having an operator spamming the mouse button to get something to work.
3 Likes
Momentary buttons in Perspective are unreliable so I'd never use them in Perspective (same reason I never use jog buttons especially in Perspective). However Phil recommends against writing to the same tags from PLC and SCADA since it can and does cause a race condition which I see regularly. I often see issues with subscribed tags that set command tags in SCADA and reset them in the PLC automatically where the Ignition tag remains on but the PLC tag has turned off, regardless of settings like "read after write" and "optimistic writes" (I've tried all sorts of different combinations). The way to fix these (or rather work around the issue) is to use a polled rate, but obviously that's far less efficient on comms.
I was referring to Phil's post here:
The other issue with SCADA and PLC writing to the same tags is that sometimes the SCADA commands can be missed if it's written at the right time in the scan cycle. SCADA can set the tag and then the PLC will reset it immediately without actioning anything if it receives the value at the right (or wrong) time. You can work around this by storing the last value, but that's probably wasteful and annoying logic (I'm not a PLC guy)
Generally, you'd have the bit unlatch only after the desired action is performed. that way, if the cmd bit goes high during that rung's scan, it will persist until the next scan.
I always buffer my HMI commands at the beginning of my AOI (literally do a COP of my entire .Cmd tag to another identical tag, then only use that tag for logic and reset any bits processed as soon as they're processed (in both tags - buffered and unbufferred even though I really only need to do the unbufferred).
There are two approaches I recommend:
The simpler approach is to use short integers instead of booleans to fire events, like a reset pulse. Simply increment the tag, rolling over, and perhaps skipping zero. The PLC would notice the change and fire the boolean for you, for one scan (or whatever is appropriate).
The more involved approach is to use a timer event that looks for handshake bits in xyz_fbk indicating that the boolean in xyz_cmd was seen, to perform the Ignition-side reset. Just like ladder logic--scanning repeatedly for actions to take. The same timer event can monitor many signals, and can also be the handler for signals in the other direction.
(If you are using my CIP I/O Button in Vision, you need no other logic for momentary buttons, as long as the traffic is CIP Class1.)
2 Likes
First option sounds good! I'll look at using this from now on, thanks for the advice
Also, was I on the right track re the race condition if both scada and plc write to the same tag in a scada set plc reset setup?
That's one. The more common is a hiccup reading back while the PLC proceeds to set another signal, not realizing SCADA hasn't caught up.
Is this still in the same scada set / plc reset scenario, or would that be for other scenarios where the plc is writing other values, maybe set points
Here's an example, from PlantPax, that I use often. I will set OCmd_Start from the HMI and the PLC will immediately reset. Is it being suggested that the HMI could get stuck high? I ask because I have done this for a long time and have never seen it cause any issues. I have seen "stuck bits" using momentary commands, but not set/reset.
1 Like
Same here, I set the bit, the PLC resets it. Never had an issue with doing commands like this, and never had a bit get stuck.
1 Like
It's not the PLC tag that gets stuck, it's the SCADA tag that gets stuck occasionally for me. I'd like to understand it more technically (@pturmel @Kevin.Herron?), but it seems like the subscription gets stuck. SCADA writes to the tag setting it True, the PLC immediately resets it to False, but SCADA remains True indefinitely. Presumably it would get back in sync if the PLC tag changed from False to True, but I've had operators complain that command buttons don't work before, and it turned out to be this issue
1 Like