code for 1 pushbutton and one light

A

Thread Starter

Aaron Gascoyne

Using Rslogix 5 I need to come up with the code for 1 pushbutton and one light.

The way it works it :
Push the button once and the light turns on, push it again and the light turns off.

Thanks guys, I am just looking for hints.
 
Easy look at the light, push button if light is off latch light on, push button if light is on unlatch
 
R

russjones100

with all due respect you are more than a little bit out of your depth with plc's if you can't think your way around this one . This is
hardly rocket science .just think how you would make a latch with two pb's and use one !!
 
J

Jeremy Pollard

Real easy
XIC <input> CTU (preset not important) [on branch] xic ctu:acc/0 ote <light>

EG xic I:12/10 bst ctu c5:0 0 0 nxb xic c5:0.acc/0 ote O:11/0 bnd

neat eh!

Cheers from:

Jeremy Pollard, CET
[email protected]
On The Web - http://www.tsuonline.com
PLCopen North America - [email protected] www.PLCopen.org
the Training Factory, Inc.
Programmable Controller Support Systems
The Software User Newsletter ONLINE
The Crazy Canuckian!
8 Vine Crescent, Barrie, Ontario L4N 2B3
705.739.7155 Fax 705.739.7157
 
F

Friedrich Haase

Moin Mr. Gascoyne,
moin all,

this might help you

instruction list
================
LD button
XOR light
ST button

structured text
===============
button := light xor button;

ladder diagram
==============
button H1 H2 (* H2 rising input edge *)
--| |----|/|-----( )--
button H1 (* H1 keeps last input value *)
--| |------------( )--
H2 light light
--| |----|/|--+--( )-- (* toggle Q when input changes *)
H2 light |
--|/|----| |--+ (* keep last Q when no input change *)

Regards
Friedrich Haase
 
T

Trevor Ousey

<pre>
try

-------| |----------|\|----+-----(L)------
I:1/0 O:2/0 | O:2/0
+-----(U)-----
I:1/0

-------| |----------| |----+-----(U)------
I:1/0 O:2/0 | O:2/0
+-----(U)-----
I:1/0

Note this needs to be modified for ControlLogix, but you get the idea.

Cheers,
Trevor Ousey
</pre>
 
R
You HAVE to use an OSR or ONS (depending on CPU) for A-B, or a DIFU or DIFD for Omron, or the equivalent one-shot relay for other PLCs.

Rob
RoTaTech
 
E

Eric Klintworth

Neat, yes, but you had better reset that counter sooner or later... If you don't, the processor will fault when the counter accumulator tries to count past 32767. (Right after the warranty period expires?)

Eric Klintworth
Sharp Technologies, Inc.
Columbus, Ohio
 
M

Mauricio García

the next code will do a on/off with the same input.

/* next lines are the program */

bst xic i:0/0 nxb xic b3/0 xio b3/3 bnd ote b3/0

xic b3/0 bst xio i:0/0 nxb xic b3/1 bnd ote b3/1

xic b3/1 bst xic i:0/0 nxb xic b3/2 bnd ote b3/2

xic b3/2 xio i:0/0 ote b3/3

xic b3/0 xio b3/2 ote o:0/0

/* end of program */

In a new project doubleclick the rung number, and it will pop a text box. You can copy & paste the program, just copy each line into a new rung and you will be ok

M.
 
J

Jeremy Pollard

Sorry Eric - the counter ACC value is a circular buffer so that when it goes to 32767 then the next value is -32768 then -32767 towards 0 then up it goes and it repeats. No overflow.

Honest it works well


Cheers from:

Jeremy Pollard, CET
[email protected]
On The Web - http://www.tsuonline.com
PLCopen North America - [email protected] www.PLCopen.org
the Training Factory, Inc.
Programmable Controller Support Systems
The Software User Newsletter ONLINE
The Crazy Canuckian!
8 Vine Crescent, Barrie, Ontario L4N 2B3
705.739.7155 Fax 705.739.7157
 
J

Jeremy Pollard

The counter takes care of the debounce since it is transitional by nature. An OSR or equiv would react the same way. The only issue might be a timer that extends the pulse, but is it really necessary? Assume that the operator will know what to do if he does have a trigger finger

Cheers from:

Jeremy Pollard, CET
[email protected]
On The Web - http://www.tsuonline.com
PLCopen North America - [email protected] www.PLCopen.org
the Training Factory, Inc.
Programmable Controller Support Systems
The Software User Newsletter ONLINE
The Crazy Canuckian!
8 Vine Crescent, Barrie, Ontario L4N 2B3
705.739.7155 Fax 705.739.7157
 
