Is there a better way?

[Manglemender]

Philip,

I'm very glad that you're open to examining different ideas, it's a great way to learn and there are certainly some very knowledgable contributors to this forum.

I'm not convinced that your simple ladder method would be more efficient but I do conceed the point that it might be easier to understand. Poor documentation on the part of the original programmer is a more common cause of confusion.

Modern processors are so fast that code optimisation is a dying art. I still remember a time when I had to juggle priorities and execution sequences to get the cycle time of the program below 100mS and you would only use floating point maths if absolutely necessary; Many old S5 PLCs can't even do floating point maths.

I would recommend that anyone interested in PLCs should study assembly code/machine code programming first to gain an understanding of what hoops the CPU has to jump through to perform any given task.

Nick

 

[DamianInRochester]

The OP has an acceptable but not optimal solution.

I have posted links many times to the bit twiddling web pages.
Why do I bother?
Oh, please, some one provide an optimal answer.
Sometimes I think this forum is a waste of time if no one learns from the past.

That may depend on how you define optimal.

For an application such as this, clarity and ease of understanding should not be trumped by execution time.

 

[TurpoUrpo]

The OP has an acceptable but not optimal solution.

I have posted links many times to the bit twiddling web pages.
Why do I bother?
Oh, please, some one provide an optimal answer.
Sometimes I think this forum is a waste of time if no one learns from the past.

How would you do it? Those bits are not necessary in same byte or adjacent bytes.

 

[Clay B.]

I dare to say it.... god it is killing me... but Peter is right... bit twiddling is cool and can make a complex function simplier.

Basically what you would be looking for is the inputs as a word, then if this word is a power of 2 then it means 1 switch and only 1 switch is on. If more than 1 switch is on then you would not have a power of 2.



Now I do not know if Click can do bitwise functions but this formula will do the trick if it can.

