RSLogix 5000 "Live IO Simulation"

[AMarks95]

I don't know if this sort of debugging tool exists, but is it possible to "record" the states of tags in a 5000/Studio project over time and then "play back" later (while offline) as a "simulation" to see what happened?

 

[MorphuisOGrady]

I don't know if this sort of debugging tool exists, but is it possible to "record" the states of tags in a 5000/Studio project over time and then "play back" later (while offline) as a "simulation" to see what happened?

You could capture all data of interest in a trend. This can be exported to .CSV.

I think you may be limited to 8 pens per trend though so you may have to run multiple trends off a trigger.

 

[ASF]

Ignition SCADA has this exact feature, for exactly this purpose. I don't know of any really robust way to do it in Logix.

 

[Phrog30]

ignition scada has this exact feature, for exactly this purpose. I don't know of any really robust way to do it in logix.

+1

 

[JeremyM]

Ignition SCADA has this exact feature, for exactly this purpose. I don't know of any really robust way to do it in Logix.

In Logix:

Write into a circular buffer the values of interest and a time stamp. Stop on whatever condition.

OR:

Use the PlantPAx P_Intlk AOI and look at the first-out status when the object trips. I rolled my own based on this model and extended possible conditions from 16 to 32.

 

[Phrog30]

In Logix:

Write into a circular buffer the values of interest and a time stamp. Stop on whatever condition.

OR:

Use the PlantPAx P_Intlk AOI and look at the first-out status when the object trips. I rolled my own based on this model and extended possible conditions from 16 to 32.

But you are limited to the size of the buffer or using the AOI, 32. That's not very robust.

 

[JeremyM]

But you are limited to the size of the buffer or using the AOI, 32. That's not very robust.

a) The buffer depends entirely on the required monitoring interval. If it’s too small, make it larger. If the buffer size demands more controller memory, buy it.

b) You aren’t limited to one interlock object instance, nor should you try to shoehorn one into handling an entire process. We use one per device and our most interlock-dependent ones typically only approach 50% of the available inputs. Scope and break your problems into meaningful chunks.

 

[Phrog30]

a) The buffer depends entirely on the required monitoring interval. If it’s too small, make it larger. If the buffer size demands more controller memory, buy it.

Yes, well aware of how that works. The right tool for the job... goes back to just because you can doesn't mean you should.

b) You aren’t limited to one interlock object instance, nor should you try to shoehorn one into handling an entire process. We use one per device and our most interlock-dependent ones typically only approach 50% of the available inputs. Scope and break your problems into meaningful chunks.

Again, well aware on how it works. But, thanks for explaining.

 

[JeremyM]

Great. Happy to help, donkey.