H
Let's agree that Jeremy came the closest to what I call an appropriate solution.
It is interesting to me to see the various responses to this rather simple question. This toggling action is something that we have to deal with quite a bit in real world PLC control.
I would cringe having to explain a five line, 27 instruction solution to a maintenance electrician (yes it may work, I can't be sure of it though
because I'm writing this on my own time and I can't afford the time to check it out - picturing myself explaining the solution is what bothers me). And there is something technical wrong with the bit banging solution: The toggle state is lost when PLC power is removed (but hey, that may also be just what someone needs).
There was a poster worrying about contact debouncing: That is what we have a PLC for (debouncing is built in to the modules). There was someone worrying about counter overflow: That is what practical experience is for, we try it out before going to the production setting. And
we find out it does not matter. PLC instruction design takes care of counter overflows.
There were a number of bit banging solutions. While it is instructive to follow these through (and while I have to admit to having created my share of these with PLC-2 hardware), they are not an appropriate solution in 2002.
So, until the Open PLC Project makes available a Toggle Instruction this is the best solution:

xic I:12/10 ctu c5:0 999 0
xic c5:0.acc/0 ote O:11/0

The task requires two rungs, the counter preset does not matter (Jeremy's original single rung with branch does not work as intended (and if the
branch is extended to the left to include the input button, it becomes a waste of time)). Name the counter "Toggle" and everyone will know what it is for.

Hugo
PLC Guru, King of MMI
 
J

Joe Jansen/ENGR/HQ/KEMET/US

Actually, it is not that simple. Because of the scan order of the processor, the light will always be off, using your example below. The reason for this is as follows, if you step through the process:

rung 1: button pressed, and light is off. Latch light on

rung 2: button pressed and light is on, unlatch light.


Remember that the I/O is updated at the end of the scan, therefore the button will be pressed through the entire scan (not to mention the fact the scans are in the millisecond range...) Therefore, starting from scrath, light off, button gets pressed. Rung 1 will turn the light on. Next rung 2 scans. The button is still pressed, and the light is on (you just turned it on, remember?) so it gets turned off. If you reverse rung 1 and 2, the light will always be on.

There are other 'tricky' ways to do this, but I have found that the method that makes the intent the clearest is:

rung 1: If button pressed, and light is off, Latch light on and turn on a 'just turned on' bit.

rung 2: if button pressed, and light is on, and 'just turned on' bit is off, unlatch light.

Finally, insert a rising edge one shot after the button pressed contacts on both rungs. What you end up with is:

{I:1/0 is the button, O:2/1 is the light, B3:0/0 and B3:0/2 are one shot bits, and B3:0/1is the 'just turned on' bit}

XIC I:1/0 OSR B3:0/0 XIO O:2/1BST OTL O;2/1 NXB OTE B3:0/1

XIC I:1/0 OSR B3:0/2 XIC O;2/1 XIO B3:0/1 OTU O:2/1

This can also be combined onto a single rung (which is how I typically do it) as follows:

{Same address names as above, but we only need one 'one shot' bit this time}

XIC I:1/0 OSR B3:0/0 BST XIO O:2/1 BST OTL O:2/1 NXB OTE B3:0/1 BND NXB XIC O;2/1 XIO B3;0/1 OTU O:2/1 BND

Which requires your input, output, and 2 bit addresses per toggle.

As I said earlier, there are probably cooler ways to do it. I have seen some that use JMP instructions to skip the 2nd rung if the first executes, etc. but I find that those methods are more confusing to others who may come after you to troubleshoot. Unlike some programmers I hear about on this list, I *do* have to carry the pager, and all 3 shift managers have my home phone #, so I tend to try to make things simple enough that our night shift techs can understand the intent....

Hope this helps!

--Joe Jansen

PS. I will be sticking this in the archive (www.plcarchive.com) as soon as I get my PDF driver working again..... :^}
 
B

Blunier, Mark

> Let's agree that Jeremy came the closest to what I call an appropriate
> solution.

I will agree that it is closest to what YOU call an appropriate solution, but it was not the solution posted that I liked best. I liked Friedrich Haase's solution the best.

button : light xor button;

ladder diagram::

button H1 H2 (* H2 rising input edge *)
--| |----|/|-----( )--
button H1 (* H1 keeps last input value *)
--| |------------( )--
H2 light light
--| |----|/|--+--( )-- (* toggle Q when input changes *)
H2 light |
--|/|----| |--+ (* keep last Q when no input change *)

Mark Blunier
Any opinions expressed in this message are not necessarily those of the company.
 
J

Joe Jansen/ENGR/HQ/KEMET/US

I thought just the opposite, actually. Using a counter to toggle a bit seems about as indirect as you can get. You are controlling bits, counting anything. While I give credit for creativity, it is not the simplest solution. Your electrician would have to understand that odd is on and even is off, except once every 64,000 and some cycles where they press the button and it won't work (crossing from 32767 to -32767 the bit stays on). This could also have functional repercussions if you are looking for general use toggling. A button can be pressed again. A sorting conveyor may not be as forgiving.

As for loss of state on power cycle, use a retentative bit. AB processors maintain state thru a power down completely. Every other PLC I have worked with either battery backs it's ram, or as a minimum has an area of memory that will keep it's state.

In the end, I cannot agree that the counter is the 'appropriate solution'. Tricky and clever? Absolutely. Clever is what gives you a phone call at 3:00 am, though. I prefer simple and straightforward, without any known bugs, no matter how infrequent.

