Logix5000 Analog scaling and alarming

[jmalter 1]

I'm developing some standards for some of our projects and I'd like some feedback on recommendations and ideas. I'm somewhat new to Logix but have a lot of experience with 5's and SLC's. It was suggested, for analog inputs, to scale on the card to engineering units. What are the advantages/disadvantages? It looks pretty straight forward but I seem to recall some limitatiions. There are many ways to handle analog alarming including ladder, function block, and at the HMI. I plan to make the PLC routine generic therefore requiring Low, Low Low, High, High High alarming and the ability to enable/disable the point. The function block item appears workable but we have to consider conditional alarms; such as ignore low suction pressure until the pump has ran for 5 seconds. I'm not sure how to handle these types of conditions with the function blocks. I'm intersted to hear what the PLC experts out there think. regards, Joe

[Ghettofreeryder 0]

Heres what i normally use. It has built in bypass timer, debounce timers, latching, etc. It also allows different raw max/min if u use different cards ie 1756-IF8 vs 1794-???. There is also an example of firstout logic as well, although i dont know what u need for alarming on your project Test_Buffer.ACD Edited 26 Apr 2006 by Ghettofreeryder

[jmalter 1]

Thanks for the example program. I like the use of subroutines and gerneral program structure. I have a few comments/questions: 1. Don't you have problems using timers in subroutines? It seems like the timers would not work independantly for each run through the subroutine. 2. I'm not crazy about the negative logic used is comparing the PV to the setpoints. It's less intuitive but works. Did you need to do this for a reason?

[TimWilborne 108]

1. The use of timers in unconditional subroutines is the same as timers in the main routine. I prefer to have most code in subroutines for organization 2. Can you be more specific about what you are talking about here. Are you talking about the greater and less than instruction? Can you explain what you mean by less intuitive? Can you give an example of how you would do it? Just curious, yours might be better.

[jmalter 1]

1. Not if you call it from another routine multiple times, unless I'm missing something. The logic enabling and resetting the timer changes each time you call the subroutine with different variables. For example if you first call it for PIT-101 and PIT-101 is above the High setpoint then the high setpoint delay timer should start timing. Then the program leaves the subroutine, back to main, and then back to the subroutine with PIT-102. If PIT-102 is below it's High setpoint the timer will reset. Your logic is slightly different using the TOF timer but the concept is the same. 2. I'm talking about the GRT, LES type functions. It makes more sense to me that when the PV is greater the setpoint then it's in alarm. Your logic is if the PV is less the setpoint then it is NOT in alarm. It works the same but not as clear.

[TimWilborne 108]

1. I haven't actually tried Ghettofreeryder's code in a processor but it looks like it will work. It is not actually multiple jumps of the same timer, the timer is passed to it. You could pass 100s of timers this way. As far as the actually analog code, I can't say whether it is good or not. But the flow looks functional 2. Thought you meant you had something different than greater and less then instructions

[Ghettofreeryder 0]

1) I have used the logic in many applications. As TW said, you are not using the same time, but you are buffering the data in and out(Buffered Subroutine). While the subroutine all use the same buffer, it functions as though you were to use direct addressing and copy it repeatidly.You can alos modify the logic to run indirectly, but i think that buffered subroutines are a good way to run repeated code. 2) I am use to seeing everything as a positive, or 1. When an input is wired fail safe, it is normally a 1 while running. So any time i see a 0, i use this to signify a bad value or situation. The only logic i use that is opposite this is my first out logic, where 1 means that was the first out. If you want, i can write the logic using a 0 instead of a 1 if you want.

[jmalter 1]

Thanks for your advice. I found a good document called Logix5000 Controllers Design Considerations, Publication 1756-RM094A-EN-P, that has a lot of good information specific to logics. There is a good section on programming methods covering Inline duplication, Indexed routine, and Buffered routine. I'm all for fail safe logic hardwired inputs but once it's in the PLC you can handle the logic anyway you prefer. We prefer using a normal closed (XIO) PLC internal to a coil that goes high (1) in alarm.

