ControlLogix Monitoring

Having been in the control field for a while, I like the flexibility of the Logix line from AB. There is lot of possiblities for the additional features like alias tag names, extended math functions, etc. Having used SLC's and many other controllers, it is nice to have this flexibility.

One problem is something of best practices. You see, we are using SCADA software and also web pages to view/control the C/Logix in a montitoring application.

The original ladder code works, but it is large and cumbersome. It includes math to convert to measureable production units, converts time units to seconds from the native millisecs. While the processor can handle this, albeit slower, our scada application could do all this math reliving the logix of this duty.

The advantage of doing the complex functions in the PLC is that we are not dependent on the sometimes unreliable SCADA software. The data is ready right from the controller, and the conversions only need to happen once.

The disadvantage is that it makes for a long, complex ladder program that is slower and more cumbersome.

I am curious to see what others have done regarding this. Thanks

I am fan of doing as much as you can ( meaning math and scaling ) in the PLC as long as it does not increase the scan time to point the main process logic is affected. When my math starts getting involved I make several different program files to divide the confusion. Many calculations like diameter and scaling are really dealt with once at start up and you do not have to worry about them again, hopefully. Also if all math is done in the PLC it makes trouble shooting easier. You have one place to make errors what you see in the PLC is what is on your MMI. Do not forget many times the PLC is not near the operator interface and save your legs.

Jim

J - E - T – S JETS JETS JETS

Thanks for the comment, I appreciate it.

I have streamlined the main process logic at least 60% which has helped execution time and the complexity.

The remaining issue was doing 'non-essential' math in the contoller. You got me thinking about something -- in the coming months we will be adding features to the system which will require math, thereby making it 'essential' (a few calcs will trigger alarm bits), so I am leaning toward doing all or most of this in the controller.

Thanks again

I also do the unit conversions in the PLC. If your SCADA system is down, or if you add other operator interface to the system, or if you tie in to de-bug the program, the convenient engineering units are right there for use.

While it is true that the math adds to scan time, in most processes this isn't a big deal. If you are worried about scan, one trick I have used is to put the engineering unit conversions in one or more subroutines that are only accessed on a periodic basis. If the conversion is made once a second, for example, the data update is still plenty fast for us mere mortals, and the PLC doesn't have to do the math every scan. If you have ten sets of calculations, acessed once a second sequentially, you have significantly cut the impact.

Solved

Done some number crunching and figure that when its all said and done, the scan time will be good enough, plus we will have the added advantage of a usuable unit(s) directly from the PLC.

Thanks guys!