Familiar with SLC, Control Logix, not so much...

Hey guys:

I'm pretty familiar with SLCs and have been doing a lot of troubleshooting and quite a few mods with them lately. I bought one for personal use as a testing platform and learned on the SLC/ML platform.

Now I'm soon to be presented with a new task, and will have to do a simple program on a Control Logix platform. I'm not that worried about the new tagging system, but what is concerning me is the asynchronous scan cycle versus the synchronous scan cycle.

What are some of your guy's opinions of what I will have to worry about with the scan cycle while designing the new program. It will be as simple as a few safety's and photo eyes to detect jams and a motor starting circuit. I'm mainly interested in organization and the difference between the two scan cycles.

I have spent hours reading and absorbing, but I would also like some fresh opinions/experiences on the subject.

This might help? http://www.inetdaemon.com/tutorials/basic_concepts/communication/asynchronous_vs_synchronous.shtml




Good luck

With the CLX series controllers you will frequently come across a programming technique that uses mapping. At the beginning of the program, all of the inputs are copied to a new tag(typically an array), these copies are used instead of the actual inputs (e.g. Local:...). Within the main body of the program, instead of writing directly to outputs, the values are written to an intermediate tag. At the end of the program, these "output tags" are then copied to the real outputs.

This technique does a couple things for you and one of them is to avoid the "gotchas" caused by asynchronous IO scanning. Since you take a snapshot of the inputs before the main program scan, an IO update will not change these at some random point in the middle of your program scan which could wreak havoc. This in a sense makes the ControlLogix program function similar to the SLC/Micro.

Thanks guys.

Archie: Yea I ran into this the other day when troubleshooting an SLC system. It took me a minute to figure out what they were doing, as I hadn't seen it before. They were copying each input and output to an N7 word and then at the end of the cycle moving a value to the word. I'm still quite interested in opinions and comments.

sparkie said:

Archie: Yea I ran into this the other day when troubleshooting an SLC system. It took me a minute to figure out what they were doing, as I hadn't seen it before. They were copying each input and output to an N7 word and then at the end of the cycle moving a value to the word

Click to expand...

I never agreed with doing this in the SLC/Micro because it made the program more difficult to troubleshoot by adding this extra layer and provided no real benefit. The only justification that I ever hear for it was to make it easy if your IO cards were moved. Nothing a search and replace couldn't do just as fast.

Long ago I adopted the philosophy that the engineer/programmer should not do something to save himself time if it is going to make it more difficult to maintain. Programming time is done once, maintaining time is done hundreds. Often programmers will try to save themselves 5 minutes, but cost maintenance hours. I think on here it is often referred to as the "Bubba" principal

Yea, the reason for doing this didn't make sense for any reason to me. I have seen large copies to N7 in order for an older PanelView to be utilized, but didn't much see the point on our other, simpler systems.

I've been scouring the web for some good programming practices on the CL platform so I can get a test bench going and work on making some basic programs as the differences in the scan cycle are a bit confusing to me still.

It seems that as you complete, for instance the following rung:

--| Push Button NC |--|Push Button NO |----( Output 1 )---
..|.......................|
--|------| Output |--|

The output would be immediately turned on once the NO push button was turned and once the NC Push button was pressed while on that rung in the scan cycle it would immediately turn off, and then the program would continue on down the line.

Am I correct in interpreting it this way with interrupts and other forms of process scheduling left out of the equation?

This explained it quite clearly for me...

http://www.contactandcoil.com/rslogix-5000-tutorial/mapping-your-inputs/

WillM said:

This explained it quite clearly for me...

http://www.contactandcoil.com/rslogix-5000-tutorial/mapping-your-inputs/

Click to expand...

Thanks for the info. I'm setting up a test bench Monday and digging into this. Almost all of our PLCs are SLC500's but we do have a few CL systems around the plant I have to work with, so I suppose it is about time I started familiarizing myself with the platform and software more.

sparkie said:

Thanks for the info. I'm setting up a test bench Monday and digging into this. Almost all of our PLCs are SLC500's but we do have a few CL systems around the plant I have to work with, so I suppose it is about time I started familiarizing myself with the platform and software more.

Click to expand...

That sounds the best thing to do. Try and simulate the potential pit falls.

As mentioned earlier mapping the IO helps stop any issues. In our spec we have to map everything. Analogue, Digital, Alarms, HMi tags.

I Deffinately Agree with the Keep It Simple attitude.
But as a more maintenance and small modifications Guy I have to say it is more than that. I work on older equipment (I have yet to deal with rslogix 5000 since school) and I find quite often too many people have made changes and not followed the standard set out by the original programmer. This makes it very hard to trace or troubleshoot things. I was taught from.the start to try and follow the existing programs standard and also to document all my changes .

DwSoFt said:

I Deffinately Agree with the Keep It Simple attitude.
But as a more maintenance and small modifications Guy I have to say it is more than that. I work on older equipment (I have yet to deal with rslogix 5000 since school) and I find quite often too many people have made changes and not followed the standard set out by the original programmer. This makes it very hard to trace or troubleshoot things. I was taught from.the start to try and follow the existing programs standard and also to document all my changes .

Click to expand...

Well, I am the singular only PLC guy at my plant. I'm like you, very few projects where I actually program a PLC. I also read the logic so that any changes I make fit in with the system the original program chose.