SFC vs RLL

[manav 0]

I have a complicated ash vessel control application. Even though the I/Os are not many. About 50-100. All digital. Now this is basically a batch stepping application. And it fits right into SFC programming using Logix series. But due to the small I/O size client is not willing to move to Compact from MicroLgx. My options are limited if I program in RLL. The programming can be done but not in a standardized fashion with more time and space consumption in the processor. Any ideas on this? I have never used Sequencer control instructions and am dimly aware of what they do, can they be used to program steps? Any cost effective solution I can look forward to? Brainstorming would be appreciated here as the project is in its infancy. One approach that comes to mind is to use the JMP instruction and form steps in RLL. Or use a lot of JSRs. Any one had this issue where an application begs for SFC but has to be done in RLL due to cost? Any chances of the other languages being incorporated in lower priced controllers from RA in the future? Any other PLCs that can tackle this cost effectively? Responses here would be extremely appreciated. Thanks in advance.

[rpraveenkum 5]

use this sequencing example http://forums.mrplc.com/index.php?autocom=downloads&showfile=638

[manav 0]

Helps somewhat but not completely. Need to convert SFC flowchart into RLL. Any ideas on that?

[rpraveenkum 5]

see this http://forums.mrplc.com/index.php?autocom=downloads&showfile=25 or this http://forums.mrplc.com/index.php?autocom=downloads&showfile=26

[manav 0]

The examples are very helpful, but the problem is that the process logic of my application is quite complex. Lot of steps / lot of batches / lot of transitions & conditions. It is like a very large flowchart. I need some methodology / alternative to SFC in compact logix that can replace it without losing programming quality.

[jstolaruk 9]

You may want to review your quote and inform your client that the restriction of not be able to upgrade from MicroLogix to CompactLogix will result in longer development and debug time (ie more cost). Or if the price can no longer be negotiated it would be less expensive to absorb the cost of the hardware upgrade in order to save it in development time; tell the client the upgrade is free.

[rpraveenkum 5]

I hope you can fit flex logix controller in the place of ML for same cost

[paulengr 44]

If it's pure SEQUENTIAL or you have a small number of interacting sequential functions, you can trivially convert it into RLL. And it is very easy to debug. You don't use JSR's. You simply branch off the rung itself. Please don't use the SFC model in RLL. It's a pain in the rear to debug because as you said, there's no SFC diagram. It is POSSIBLE to write it this way, but it's a pain to work on. Just because it is hard to figure out a program where 95% of the ladders are NOT in use. Conversion process...Number your states. Choose an integer variable as your state number, say N7:0. Then check that on each rung... EQU N7:0 xxx <insert state operations here> ....where xxx is the state number. Use rung TITLES to label your states. Then it will show up as a tree in Logix 500 that is easy to browse/manage. Under the titles at the beginning of each state, put down what the state is doing, what the branch points are, etc., in the rung comment. The documentation this way is actually better than CLX (other than the fact that the structure of the program is not obvious). SQI/SQO operations can handle up to 16 states maximum (one for each bit). They CAN use simultaneous states but they are VERY difficult to debug overall. I have purposely removed them from several programs and I suggest you do the same for your sanity. If you want to do full blown interacting and simultaneous states, then instead of using sequential registers, you're stuck with using state bits. This is in itself not too bad except that it becomes somewhat more difficult to disassociate the states when necessary (the transitions are more obvious on the diagram). In this case, if you had a sequential state change, it would look like this: XIC x <insert conditional logic here> OTL y & OTU x (put in a branch and do both simultaneously). In this case, x is bit for the old state and y is the bit for the new state. Simultaneous branches are easy...just add more OTL's. There is a danger in using this bit form of logic which you have to be very vigilant for...getting states "locked up". It is very easy to accidentally leavy a state bit on. It is even easier for technicians who don't know quite what is going on to go in and toggle bits on/off manually, which can add very strange "race conditions" where you have multiple points of execution simultaneously. The reason for this is that you are truly working on a Petri-net model. There are no "illegal" states unless you specifically program for them...and coding up that situation is even worse than living with them (think dozens of rungs which take up memory and CPU but virtually never occur...and if they do, determining the appropriate action other than a reset/error is almost impossible). This is akin to watching out for "hazards" when you are doing standard reductions on boolean gate logic. In the integer form, you can't get into any of these extraneous conditions simply because only one state can be active at a given time. The worst case scenario I've encountered using this stuff so far is a batching controller that is loading batches to load into a cupola furnace for a foundry. There are 3 different stations which make up parts of a complete batch. Two of those stations have a single weigh hopper shared by 3-8 different ingredients so you have to weigh up one at a time. All 3 stations have to dump into a 4th station which is the skip bucket itself (the bucket that dumps batches into the cupola). The way that I programmed them is that each of the 4 different stations (bucket, batch station #1, #2, #3) are separate state machines (sequences). Two of the batch stations have separate "loops" of states with a common shared section of states. The "loops" correspond to adding different ingredients. Much of the code is common even in the "loops" obviously. Each of the 4 state machines (sequences) is contained within a separate PLC ladder since the interaction between them is small (deals with loading/unloading only). Once it was coded up and debugged, it has worked with very few headaches ever since. The only areas where I've run into problems are when the physical system can get into an "illegal" state that the logic didn't account for. For instance, having a batch station dumping with the skip bucket not in the location to dump into. So I had to add a few extraneous states to account for whatever strange things that operators may do with sticks and hammers and whatever else they might rig up to put it into states that are normally impossible. And finding and adding these is trivial to do. All the electricians can also read the RLL which is a huge bonus compared to the one time I tried to use SFC's in a PLC-5.

[manav 0]

FlexLogix will be about 30-40% higher. Basically unless the system goes over 200 digital I/Os flex or compact is really not cost-effective at all. My apps are using max of 100-120 I/Os. So for cost of INR 125k - 150k on Micrologix, user will have to pay about INR 200k for shifting to compact or flex. No one pays that much extra if the development cost is fixed and not negotiable.

[manav 0]

You seem to have put the whole situation in a concise form. What you have explained in a detailed format is the way to go for programming in RLL. But the problem is that for a small I/O system this approach requires extensive programming. Whereas the same program would be much smaller in size, more intuitive, easier to program, and much easier to monitor and debug, also the "operator confusion" states you mentioned are much easier to take care of using SFC. My dilemma is that for a large I/O system SFC would be available. For a small I/O app (<125) the end user always would want to pay as less as possible, and the programming time using RLL in Micrologix is much more than I would take to program a higher I/O count app in ST,SFC,FBD etc. using Flex etc. Still the suggestions you gave will be helpful. Thanks a ton mate.

[pimpim32 0]

Did you take a look at Panasonic's FPX ? I never used them but seems like they have the option to use FPWinPro software where you can use SFC or ST. Looks very impressive for a microPLC. Now I am waiting for the moment when I will make a project with FPX to see how it feels like.

[manav 0]

Not easy to change from RA products after using them for 5 yrs.