Wonderware/Intouch & ControlLogix L73/RSLogix500 Interaction

[SoftwareJanitor]

Sorry for these basic questions. I'm a traditional structured text programmer who's been asked to take over the PLC and HMI coding here and I'm not familiar with the idiosyncrasies of these platforms.

1.) Of course, the Wonderware/Intouch (version 10) app writes to a button tag to change the Operating Mode, but I cannot find the full path to this tag in the InTouch app. I'm expecting to see something like I see in the PI definition [PLC20F]:OP_MODE, but all I can find is an "Access Name" for "PLC20F" which specifies a "Topic Name" of "RSLINX_PLC20F". Where's the connection made to the "OP_MODE" tag? Is that only in RSLINX (to maintain separation of church and state)?

2.) If Wonderware AND the PLC are *both* writing to this same "OP_MODE" tag, how do I know in the logic if Wonderware has modified the "OP_MODE" value in the middle of a scan (or can this not happen)? And if I want to detect when the Operator changes the mode (because the logic can also change it due to failures), then - since this thing is constantly scanning, I have to add logic to trap that out?

Wish these things were more event-driven, as in: press button on HMI, get entrance to a registered thread in PLC logic (instead of scanning everything all the time).

Or am I misunderstanding these things ...???

 

[mellis]

You're probably misunderstanding some things, it's common in this situation.

The path to the specific address in the PLC is in the tagname dictionary. That is where both the access name and the PLC address are defined for each Wonderware tagname. The Access Name defines the network path to the PLC.

The PLC code responds to a change in the tag from Wonderware(WW). What is usually done is that WW writes to a tag to request a mode change. The PLC evaluates that request and changes the actual mode if it is appropriate. The actual mode is usually a different tag. If your PLC is writing the same tag that WW is, then you may have problems.

Your point of view is probably not appropriate. You seem to see things as if WW was in control of the system. The PLC is in control, WW is just an interface. If you need to know if the operator changed the mode vs. some action of the PLC program, that would happen in the PLC program not WW.

The more specific the question, the better the answer. Generalized questions are easy to misinterpret.

 

[SoftwareJanitor]

OK, I see now that it is the "ITEM" name, together with the Access Name that defines the path. Mystery solved. I saw the tagname "OP_MODE" in the "Item" box, but the checkbox beside it "Use tagname as Item Name" wasn't checked, which confused me (since this name was the same as the tagname). I guess someone manually typed the name in twice but didn't check the box (when they could've just checked the box)???

It's one small step at a time right now...

As for the WW app being in control, I *do* know enough to know that the WW app is only an input device (well, OK, it also displays stuff), but I don't know what the conventions are when writing these PLC programs. I don't want to start doing unconventional things that others might have to deal with later. For example - part of me wants to write these programs like an assembly language program, with lots of jumps to labels, but I'd bet nobody does that.

So right now, the WW app actually *does* write to a different tag (OP_MODE_BUTTON) when the OP_MODE button is pressed, but only so it can display a pop-up asking for confirmation. THEN, if confirmed, it writes to the same PLC OP_MODE tag anyway. You're saying this is typically not done?

So I should re-write this by creating a bunch of WW "input" tags, and then create a separate WW routine in the PLC that checks these inputs and processes them accordingly? And the WW app would only set them for one scan, or would the PLC be responsible for clearing them?

Either way, that sounds like a good idea. And it would more clearly identify exactly WHAT tags the WW app was manipulating (although a carefully-chosen, hierarchical naming convention would also reveal that)...

=====================

Another basic question:

If I want to display a timer output as X mins, Y secs, is there an automated way to do that (in either WW or the PLC), or do I have to do the legwork myself?

 

[mellis]

Since you are using a ControlLogix PLC, you have tagnames instead of hard addresses. For simple cases, these can match the WW name. However, if you have a tagname with structure the WW conventions and the ControlLogix conventions do not match up. For instance, in the PLC a timer accumulator may be called "Timer1.ACC". WW will not allow a tagname with a "." so some accommodation has to be made.

It depends on your requirements. If your requirement is that it take two actions on the HMI to initiate an action in the PLC, then what you describe is adequate. This is very common practice. It prevents someone pointing at the screen from unintentionally affecting the operation.

If you are asking the operator to confirm that a condition exists (i.e. the manual addition is complete), then that should happen in the PLC logic.

The issue of writing directly to the mode tag depends on the way the rest of the code is written. But your original question was "If I need to know the operator changed the mode...". In that case, a single bit will not provide that information and a more complex structure is needed. Some systems would use an "operator request" and a "program request" for each possible state and a separate tag for the actual state.

The WW app has no way to set a bit for one scan. It can set a bit for a fixed time like 250ms. It can set it and leave it on. My preference is for WW to set the bit for a reasonable time like 250ms. The PLC code will turn the bit off after it has responded to it. The result is it will be on for something less than one scan.

The timer display is a good one. If you want it in minutes and seconds, you will have to format it yourself and it will be non-trivial. You will see a lot of people use seconds up to 900 (15 minutes) or minutes with a decimal point to avoid this problem. These choices only require scaling which is easy to do in the HMI. To do a display like hh:mm:ss with all the proper leading zeroes and colons will require some logic, math and string handling. I'd do it in the PLC and display the string. A basic guideline that I use is "keep the HMI simple, do the complicated stuff in the PLC". The main driver for this is I can make changes in the PLC while the system is running. Changes to the HMI require a shutdown of the HMI.