one-shot with CompactLogix

Clubbe

Member
Join Date
Dec 2004
Location
Guelph, Ontario
Posts
4
I'm an Allen-Bradely nube... please bear with me.

I'm dealing with a CompactLogix 1769 for the first time. In an attempt to deal with the the 1769's asynchronous I/O behaviour, I've set up logic to copy the input to buffer variables at the start of a cycle, and copy buffer data to the outputs at the end of cycle.

Now my problem arises when I attempt to fire a one-shot to one of my outputs:

|   goHome                           |

|----] [---------| OSR            |--|

|                | SB: workBit[0] |  |

|                | OB: workBit[1] |  |

|                                    |

| workBit[1]               Home      |

|----] [--------------------( )------|

|                                    |



While in RUN mode, I toggle "goHome" with varying results. Often I will get no result whatsoever, but every so often "Home" will actually fire (usually after 3 or 4 ineffective toggles).

I'm stumped... any suggestions would be greatly appreciated.

Thanks
 
Greetings Clubbe,

first of all ... how do you KNOW whether the “home” bit is firing or not? ... basic idea, if you’re just going by the “green on the screen” then you need to know that you can easily be misled by that method ... secret handshake: the screen is updated through the communication cable – which can’t move data fast enough to be “real time” ...

suggestion: just for testing purposes, change the “home” bit to a “latch” instruction ... this will come on and STAY ON if it fires even for just one scan ... I’m betting my pocket change that your “home” has actually been firing each and every time that you tested it ... but you just missed the indication on the screen ...

next ... a suggestion ... you’ll probably find it a lot easier to work with the ONS type of “one-shot” ... if your system supports it ...

good luck ... and welcome to the forum ...
 
Sorry, should've been more specific:

When I said that "Home" fires, I meant to say I get actually output to my linear sliders (in this case, they return to their Home positions).

I tried the ONS instruction as well, but I get very similar behaviour.

Am I not understanding the nature of I/O buffering and scan times?
 
Clubbe,

it's not hard to understand, provided you keep in mind that all Logix5000 controllers (e.g. CompactLogix and ControlLogix) are asynchronuous controllers, while almost every other controller is synchronuous.

While most PLC's have a cycle consisting of reading inputs, processing the program and switching outputs, this is not the case with CompactLogix and the like. These controllers handle IO independently from program processing. In case of CompactLogix the IO cycle comes every 2ms. So, if your program cycle is much shorter than 2ms, it's quite possible the program processes multiple cycles between 2 consecutive IO scans, hence the output in your example doesn't react every time you throw the switch. But in the odd case the switch is thrown just before the IO is processed, you geta result on the output.

It startled me too the first time I got this effect. I tried to demonstrate the effect of a double coil syndrome. Connect a relay to the output in question and listen to it's clicking.....

The solution? Don't use a continuous task for your main program, but a periodic one with a period of a multiple of 2ms and a priority higher than the IO task (1-6). Find the 'About Tasks' section in the help topics to find out more.

Kind regards,
 
if your “home” signal is a real-world output, then your “one-shot” arrangement will only keep the output ON for one processor scan ... this is a VERY small slice of time ... it sounds like your field devices (sliders?) might not be seeing the signal for a long enough period to react ...

since we don’t have all of the details of your machinery, the following suggestions are just “general” in nature ...

maybe you could use a timer to keep sending the “home” output for a specified period of time ... (a few seconds?) ... at least long enough for the sliders to see it ...

maybe you could send the “home” output signal continuously UNTIL some sensor in the field confirms that the sliders have reached their home positions ... then turn the signal off ...
 
Slow it down.

If I'm understanding you, HOME is a discrete output bit.

If so, then what your ladder logic is doing is energizing that DO for upwards of one PLC scan. That's what, about 10 msec?

You need to remember that ControlLogix (and CompactLogix) don't do the normal Read Inputs-Scan Logic-Write Outputs sequencing. Output modules are updated asychronous to program scan. I'm still learning exactly how often those updates happen, but it's not impossible that you could go through a SET-logic-RESET cycle before the output was updated. Thus, your motion controller input was never activated.

Another possiblity is that, if the output is only on for 10 msec (average), that wasn't enough time to build up a voltage on the wire, to enable the motion control input to read the "activation" voltage.

In short, use something that will produce a longer lasting signal than a one-shot. A Timer TT bit, perhaps.
 
Thanks everyone for your help up to this point... I'm the only fella in my shop who deals with PLC's, so the going can be tough.

At this point I've changed my program to a periodic task with a period of 10ms and a priority of 5. The OSR instruction is still not giving me the output I want, so I believe that a lack of signal is very much the case.

A little clarification: the linear sliders I am using are a product newly introduced by Oriental Motors. Each slider has it's own controller, which I am interfacing to the 1769 a-la-hardwire. Initially I tested the "Home" signal using a simple sustained output from the PLC... I discovered that the slider controllers reacted by repeatedly attempting to home the sliders while a signal was provided. Thus I concluded that a one-shot signal was necessary.

Any thought?... Thanks again everyone!
 
Try "pulsing" the output for a period of time. Here is how it would look in a SLC. You can try different presets to get the right pulse length. I think you could get rid of the one shot and the done bit also.

pulseout.jpg
 
Last edited:
Following is the technique used in our ~3000 rungs PLC-3's, in which I/O scan and program scan are asynchronous.

Several of these rungs are spread evenly through the main ladder -

LATCH
----------------------(JSR)



The subroutine called consists of:

LATCH ORF (file-file OR)
---|LBL|-------------+ A: #I0:0 the REAL inputs file
+ B: #B3:0 scratch file
+ B: #B3:0
+ COUNTER: Cxxx
+ LEN: 128
+ MODE: ALL

Cxxx/EN
----------------------(U)--


The final two instructions of the main program are:


MVF (file-file move) Cyyy/EN
----------------------+ A: #B3:0 +-------(U)----
+ R: #I1:0 +
+ COUNTER: yyy +
+ LEN: 128 +
+ MODE: ALL +

MVF Czzz/EN
----------------------+ A: #I0:0 +-------(U)---
+ R: #B3:0
+ COUNTER: zzz
+ LEN: 128
+ MODE: ALL


The subroutine 'latches' the inputs which are on by OR'ing them into the scratch file.

The final two main rungs copy the collected inputs to file I1 and refresh the scratch file to the true current state of the inputs. File I1 is accessed to solve rung logic over the NEXT scan.

Time critical inputs are addressed to I0.

Maybe this will be of some help to you.
 
If the axis has a 'moving' output, this is the proper way.

HomeExample.jpg

Maybe with a timeout if it doesn't move after a second or so.
pp
 
The easiest way to accomplish what you are doing on Async-scan PLC's, is just to latch the go-home bit with a one shot, and then unlatch it when you get a status bit back that the system has homed.

If you are using motion control modules, or even an external motion system, such a status should be available. You can also use a status bit of 'Home Command Received' if it is available.

This is how the counter modules work in Controllogix for example; You set the output for 'Counter Reset', and leave it set until the module reports bace 'Reset done'.

A nice thing about this approach, is it also provides for some error checking should you wish; start a timer with XIC GoHome and XIO AtHome. If the timer times out, the system isn't homing properly.
 
All sorted out! :D

Thanks to both Jean Pierre and Ken in particular. I implemented Ken's suggestion and away it went --- problem solved.

Thanks to everyone for your help.

Clubbe
 
An observation...

In the example Ken used, the XIO T4:0.DN in the timer rung is not necessary because the timer is held in by it's .tt bit. The .tt bit will go off when the .dn bit comes on...

If the timer were using the .en bit to seal in, then the XIO T4:0.DN would be necessary.

pulseout.gif
 

Similar Topics

Hello all. This is a very lonnnnnnng shot but worth a try. I have an OMS Group Impact100 metering machine. At this customer it blows foam into 3d...
Replies
0
Views
167
Howdy Everyone, So I have been retrofitting a cell to run different fixtures and updating it with new drives and a few other things. It runs...
Replies
15
Views
1,457
Hi all, I am working on a ladder program in AS and I was to trigger a reading on my IO link sensor every .5 s, and use that value to run a...
Replies
1
Views
517
Hello Everybody, Someone must be familiar with Horner Cscape, I wrote a program on a overhead door with a 3 button station,I'm working on a...
Replies
2
Views
1,387
personally I don't care about golf - but this is one impressive shot ... if it weren't on tape, I wouldn't have believed it ... the first video in...
Replies
1
Views
1,490
Back
Top Bottom