Switch/Case Statement in Ladder Logic

Hi All

I am wondering if anyone has a nice way of implementing a switch statement in ladder logic. I have attached the version that I currently use (I haven't tested it, I'm writing it from memory as the actual code I don't have access to right now). What you see may not work perfectly but the basic Idea is correct, you enter the routine with some non zero value in the "Write" word. Then you jump to the parameter and then to sending the message. Now you might say, why not just write 2 separate message instructions, in the example that would work fine, but there are cases when we have 20+ parameters to write, so it becomes a lot of memory to have 20+ messages.

My boss wont let me implement this code in structured text, using the "Case of" instruction (Allen Bradleys version of Switch), he says that the ladder logic version is easier to understand, I disagree but he's the boss.

Has anyone come up with a better way, that does not make use of a lot of JMP & LBL instructions?

Thanks
Ian

You may be over-complicating this (or, I may misunderstand). But let's say you tell MSG_1 to send Register_1 to Destination_1. It is a simple matter to change the value in Register_1 between MSG send events. The problem I see (and in your application it may not be an issue), is how does the distant end (that receives the MSG) know which parameter you are sending? Seems to me that to do both (vary the value AND destination), you will have to use individual MSG instructions.

In this specific case I was talking about writing indexes to a kinetix 300 drive so the message goes to the same destination and the drive interperetes the message and updates the index. But let's say I wanted different parameters/drives I could change the msg.instance or msg.parameter or the msg.path to achieve this.

My main concern here is the switch part more so than the msg part.

All help great fully appreciated!

Too many JMPs and labels for my taste (I only use them for looping indexes into arrays). I've rather see some boolean tags setup to say conditions are true to "do this" or "do that" and position them as the first contact in the rung.

jstolaruk said:

Too many JMPs and labels for my taste (I only use them for looping indexes into arrays). I've rather see some boolean tags setup to say conditions are true to "do this" or "do that" and position them as the first contact in the rung.

Click to expand...

Couldn´t agree more, however it becomes quite complicated to do something like

...Par1....Par2....Par3....ParN.....Do Par1
---||-----|/|----|/|......|/|------( )

Its fine if you have 2 or 3 parameters, but if you have 20 parameters this becomes a beast to maintain.

For me the easiest solution is Structured Text, but since I´m not allowed to use it, I need to come up with something better than my current way in Ladder.

Usireland said:

Couldn´t agree more, however it becomes quite complicated to do something like

...Par1....Par2....Par3....ParN.....Do Par1
---||-----|/|----|/|......|/|------( )

Its fine if you have 2 or 3 parameters, but if you have 20 parameters this becomes a beast to maintain.

For me the easiest solution is Structured Text, but since I´m not allowed to use it, I need to come up with something better than my current way in Ladder.

Click to expand...

For me, one of the most important things to do when creating code is to make it as easy as possible for the next person to understand. If that means 20 rungs of what you call a "beast", so be it. At least the next person will understand it and I won't get a phone call asking "how does this work".
Yes, Structured Text has its place and its easy to create but its flow can't be traced and it can't be edited online while the PLC is running and some machines can't be shutdown. Pretty useless for the electrician trying to debug at 2:30am in the morning.

jstolaruk said:

For me, one of the most important things to do when creating code is to make it as easy as possible for the next person to understand. If that means 20 rungs of what you call a "beast", so be it. At least the next person will understand it and I won't get a phone call asking "how does this work".
Yes, Structured Text has its place and its easy to create but its flow can't be traced and it can't be edited online while the PLC is running and some machines can't be shutdown. Pretty useless for the electrician trying to debug at 2:30am in the morning.

Click to expand...

No I understand what your saying, I didn´t mean 20rungs would be a beast, but putting 20 XIC/XIO contacts infront of an output I think would confuse the operator more than than necessary.

I think there is not really a simple solution to this issue (other than writing various messages). If anyone has any other ideas, I´de greatfully appreciated it!

Usireland said:

No I understand what your saying, I didn´t mean 20rungs would be a beast, but putting 20 XIC/XIO contacts infront of an output I think would confuse the operator more than than necessary.

Click to expand...

I'm sure we can agree to disagree on this point. That rung you describe is a lot easier to debug than your previous example. Another individual can clearly see what is going on very quickly.