--Joe Jansen
(No claims of religious enlightenment or royalty, just a guy doing his job)
 
P

Patrick Cross

I agree with Joe on this one.

I also thought that the counter solution was abstract and that 'electricians' would have a hard time understanding it. I tend to prefer a five line solution that is self-explanatory rather that a clever one or two line solution.

I learnt this lesson a few years ago when programming a Square D PLC at a particular site. These PLCs have a lot of scope for implementing very complex operations in single instructions and Control system engineers on previous projects had utilised this as much as possible to save memory. When I did a project at that site I was specifically asked by the electrical supervisor to spell everything out in the logic so that it was quite obvious. I had to cop a lot of criticism and 'I could do that in two lines' attitude from my engineering colleagues during review phase, but the customer (the electrical supervisor) was very happy with the result as he could understand the code very easily.

The worst example (from a maintenance perspective) of 'clever solution' I've seen is in a PLC3 at a brewery. The logic for all the valves was programmed using file operations, ie. to AND to bits together, instead of using XIC B3/1 XIC b4/1 OTE B5/1 the entire B3 file was compared with the B4 file and the result placed in
the B5 file. Completely ingenious and managed to fit a huge amount of functionality into one processor, but completely impossible to debug. Whenever something went wrong with the sequence, they had to shut the plant down, run a routine in the PLC that reset all the memory and then start the plant up again. Needless to say when that PLC was upgraded there were specific requests to program the PLC in an manner that was easy to understand.


Regards

Patrick Cross
Control Systems Engineer
Western Mining Corp. - Olympic Dam
[email protected]
 
J

Jeremy Pollard

32767 to -32768 bit 0 does toggle.:) Uses 2's complement to represent (or that might be 1's complement, but whos counting) If you are wanting to create a selector switich, then this works. If you want a known state at start up then reset the counter in a start up routine. In AB there is a bit for first scan which you could use.

If an Electrician can't understand the concept behind 2 rungs of logic, he shouldn't be looking into the PLC program in the first place - just my
opinion.

Cheers from:

Jeremy Pollard, CET
[email protected]
On The Web - http://www.tsuonline.com
PLCopen North America - [email protected] www.PLCopen.org
the Training Factory, Inc.
Programmable Controller Support Systems
The Software User Newsletter ONLINE
The Crazy Canuckian!
8 Vine Crescent, Barrie, Ontario L4N 2B3
705.739.7155 Fax 705.739.7157
 
J

Johan Bengtsson

The counter most surely doesn't cross from 32767 to -32767 but rather to -32768, and that is (not by coincidence in any way) an even number.

the counter would work quite well provided the PLC don't complain about a counter cycling that way.


However the cleanest solution as I see it would be::

button lastB pulse
--| |-----|/|------( )---

button lastB
--| |--------------( )---

pulse lamp lamp
--| |-----|/|---*--( )---
|
pulse lamp |
--|/|-----| |---*


pulse gets high for one scan each time the utton is pressed, then it is lamp = pulse xor lamp

This problem would however be much easier and cleaner solved in SFC:

step0
|
| button
- --| |---
|
| lamp
step1 ---( )--
|
| button
- --|/|---
|
| lamp
step2 ---( )--
|
| button
- --| |---
|
step3
|
| button
- --|/|---
|


Ok, ASCII graphic looking like it does but anyway...


/Johan Bengtsson

Do you need education in the area of automation?
----------------------------------------
P&L, Innovation in training
Box 252, S-281 23 H{ssleholm SWEDEN
Tel: +46 451 49 460, Fax: +46 451 89 833
E-mail: [email protected]
Internet: http://www.pol.se/
----------------------------------------
 
B
I often do "clever solutions" but I have learned the hard way to accurately describe them and not use them for actual sequence control. I often use such techniques for auxilliary functions (alarm control for instance), but I always leave plenty of spares and describe it totally. That way when someone needs to add an alarm they just latch up a spare alarm and the alarm horn logic, silence logic, and reset logic is already taken care of. Even this approach gets me in trouble some times, as field engineers often have a difficult time understanding the fairly simple code, but I figure it saves 4 or 5 rungs of code per alarm, and with a typical 100+ alarms in a typical system, thats a LOT of extra testing and coding to have to do, when I can do the whole thing in a few dozen rungs and virtually guarantee the whole thing will work without having to test every individual alarm seperately for reset, silence and horn functions.

One time I even included the alarm delay timers in the routine. It dramatically reduced my coding and testing time, but the field engineer about croaked, even though my control description specifically described the registers to enter the time delays in for each alarm. This was because he refused to read the control description or the rung comments and could not follow the logic.

I would be willing to bet that the PLC3 situation you described resulted from someone underestimating how much memory was required in the PLC to do the logic conventionally and someone decided not to spend the extra bux to do it right so the programmers did as they were told and used what they had. Keep in mind that a memory upgrade in that beast was kind of pricey (like $20k), so there was a lot of incentive to do things like that back then.

Bob Peterson
 
Top