Rockwell PLC - Test philosophy - Need input

[dalporto]

See code at the bottom.


Hi all.


For the story, this is my first complete project using a Rockwell PLC, I've been mostly working with Unity Pro for the last 15 years.



So, I was planning a remap for about 40 analog values. You'll see that I use the value, a signal quality bit (which show #BAD on the HMI when the quality bit is off), and a signal fail which drive the alarm.


The SIM_ON (Simulator On) internal bit, when toggled, will mostly clear every alarm and place the PLC in a state of ready to start, and then I can use the other SIM values to test / FAT.



With a Schneider PLC, I have a block that I disable when the SIM_ON is true, giving me the opportunity to toggle whatever I want on the "output" side, so I can test every bit / value individually without having to double every tag I need, that don't look possible with Rockwell



Now, with that setup, I just figured out that I cannot force anything to individually test the _QUAL and the _F bit except for the local .Fault, which is useless as it is. This is mainly to prove that the right tag goes at the right place on the HMI/SCADA. When I turn off the SIM_ON, I have all alarm / statuses coming at once, which is useless.



The only thing I'm seeing right now would be to double the SIM tags, which I'm trying to avoid since I usually try to remove the feature before to give it to the customer, it's taking a lot of room and it's kind of busy work to do.



So, what's your take on that? I'm pretty sure some people had to do that kind of thing at some point. Basically, what would you do in that situation?



Thanks.

 

[5618]

I'm not sure how directly this applies to your project. Our style is to have dedicated IO mapping routines. That would usually be one routine for each analog (or digital) module, mapping the module points and status data to whatever tag is used throughout the program. Scaling and filtering of analog is done here as needed, but no other logic, just direct mapping.

On a system with about 50 Flex & Point racks, I did a separate routine for each rack, not each module.

There's rare exceptions to only 1:1 mapping, like a run reverse tag parallel with run for hardwired drive control when two outputs are needed for reverse.

So, about the only thing SIM_ON would do is disable the JSR to the module mapping routine and enable a JSR to a different routine where simulated values are mapped to the program tags. Any logic to automate changing test values would be there.

Of course there's exceptions here too as needed.

 

[drbitboy]

the only thing SIM_ON would do is disable the JSR to the module mapping routine

+1.

See here; I think this is directly analogous to OP's "block that [they] disable when SIM_ON" value is 1 in Unity Pro.

 

[dalporto]

Oh yeah, this is the stuff.


Thank you guys!

 

[cardosocea]

Now, with that setup, I just figured out that I cannot force anything to individually test the _QUAL and the _F bit except for the local .Fault, which is useless as it is. This is mainly to prove that the right tag goes at the right place on the HMI/SCADA. When I turn off the SIM_ON, I have all alarm / statuses coming at once, which is useless.

Worth pointing out that you can inhibit the module in the Hardware tree and write whatever you want to the .Fault and .Data variables. It is somewhat painful to do when you have 100 of them, but would allow you to do what you want without the SIM bit on. I've looked in the past whether it was possible to programatically do this (listing and inhibiting modules, but didn't get anywhere).

 

[joseph_e2]

Worth pointing out that you can inhibit the module in the Hardware tree and write whatever you want to the .Fault and .Data variables. It is somewhat painful to do when you have 100 of them, but would allow you to do what you want without the SIM bit on. I've looked in the past whether it was possible to programatically do this (listing and inhibiting modules, but didn't get anywhere).

When I'm working with a Logix 5000, I inhibit the modules and have a simulate program that writes to the input tags based on the outputs. I agree that it would be a bit painful with that many.



I don't know about listing modules programmatically, but you can use SSV instructions to inhibit/un-inhibit them.

 

[cardosocea]

I don't know about listing modules programmatically, but you can use SSV instructions to inhibit/un-inhibit them.

Thinking out loud, if one were to use ACM to generate code and hardware tree, it could be done fairly quickly to have an AOI per module inhibiting and reversing it.

 

[dalporto]

So far the solution proposed by Drbitboy and 5618 did the trick for me.


I dumped all the points I wanted to test in a separate section and turn the JSR down, then I can toggle the bits on and off.