Accuracy of PLC triggering

[skjomcs 0]

Hi, I have a question regarding a micrologix 1100 PLC if anyone could provide feedback i would be grateful. i am using an input to a micrologix plc to start a timer(this input is repeatable),i start a timer when i see this input, after this timer gets done i begin another timer to trigger a camera to find a part. the second timer stays on for 30ms to give the camera a pulse long enough to see. The problems is the part i am trying to detect is within a 18ms window. If the timing of the trigger drifts by 5ms i will miss the part. this is what is happenning i am failing to detect the part consitently as the trigger appears to drift by 5ms. Could the plc scan times be causing this? Am i doing something wrong? Can you obain a repeatable trigger that dosent shift by 5ms using this PLC? I am very new to this so please Thanks

[Bob O 8]

I have only worked with the DVT systems and I used a sensor to trigger the camera to take a picture once it sensed the part.

[BITS N BYTES 66]

I am not familiar with the ML1100 but if it has the STI [selectable Timed Interrupt] function similar to the SLC500 you can use this to get a very accurate and repeatable time to trigger the camera. Because the STI is asynchronous with program scan you will get no drift.

[skjomcs 0]

Thank you, Can i use this to generate two triggers when i recieve one input, one after 380ms and the other after 500ms?

[gmferg 1]

An STI would not work for your situation. You want to use an input to create a delayed output. The very short times you are trying to achieve are all about scan time. You need to see what your scan time is at. One thing that would help reduce the drift is if you were to use only one timer with a GEQ or LIM instruction to trigger the output. Instead of looking for the second timer to timeout the 30mSec for camera trigger, allow first timer to go an extra 30mSec and check that accumulated time is beyond trigger point. Each time you stack timers, you introduce error since the timer is not triggered done until its accumulation time is GEQ preset and timer rung is scanned. Therefore, timer accumulation will always be greater than preset when done. There is also error introduced by scan time when starting a timer. The timer isn't actually started until the input is true and the rung containing the timer is scanned. The Micrologix 1100 has an EII function file. This is an event interrupt file. You can use an input to cause scan to be interrupted and "jumped" to a specific routine to execute that code. You could use this to reset a free running timer. This would at least eliminate the error caused by starting the timer at the exact time the input is triggered. Be sure to condition your RES with the actual input point. I believe the EII monitors a word of input bits not just the one you're looking for. If all else fails with PLC, look at installing a programmable timer relay to perform only this job of triggering camera.

[BobLfoot 302]

The STI is a routine which operates when the interrupt occurs. To get what you desire you'll need to place a timer in your sti and use IOM immediate output mask.

[gmferg 1]

The STI interrupts scan at a fixed time interval, not input trigger. An STI would actually be worse in this situation than not using it. Placing the timer within the STI would cause it to be triggered less often than if it were in the regular scan as the STI has to be set to interrupt at a slower rate than scan time. EII function file is absolutely the way to go for this project. It uses a physical input to trigger an interrupt instead of some arbitrary time interval. I would place only one rung within the EII routine: XIC input RES timer. The timer, placed in a different routine which is always scanned, should be free running with no inputs and a very high preset. Use the LIM and IOM instructions on a rung right after the timer rung to trigger the camera output. You may want to experiment with placing the timer in the EII routine as this will trigger it to start sooner than in the regular scan but it may not update accumulation soon enough. You may want to experiment with having timer in both locations and see what happens. I do like the idea of using IOM to trigger camera output right away instead of waiting until end of scan. I believe outputs in Micro 1100 are not updated until end of scan unless you use IOM instruction. If the OP could post the program here and post the scan time, that would help a lot in getting the correct answer. The scan time can be read while online under the Processor Status area. Edited 2 Nov 2008 by gmferg

[BobLfoot 302]

Good point with a 1ms STI the code should probably look like the following: IIM of sensor If Sensor on then OTL count_now flag {B3/0} IF Count_Now Flag{B3/0} then add 1 to a counter If counter is between 380 and 410 the output trigger 1 If counter is between 500 and 530 the output trigger 2 If counter is greater than 530 the OTU count_now flag {B3/0} If not Count_Now Flag reset counter IOM the Trigger

[BITS N BYTES 66]

Forget about a "TIMER" within the STI. Use counters/accumulators within the STI and use the STI timebase. For example if the ST is set for 10mSec then when a counter within the STI = 5 then EXACTLY 50mSec have expired.

[gmferg 1]

Camera needs to be triggered a set time after an input is seen. This cannot be done using an STI. Use the EII.

[skjomcs 0]

# Okay i am getting slightly confused, thanks for all the replies though, this is a great way to learn, its my first real plc program. So am i correct in saying i dont use the sti and use the EII?

[gmferg 1]

That is my opinion, obviously there are others. I would suggest you try both as it is a good learning experience and you will prove to yourself which method you prefer.

[TimWilborne 108]

Actually I believe a combination of the two will provide the best performance. Trigger an EII based off of your external sensor. The only code this will have in it is to set the TIE bit on your STI which is already set to execute every Xms. Xms later the STI routine will execute. The last rung of your STI routine should reset the TIE bit. It is then ready for the next external trip We needs some clarification on exactly what all you need to execute during this window. Are you just turning on a single output? There could still be some scan time issues doing this depending on how complex your code is during this window of execution