Arranging multi-station code in single PLC

[BlackBamba]

Hi all,

A question about preffered ways to arrange/divide sub-programs on a production line with quite a few stations.

This line has products moving on a conveyor and going through 30 stations.
Each station has a separate code "block" (this is on RX3i. In general programming terms I would call that a sub-program).
A typical station code consists of:

- Calculations, converstions etc.
- State machine management (state changes, states history, jumps etc)
- Actual state machine (states)
- Outputs section
- Status monitoring + reporting

Including the comment rungs, this spans 100+ rungs for a simple station, and sometimes 400+ rungs for the complicated ones.

On average a station has 2-3 outputs.
At the minimum, a station has 6 states.
Which means the outputs section is just small percentage of the code.

Now, if I had a dedicated PLC for every station, I think I would have separated the code to sub-programs: state machine (maybe in ST rather than LD), outputs, status monitoring. This just FEELS like a better practice.
But doing so on a single PLC means breaking stations' encapsulation while creating a huge list of global variables that will be a nightmare to browse through.

What's more... I'm not actually sure there's real benefit in such code separation? since most often (when troubleshooting) one looks at the outputs and then goes to check the state machine - where the inputs are processed.

I hope I managed to present my dilemma clearly.

Would love to learn from what others are doing.

 

[parky]

Personally, I would keep most in the same block for that station, I would separate for example analogue processing & reporting as these are probably rarely needed for fault finding (think about others that may need to fault find on it). As you only have a few outputs per section I would put them at the end of the main code for that station, that way anyone trying to find a fault does not have to go from one program block to another.
I think it depends on the individual & how they prefer the code written, no matter what you decide it will not suit everybody, just wait for all the replies to this & you will understand what I mean.
Some people have a structure & will not divert from that regardless of the complexity be it needed or not, I find myself flexible and code according to a structure I have developed over many years, sometimes developing that from what others have done or requirements of the customer, however, a simple program maybe I will just write it all in one block & keep it simple.
ST to me does not inspire me, it was developed more on the lines of making code transportable, yes it has it's merits in calculations (more akin to high level language programming and duplication) but find it a little bit more difficult to monitor, ladder or FBD is graphical & shows the states better in my opinion, bearing in mind I started in assembler, C, pascal etc. so cut my teeth on structured text type of programming.
I find that FBD is just as quick to write but again it is peoples personal preference.

 

[cardosocea]

I find that FBD is just as quick to write but again it is peoples personal preference.

FBD doesn't lend itself to complex Boolean logic though... Plus, at least in the Rockwell world, it's annoying having to instanciate Boolean logic blocks as they're Add on instructions and not part of the logic as displayed in Ladder. This also opens up the possibility for people to, at least in the earlier generations of Logix 5000, save memory by reusing the instance of the BOR and BAND blocks which then makes the visualisation of them impossible.

On the ST, I find myself creating an ST subroutine/function and document the program and changes there under a large multiline comment. Other than that, it's great for calculations, but doesn't lend itself to be easy on the eye.

 

[parky]

"FBD doesn't lend itself to complex Boolean logic though..."
oh.. really, in Rockwell they may be AOI's but in others it's just a graphical representation of the ladder equivalent, on some IDE's they can be displayed in ladder. I cannot believe that bool logic is easier to write in ST. In many platforms the FBD functions are just compiled into what could be explained as assembler as could ST or ladder.
It also depends how you progressed, I was designing complex logic circuits using TTL & Cmos for many years, producing the circuit diagrams would be very difficult in ST or even in ladder, FBD (not including special functions) especially for bools I was bought up using the American standard for logic symbols & to be honest, found it a bit difficult to use the European ones in Siemens.
It's the same with Siemens, STL was difficult for some i.e. remembering the A(, O( & )) bracketing or in some of the Japanese ORB (cannot remember all of them) references to parallel branches etc.
Here is the Mitsubishi ladder verses FBD & the compiled code. You will see there is virtually little difference, there are some differences by using temporary memories this is due to how the FBD can be changed round to give the same result (I cannot go into why it produces different code but some years ago I spoke to the guy who did the original GXIEC IDE and asked him the question but it is to do with flexibility in connecting the FBD).

 

[James Mcquade]