[Ghettofreeryder 0]

Yeah man, I highly recommend that document. Thats actually the most valuable piece of documentation when ur first starting with a clx. It helped me anyways. Maybe post it on the forum. Another good document is the PIDE document, I will post it. I like running buffered subroutines compared to indirect because not only is it quick to program, its easier to modify for special situations, such as changing from a normal pide to some other way of control. It also runs faster then indirect programming. The PIDE document I have is Publication LOGIX-WP008A-EN-P 1756_rm094__en_p.pdf Edited 2 May 2006 by Ghettofreeryder

[jmalter 1]

I used your basic concept and made some adjustments to meet our requirements. I am experiencing one problem with our HMI interface where I sometimes have a hard time writing a value to the PLC. My guess is the subroutine resets the controller tag with the data returned from the subroutine. The values "take" when the program is not in the subroutine for that item. The HMI is Wonderware Intouch and we are reading the controller tags such as PI-101. We make the alarm alarm limits available to the operator (password protected). I sometimes have to enter it 3-4 times before it takes. Any suggestions? AI_ScaleAlarm.ACD Edited 11 May 2006 by jmalter

[TimWilborne 108]

Never really seen that behavior. What type of network is it. I do something similar on Ethernet, Devicenet and DF1 to Standard Panelviews and do writes from VB through RsLinx and have never had trouble getting the information into the PLC. But this may get you going. I don't know a lot about Wonderware but if it can do something like handshaking and notification then use it. Write your tags to some buffer then in your PLC program look for the notifcation tag and and write from the buffer to your PI-101 when it is true and set the handshake tag

[Ghettofreeryder 0]

I have never had such a problem. I have tried the logic with RSview, factory pmi and panelview plus'. What HMI are you using. You are referencing PIxxx right, not AIxxx

[TimWilborne 108]

Yes I have thought about it more too and there should not be a problem with writing too it since the message to Wonderware should happen during the overhead. The only time this could be a problem is if it was processed during the subroutine which from what I understand would not be able to happen in a communication between Wonderware and the PLC

[Ghettofreeryder 0]

Yeah, well, i dont think thats entirely true, the communication portion will "cut" into any routine with a lower priority, but i dont think this will affect the analog routine because the Tag has already be moved into the buffer, so its actually almost better to run the buffered routine if u think about it. I would say its a problem with your hmi, but we'll need some more information. I will try the logic with WW when i get back to the shop and let you know if i see the same problems Edited 12 May 2006 by Ghettofreeryder

[TimWilborne 108]

Actually isn't Wonderware processed the same as RsLinx or a message? If so it would come during the system overhead time slice

[jmalter 1]

I've have link thousands if not tens of thousands of points between WW and AB plc's without seeing this type of problem. I'm pretty confident Wonderware is not the issue. (although I think there is a way to tag browse with DASABTCP server. I've haven't had a lot of luck or much time to look into it.) The problem appears to go away if I enable the 4 AI JSR's in the sample code. I think my original assumption is correct. With so little logic the processor is spending a lot of time in the Alarm scaling and alarming subroutine.

[TimWilborne 108]

I'm leaning towards the System Overhead Timeslice. I'm pretty sure this is where your Wonderware messages are being processed. Try increasing it. It can't hurt

[Contr_Conn 4]

I am not really familiar with CompactLogix, but in the example above I would take a look at 2 ms RPI for local modules. Do you really need 2ms for AC I/O that has signal period of 18ms? You should remember that Compactligox and flexlogix using only one microporcessor to control I/O and process logix and comms. Also with high volume communications you should bump overhead timeslice up to 45% And going from cont. task to multiple periodic will help with comms. Edited 12 May 2006 by Contr_Conn

[Ghettofreeryder 0]

Yes, but the information is only loaded into the buffer once, so even if the i/o communication occurs in the middle of the subroutine, it will not affect it because the data INSIDE the buffer will not change. And if the communications occurs during the time slice, this will not affect the subroutines