Programming logic help!

[LoganS]

I'm ashamed to admit that I cannot figure this out. Probably over thinking it, or maybe it is actually difficult. 

 

What I need to do is time an output to go off after 500ms of receiving a trigger input IF the controller ALSO gets an OK signal after the trigger input.  I need to be able to receive these trigger inputs and OK signals in 50ms cycles. So basically I will get 10 triggers before my first output if the system is running at full capacity.   Since program time is variable the output for OK is dependent on that; I also have a READY signal available that is high when trigger is low and system is not processing.  The OK would output immediately after rising edge of ready.  A NG judgement will be assumed for a trigger with no OK input.  See timing chart attached, trig one is OK and trig 2 is NG.

Essentially I need to recreate the trigger pulse train for the instances with an associated OK at a 500 ms delay

I was considering throwing the binary bits into a data table then pulling them back out after 500ms removing the oldest entry each time but even that I cant fully think thru/ wonder if there is a simpler way.

Application details- This is a vision system to a samba 43 and the vision system sends its judgement output when the program is done executing.  Some programs are 30ms some are 400ms depending on camera resolution, program complexity etc.  The parts are traveling down a conveyor belt at a set speed so the output timing determines how far the part has traveled since the trigger, hence why i want to hold that constant at 500 ms.  We are blowing the parts off the line with air if they are OK. 

Surely someone has done something similar to this..

Any advice appreciated, thanks

[Ausman]

Hi Logan,

I think you might find the solution I have in the link below a useful thing to play with.  Perhaps read the entire topic to get background.  I feel sure that using the interrupt will be an easy method to solve your issue.  Also take note of the seemingly odd way the interrupt is implemented.

cheers,    Aus

http://forum.unitronics.com/topic/4599-totalizer-to-gpm/?do=findComment&comment=17077

 

[Ausman]

PS, a note to all. 

When referring to "vision systems" I initially thought you were talking another "Vision" PLC to the Samba.  It can get confusing on the forum with more and more optical vision systems becoming available!  🧐

cheers, Aus

[LoganS]

15 hours ago, Ausman said:

Hi Logan,

I think you might find the solution I have in the link below a useful thing to play with.  Perhaps read the entire topic to get background.  I feel sure that using the interrupt will be an easy method to solve your issue.  Also take note of the seemingly odd way the interrupt is implemented.

cheers,    Aus

http://forum.unitronics.com/topic/4599-totalizer-to-gpm/?do=findComment&comment=17077

 

Thanks Ausman,  I read the topic and though it was insightful to the function of the interrupt Im not really seeing how this would be useful in my application.  Perhaps I did a poor job explaining or perhaps my brain just has not made the connection yet.  

 

Not sure if this helps, but put simply I am basically trying to have this judgement condition operate with a 500ms lag. Sort of like a lagging conversation over the phone: all information retained but it comes thru at a delay.  Does this make any sense?

[LoganS]

Would it be possible to log time stamp at every trigger, add 500 ms,  then delete from table when output is sent?

[Ausman]

Reading everything you have said, it looks like there will be a maximum of 11 items in the entire "delay" sequence.

I suggested the interrupt because 1.25ms can give fairly tight timing control with little effort.   For me I'd be avoiding the use of a table.

1   Use the method of moving bits along in a vector, triggered to do a single move every 50ms.  You can find various ways to do this in Help under Store functions.  You would then use the relevant bit status as your primary trigger and relate it to the later one.  As the smallest easily done system timer you could use for this is 100ms, I would again be looking at using the interrupt as the timer basis. 

2  If it is indeed only 10 or 11 items b/n the start and the blowoff, you could use a FIFO system of TE timers set at 500ms.  If timer is on and second trigger is on, action happens.  Timer could be set to start by either an actual physical read of the item initially, or the assumed arrival on the belt.

This is a classic case of there really are multitude ways of doing this....each programmer has their own preference.  Sometimes something "clunky" is actually easiest to work with, as you can see what is going on very easily.  The fantastically miniscule program that does it all exquisitely with very few rungs may not be that easy to use for troubleshooting!

cheers, Aus

[kratmel]

someting about present in

 

 

 

[LoganS]

It sounds like combining the two solutions above is what is needed... The example provided by kratmel the guy used an encoder... I can logically create this by using the interrupt proposed by Ausman and tie this DW from the interrupt counter, correlate it to my commanded frequency on the frequency drive and have pretty tight control over position.  To keep things simple i will hold frequency constant until the code is working and just use the interupt as a timer but you can see where I am going with this..  Im going to try adn get some logic down and I will post as I am sure there will be issues. 

 

My favorite quote in the thread from Kratmel when Joe Tauser said "This one's not as easy as it sounds." lol

 

Thanks

[Joe Tauser]

No, it's not so easy  😀 

I'm glad you went back and looked at the previous posts.  This thread spooled off dealing with your premise before I got a chance to respond, but question I really had was whether the distance between the inspection point and the blow-off is a fixed number of units, like something you'd see on a canning or bottling line.

If it is, then you need to stop worrying about transit time and tie your action to something that gets triggered on a regular basis.  Then it becomes a matter of buffering the inspection output in a chain of registers and counting pulses while you shift the buffer.  Is the inspection trigger a regular thing tied to the line or are your parts sporadically placed?

Joe T.

[LoganS]

37 minutes ago, Joe Tauser said:

No, it's not so easy  😀 

I'm glad you went back and looked at the previous posts.  This thread spooled off dealing with your premise before I got a chance to respond, but question I really had was whether the distance between the inspection point and the blow-off is a fixed number of units, like something you'd see on a canning or bottling line.

If it is, then you need to stop worrying about transit time and tie your action to something that gets triggered on a regular basis.  Then it becomes a matter of buffering the inspection output in a chain of registers and counting pulses while you shift the buffer.  Is the inspection trigger a regular thing tied to the line or are your parts sporadically placed?

Joe T.

It is not consistent.  The parts are metered out from a vibratory feed bowl. 

 

The time between trigger and output is also variable, hence why i am trying to do this.

[LoganS]

here is my code.  It is working well.  Ended up going the data table route as I couldn't wrap my head around any other way... I didnt see how a shift register would have worked as it is sort of a 3d array of data not just shifting bits.  Anyways take a look and offer any suggestions if you wish.  

 

Basic flow is this: 

• Camera trigger time stamps 2.5ms counter value to data table in the row designated by a pointer integer (power up zero)
• desired time delay is added to this value and sent to the set point column in same row. (200 gives me 500ms)
• judgment condition Boolean is sent to same row in 3rd column after the Ready signal come back to its high state if there if OK input is high. 
• table lookup utility is constantly sniffing row 0 for current time = setpoint, and when it does, the physical output tied to air valve is opened if there is a 1 in the judgement column.
• after the window looking for judgement=1 executes , row zero is deleted and everything shifts up 
• repeat

 

 

I just need to add a few interlocks to it for faults and setup modes and the likes, as well as add a duplicate with another set of operands and data table for the second camera.   but other than that the code is doing  what I need it to.  I estimate my time synchronization is around +/- 7ms.  (2.5ms counter as timer and a 2-3 ms scan time) Will be doing more testing for bugs as well.  Zero bad product being accepted is tolerated so It needs to fail in a safe manner if its going to.  

 

-Logan

vision system #2_3_17_20_redacted.vlp