i can only speak for AB plc5,500...
i would typically do the following.
look at your data table and see how things are set up and divide the table into segments.
1. general timers, counters, bits for setting the system up.
2. set up the bits for the different stations.
sta.1 b3/100-b3/199
sta.2 b3/200-b3/299
and so on. use more bits if required.
3. sta.1 t4:xx-t4:xxx. for timers. do the same for counters, integers and so on
divide the table up and see if they can fit into your scheme. work it out.
4. then code station 1 and see if it fits into your data scheme.
5. then repeat the process for the remaining lines.
let bit 0 be the station enabled bit, bit 1 be permission to run, and so on.
do this for all stations to help keep things in order for all stations. makes life easier.
james

 

[RockyLeafs]

We do this all the time but using AB software (RSLogix 5000)

In my programming, I usually have a main program to handle the general info of the line (date and time, global modes auto manual, conveyor controls, part selection)
Then have a program with each station, within that program I put difference routines for that station, for example: Modes, Homing, Sequence, Outputs, Production Numbers, Alarms.
I personally hate long routines where it is hard to find simple mode requests or outputs, etc.
With RSLogix/Studio 5000, you can easily keep the controller and program tags separate or alias them together. So you can have an AutoMode tag in every program, and alias that to a StnA.AutoMode tag... blah blah blah. Pretty powerful stuff.
We have done a lot of multiple station conveyor lines with very complicated cells and robot with no issue, and it keeps it clean.

My rule for programming, make sure you organize and write it like the next guy who sees it knows where you live and has a gun!

 

[BlackBamba]

Some people have a structure & will not divert from that regardless of the complexity be it needed or not, I find myself flexible and code according to a structure I have developed over many years, sometimes developing that from what others have done or requirements of the customer, however, a simple program maybe I will just write it all in one block & keep it simple.

Using FSMs definitely increases code volume. In this case, I chose consistency over simplicity, in a way. For example, all the stations have some common states (eg Off, Reset, Ready, Error), with identical names/numbers; S_400 means "Ready" everywhere. Or, the same built-in debugging tools (like state history, jump-to-state etc)exist in all the FSMs. So yes, you could say some stations are "over engineered" and this might make troubleshooting more complicated for someone seeing the code for the first time. But there are great benefits offsetting it.

ST to me does not inspire me, it was developed more on the lines of making code transportable, yes it has it's merits in calculations (more akin to high level language programming and duplication) but find it a little bit more difficult to monitor, ladder or FBD is graphical & shows the states better in my opinion, bearing in mind I started in assembler, C, pascal etc. so cut my teeth on structured text type of programming.
I find that FBD is just as quick to write but again it is peoples personal preference.

I didn't mean to spark a battle of "which language is better".
For FSMs, on GE/Emerson PACSystmes at least, there's no built in support and no LD equivalent for a SWITCH/CASE statement. I'm using jumps & labels for the performance gain (executing the active state code and skipping the rest). This adds 3 commands/rungs per state, and is... sort of ugly?

This project includes quite a bit of ST for the production process management - things like tracking products status, setting and resetting batch data. Some of these programs run relatively long and complex algorithems and it's much easier to do in ST. It's not just the math, but also loops and of course switch/case statements.

I've used FBD on other controllers and I'm not a fan of pure FBD. I find it easier when an IDE allows to inject some LD with the FBD.

 

[parky]

I think you mis-understand the case statement, when compiled it has to add the code for each case when it finds a match it then jumps round the rest so compiled code is sort of the same as writing it in ladder with compares but a jump round the rest look at a C compiled code for example.
So
in ladder it would be
CMP My_Var with 1 if true do something... JC Skip
CMP My_Var with 2 if true do something... JC = Skip
and so on

:Skip
So if used in this way with ladder it reduces the scan time by jumping round the rest of the code.
It is also possible to not bother with the jump just let the scan of the PLC evaluate all states if you want as only one will be true.
In Siemens STL there is an easier way by using the TAK instruction that swaps the accumulators so you do not have to re-load the My_var
Yes it looks like more code in Ladder but in reality there is probably no more code than in compiled ST.
And as it is easy to copy a rung of ladder then edit just the compare value will not take more time to code. I agree ST looks cleaner but I wish people would understand what really goes on behind the compiled code.
Not many PLC platforms will allow you to see the compiled code however,
While we are on the subject different platforms will produce the compiled code (some just compile it into instructions (hex values) then use a small interpreter to run the instructions so is not actually compiled into machine code as the processor would use directly). That was one of the ideas of ST to make it easy transportable to different platforms (not that it is all going to work due to differences in special interface cards i.e. analogue or coms).
Siemens S5 is a good example, the blocks were stored in memory just like the format of a hard disk, a block could be downloaded (actually the whole program) while in run mode due to a block i.e. program block 1 was written into spare memory, outside of PLC program scan the header info for it's original location is replaced with the location of the changed block so the old block is not called anymore, the earlier processors when doing on-line changes the old blocks filled up the memory so after a while a compress of the ram was required, later processors had an automatic compress to remove redundant blocks. Not many PLC manufacturers will divulge their processes. However, I have worked with a couple of engineers who have been involved in the development of PLC's and know some of the workings.
My rant on this subject complete so will not be commenting on this thread again.

 