f= (v&(v-1)== 0

f is your status bit and v is your inputs grouped as a word. Note the "&" is a bitwise AND function.

Now in the OP's example he is NOT using input X000 in his grouping so you function would need a condition since a 0 in our word with give us a true result.

IF (V > 0)
f= (v&(v-1)== 0

Also if you have unrealted inputs in the group you could use a mask on your "v" to filter these out.

Now the real question is.. Does the Click have bitwise funtions. Now you have something that will detect a simgle switch and it would only be 1 line of code per bank of I/O.

Downside most people will have no clue what you did.


See Peter... some of us have been reading your posts...


Side Note: The most common use I have for this is in Alarm functions. This lets me know if I have more than 1 alarm active at the same time. On several machines where I use a banner for alarm display I trigger another function for multiple Alarms versus single alarms.

If you are curious: http://www-graphics.stanford.edu/~seander/bithacks.html

Web Page with all kinds of tricks.

 

[TurpoUrpo]

I dare to say it.... god it is killing me... but Peter is right... bit twiddling is cool and can make a complex function simplier.

Basically what you would be looking for is the inputs as a word, then if this word is a power of 2 then it means 1 switch and only 1 switch is on. If more than 1 switch is on then you would not have a power of 2.



Now I do not know if Click can do bitwise functions but this formula will do the trick if it can.

f= (v&(v-1)== 0

f is your status bit and v is your inputs grouped as a word. Note the "&" is a bitwise AND function.

Now in the OP's example he is NOT using input X000 in his grouping so you function would need a condition since a 0 in our word with give us a true result.

IF (V > 0)
f= (v&(v-1)== 0

Also if you have unrealted inputs in the group you could use a mask on your "v" to filter these out.

Now the real question is.. Does the Click have bitwise funtions. Now you have something that will detect a simgle switch and it would only be 1 line of code per bank of I/O.

Downside most people will have no clue what you did.


See Peter... some of us have been reading your posts...


Side Note: The most common use I have for this is in Alarm functions. This lets me know if I have more than 1 alarm active at the same time. On several machines where I use a banner for alarm display I trigger another function for multiple Alarms versus single alarms.

If you are curious: http://www-graphics.stanford.edu/~seander/bithacks.html

Web Page with all kinds of tricks.

Care to look at post #6.

After that you can look at post before yours.

PS. Click is free.

 

[Clay B.]

Understand Click is free. I am just not currently using it so I do not know if it has bitwise functions. Hince the disclaimer.

I also said if bits where not adjacent then a Mask function would be required to elimanate bits not used by the function.

I did see your post 6, I was just showing the basic formula.

I also put in my post that on the downside most would not understand it.

It is just another method.

 

[TurpoUrpo]

Understand Click is free. I am just not currently using it so I do not know if it has bitwise functions. Hince the disclaimer.

I also said if bits where not adjacent then a Mask function would be required to elimanate bits not used by the function.

I did see your post 6, I was just showing the basic formula.

I also put in my post that on the downside most would not understand it.

It is just another method.

Think about it, if your switches are scattered in inputs, so that they are in many bytes, that wont be anything optimal. You need to do too much work to get them together first.

But:

With s7 it takes 5 instructions to do it, one could use fc with bool inputs and exploit how fc's work to get it efficiently done even if switches are located in random positions.

With others I dont know.

 

[Dravik]

The benefits of Bit Manip become more obvious as the number of bit positions you need to look at increases.
Can you imagine doing the same thing as in post #1 w/ 20 bypass switches?

 

[Clay B.]

Here is a RS Logix 500 method. As you can see I applied my mask directly to the inputs so my N7:0 integer was only the inputs I needed. I kept it small but you could expand this over several words or input cards as needed. With the mask function you are only looking at the inputs you want and are ignoring the rest.

I generally use this trick for alarms which I group together. So I have a trigger for mutliple alarms. I highly recomend looking at the web page I posted earlier as it also shows several other bit tricks. This is just one.

 

[Clay B.]

To know if you PLC can do this you need to know if it can do bitwise functions. IF it can AND a group of bits then this is possible.

TurpoUrpo... the first time I ever saw this doen was actually on a S5 in STL... Took me awhile to figure out exactly what they were doing...

 

[DamianInRochester]

Click can handle the bitwise functions.

It can also "copy" IO regsiters to data registers.

 

[L D[AR2P#0.0]]

Another ladder implementation:

 

[L D[AR2P#0.0]]

Think about it, if your switches are scattered in inputs, so that they are in many bytes, that wont be anything optimal. You need to do too much work to get them together first.

But:

With s7 it takes 5 instructions to do it...

Please show this implementation.

One instruction required to assign result leaving 4 instructions to process 5 booleans, or have I got the wrong end of the stick ?

 

[TurpoUrpo]

Please show this implementation.

One instruction required to assign result leaving 4 instructions to process 5 booleans, or have I got the wrong end of the stick ?

Bit twidler without mask in lad.

This:
f = v && !(v & (v - 1));

 

[daba]

I am in awe of the clever "bit twiddling" that can be achieved in so many situations - so much in awe that I would prefer not to use them.

Sure, I can mostly understand them, and that's what worries me, "mostly understand". I believe my PLC skill level is above that of most plant technicians who have to fault-find when the plant doesn't function properly.

Just remember, some of these guys don't see any PLC program for months, and then one day a problem will arise on a system they have never even looked at before.

My work has been entirely PLC centered for nearly 30 years, most of that time as a system integrator, writing code for clients. At the end of each job, I strove to feel comfortable that the code I left behind was easily followed and understood by those who might have to maintain, debug, and possibly modify or expand.

I would not make it hard for them, choosing the most "visible" and easily understood method in the majority of cases, even if I knew that the code would be less compact, and probably less efficient.

Sometimes, just sometimes, a "bit fiddle" is the most appropriate solution, and in these cases I would put as much description as I could to explain the functionality of the "less transparent" solution - to give maint. tech. a fighting chance. Of course we all know that (with some manufacturer's) the essential documentation may not be available at the crucial time !