Hope I don't forget anybody...
Sorry guys... Late start for me today (but HEY, it's a S-U-N-D-A-Y!). Last week's installation sucked the life out of me, so I had to catch up on sleep. Anyway, I'm back...
Bob O said:
You may or may not have followed my thread about rejecting parts down line on a flat belt conveyor.
Yes, I did. That was very similar to my application
chavak said:
The option I made was the "vision system" outputs another pulse no matter it is either pass or fail. And I used its falling edge to do the shift of the BSL.
I could do that, but IMO, you wind up in the same boat. If the camera fails to give you the "inspection completed" signal, you don't advance the shift register...
Rube said:
Eric-- I use FIFOs all the time but I can't "see" what's causing you grief until Monday when I could load a processor and check the program.
Once you do, it will be easy to reproduse. Stick a few "PASSES" into the stack (I:0.0/1), then unload them with the reject input (I:0.0/3). You'll see that the reject output (O:0.0/0) does not fire (as it should), yet once the stack is empty, the reject output CONTINUES to NOT fire with additional reject input signals. This is the heart of my dilemma. Otherwiase, everything works perfect.
Rube said:
One thing I noticed is you load the stack with "1" and "0". You're only concerned with rejected parts, which I would label "1". Then when B3/0 goes FALSE, MOV a "0" into the stack. This has the effect of resetting (clearing) stack until the next rejected part. We do this on two lines so I know it works. I can send logic in the morning if you don't get it tonight.
Wouldn't I wind up with 'extra' data in the stack? You're probably on to something, so please elaborate!
Rube said:
As for the triggering, I use cycle/dwell timers to trigger my FFL/FFUs. I don't know why they are triggering improperly unless the sensors are blocked for a long time.
I tried to stay away from using a timer as a clock because I was comcerned about the starting and stopping of the conveyor. I have no way of knowing if the conveyor is running, or how fast it is travelling at any given time. My fault really, as this project is basically a favo(u)r to one of my vendors. He just asked me to throw this together for one of his customers. I didn't ask enough questions up front, so there are many details I'm not sure about. That is the main reason I'm trying to keep this as simple as possible. He has exactly ONE value to fiddle with. Setting the reject duration timer's preset. I added the debounce timers (which will all be set to zero at shipment) in case he needs the ability to ignore 'noise' from the photoeyes. I honestly feel my 'problem' will not BE a problem, but I just didn't personally like it, so that's why I'm here.
JohnW said:
Have you had a look at this thread?
Yes, and I followed it while the discussion was going on. I will dig into it more later. Thanks.
dandrade said:
They must be interlook. To process not to scan simultany in the two instrutions same SCAN.... Always, interlook in SCAN pair one instrution(FIFO IN) , and SCAN not pair other instrution (FIFO DELETE)
I was going to interlock them, but since load and unload can occur at any time (even concurrently on the same scan), I felt an interlock would PREVENT proper operation. Am I missing something?...
Doug_P said:
1. Since, from your description the camera provides a signal for either result, why couldn't you load FIFO/0 with a '1' if the result is "FAIL" and load FIFO/1 with a "1" if "PASSED"?
2. Load FIFO/2 with a '1' whenever the inspection sensor is triggered?
This way when the unload occurs FIFO/2 tells you a real object is present and if neither of FIFO/0,1 is on then the camera did not read.
In my first shot at this program, I used the inspection position to advance the FIFO, but the camera result occurs a short time AFTER the trigger, so I was forced to stick the result in the 'current' stack position, which required adding a subroutine to look at the current stack position and place the result in there. Since the ML1000 doesn't have indirect addressing, it started getting overly complex IMO. I didn't continue pursuing this route, though that's probably the direction I should have taken.
akreel said:
Like Doug_P, I wondered why you're loading "Source = 2" on rung 5
Good eyes! You caught my mistake!
That was a leftover from my first program. When I previously fired the FFL off the inspection position sensor, I was loading a "1" for failed, "2" for passed. When it reached the reject, a value less than "2" would be rejected. This included "0". I was planning "0" to mean 'no inspection', which would reject the part.
I have corrected this 'faux pa', but it has no effect on the function on the program. Any value greater than zero is considered 'passed'.
akreel said:
You said you are having a problem with the FIFO table retaining the last value, so here is what I thought you could try. I hope this can still be done with FFL instructions.
1. Instead of loading a fixed number into the stack on rung 5, load a serial number. (You may want to use serial numbers for your parts at a later date, anyway). Use a CTU instruction after rung 4 and have it reset itself to 1 after some maximum limit (to avoid an overflow). If the part is good, load the serial number. If it's bad, continue to load a zero.
2. Before rung 10, compare the value taken out of the stack to the previous value unloaded. If the values are the SAME or zero, fail the part. This way, if the last good part is stuck in the que the machine will fail parts (as you suggested).
This idea I'm REALLY liking! I can simply alternate between two values (like "1" and "2") to use as the 'pass' value. Continous good parts through the systems will produce 1, 2, 1, 2, 1, 2, 1, 2. Unloading two identical numbers in a row means the camera stopped giving results. Elegant solution, AK!
Now to get back to my programming!
Derek McFarland said:
You could build your own FIFO if you used 1 for failed instead of zero. When a part is inspected load it into the highest non-zero address in the stack. When a part is at reject unload the highest address in the stack and shift the rest up.
I appreciate your suggestion, but I think AK has provided a solution that I'm gonna run with. Let's see if I can make it work.
Thanks again to all!... :site:
beerchug
-Eric