[BlackBamba]

We do this all the time but using AB software (RSLogix 5000)

In my programming, I usually have a main program to handle the general info of the line (date and time, global modes auto manual, conveyor controls, part selection)
Then have a program with each station, within that program I put difference routines for that station, for example: Modes, Homing, Sequence, Outputs, Production Numbers, Alarms.
I personally hate long routines where it is hard to find simple mode requests or outputs, etc.
With RSLogix/Studio 5000, you can easily keep the controller and program tags separate or alias them together. So you can have an AutoMode tag in every program, and alias that to a StnA.AutoMode tag... blah blah blah. Pretty powerful stuff.
We have done a lot of multiple station conveyor lines with very complicated cells and robot with no issue, and it keeps it clean.

My rule for programming, make sure you organize and write it like the next guy who sees it knows where you live and has a gun!

Yeah well this line has about 60 routines in addition to the stations code...

I can split a station's code and keep all the relevant routines in a station programs folder - this will display nicely in the project tree.
The issue is with the variables. The RX3i/Machine Edition is not capable of aliasing the same way as the RSLogix5000. I can only alias in the same scope. I CAN have multiple variables in separate scopes assigned to the same memory (global) address though. But my current code uses symbolic variables where a fixed memory address is not strictly required.

Ok I just thought about this again... there's another solution that requires variables with reference addresses but will at least keep the variables truely local and won't require duplicate variable definitions: a "Parameterized Block" inherits the %L (local memory) of it's caller.
If I decide to split the code, this will be the way to go. Cheers mate!

 

[BlackBamba]

Yes it looks like more code in Ladder but in reality there is probably no more code than in compiled ST.

Oh I know how it works under the hood... But I AM concerned about the "looks" of the code and this is what this thread is about. Thanks for your comments, cheers!

 

[BlackBamba]

i can only speak for AB plc5,500...
i would typically do the following.
look at your data table and see how things are set up and divide the table into segments.
1. general timers, counters, bits for setting the system up.
2. set up the bits for the different stations.
sta.1 b3/100-b3/199
sta.2 b3/200-b3/299
and so on. use more bits if required.
3. sta.1 t4:xx-t4:xxx. for timers. do the same for counters, integers and so on
divide the table up and see if they can fit into your scheme. work it out.
4. then code station 1 and see if it fits into your data scheme.
5. then repeat the process for the remaining lines.
let bit 0 be the station enabled bit, bit 1 be permission to run, and so on.
do this for all stations to help keep things in order for all stations. makes life easier.
james

Thanks. My system is already developed though. Anyway it was developed in a different process, as it's a new-tech line and the software evolved together with the hardware, over a few years period.
Though it's interesting to think if I could have planned and developed it the way you suggest. My initial reaction is that this approach is more suitable for a system with many identical/similar stations, working independently.

 

[parky]

I know I said I would not make anymore comments on this thread, but well... I'm a glutton for punishment, I do not know the RX3I at all, I'm wondering if it is just an upgrade of existing way the PLC handles code to make it compatible with IEC, ST etc. some platforms did exactly this unlike RW who completely changed their platform, the idea of symbolic tags rather than fixed address space was for compatibility, however, some manufacturers used various methods to overcome this, for example they reserved some of the fixed address space for bools, integers etc. to act as local or global labels that were actually allocated at compile time however, these generally cannot be referenced by HMI's i.e. some still require actual addresses.
That is probably why you can assign a tag name without giving it an address, the compiler knows what address to give it. In PLC's that have actual address space it does not care what the symbolic or tag name is just it's location in the variable address space, that is why some platforms if uploaded from PLC to the IDE loose the symbols unless these have been stored in the PLC memory.
An example is Q series PLC Local labels and globals if not given an address but allocated to reserved areas of existing addresses i.e. for word area this is say D0 to D12000, so D900 to D1100 are reserved for compile time allocation so it will get a "D" address, globals that are configured with actual addresses i.e. My_Var10 is D200 & so on.