How to optimize communication between SCADA and Control Logix

Sometimes I want faster updates on my SCADA system. I've researched documentation from AB and found a few pointers but I also have a few questions and would be interested in someone on this forum providing their experience and advice.

Most SCADA systems don't support DINTs therefore creating INT tags will result in less overhead for the communications because I can cram more INTs into a single read request then I can do with DINTs. Perhaps I can have a routine that maps the DINT tags in the PLC to an Array of INTs. My SCADA system can then read from the Array of INTs. If I put the Array of INTs into a periodically scanned program that scans at the same rate that the HMI scan class is then my communications is optimized between the PLC and the SCADA system.

The PLC is a control logix v21+. The SCADA system is Ignition but I also use Kepware from time to time.

Optimizing your tags to read and write this way is great, you just have to keep an eye on how much data you can practically transfer in that manner. I've worked on a lot of old RS232 PV+ with SLC500 / CLX / MLX systems that did it that way.

dschmiddr said:

The PLC is a control logix v21+. The SCADA system is Ignition but I also use Kepware from time to time.

Click to expand...

You're points about DINT's aren't applicable to Ignition. Older platforms sure.

How fast do you need updates?

From a general ControlLogix perspective, you want to pack as much data together as possible. You can achieve this by using UDTs and and arrays. You could map as you have suggested, but on a ControlLogix I'd argue it isn't needed, just use alias tags in your PLC programs.

For example take the array SCADA_STEPS[0..100]
SCADA_STEPS[1], Alias to "Program1CurrentStep"
SCADA_STEPS[2], Alias to "Program2CurrentStep"

The PLC program uses Program1CurrentStep and Program2CurrentStep to make sense of the tag, while SCADA is configured to communicate with the SCADA_STEPS array. In Ignition you could use the same Alias tag name, but the OPC configuration would point to the SCADA_STEP[#] tag.

Creating a UDT of the various control tags you need, and putting that into an array for comms works very well in my experience.

ControlTagsUDT:
- StartCMD
- StopCMD
- CurrentStep
- FaultStatus
- FaultNumber
- StepTimer

Create the control tags array for SCADA communications:
SCADA_ControlTagsUDT[0..100]

Align the ControlLogix UDT with the Ignition UDT and life gets real easy.

Perhaps defining what is required to be fast communication and what isn't and make better use of the bandwidth this way? Ignition is quite simple at arranging this.

I worked on systems where all the user action and feedbacks were on 100ms comms and everything else on 500ms and this worked quite well. It wasn't however with a regular request and reply driver, but instead the PLC's sent data at that rate effectively cutting down the comms overhead.

Doesn't matter how fast you make it, don't forget that the operator needs to have the time to respond. I guess even if you achieve FullHD or 4K quallity/refresh rates, the operator will need at least 10 seconds (or minutes in most cases) to react. Using arrays really helps, but try to keep things close to what is required, millisecond refresh on SCADA doesn't give you much.

I like the idea of using alias tags.

One thing to keep in mind is tag name length, this can eat up a bunch of room on the CIP message. I would alias to tags for the HMI that have very short but also meaningful names. the last thing you want is a huge list of tags that you arn't sure what they are for.

mdim said:

millisecond refresh on SCADA doesn't give you much.

Click to expand...

For process SCADA, no. For machine control, it does greatly.

Speeding up SCADA

One purpose for pushing faster scan times is because the historian works off of SCDA tags therefore faster updates mean more data resolution.

Also, consider the need to poll from far distances. Best if the data was as compact as possible which I presume would be the same technique as designing for fast update times.

dschmiddr said:

One purpose for pushing faster scan times is because the historian works off of SCDA tags therefore faster updates mean more data resolution.

Also, consider the need to poll from far distances. Best if the data was as compact as possible which I presume would be the same technique as designing for fast update times.

Click to expand...

Why not create multiple scan classes. For things that don't matter put in a slow scan. Things you need to be fast, in a faster scan. Also look at leased scan classes, these are so tags only scan if on a window.