fifo for 2 machines

[KalleOlsen]

What if you use 12 registers that stores the time stamp (or some other 'time' counting) at the moment the start button is pressed, only the first attempt is stored. A 'cancel' removes (0) the time stamp. So does a starting process. You'll need a routine that finds the register number for the first t-stamp.
No code suggestions - I'm totally blank on AB.

Kalle

Here's a code sample how it could look when done with time stamping, no FIFO, in an S7 (if S7 is allowed in an AB thread

).

 

[Lancie1]

Kalle, That S7 timestamp routine looks like it would work great. I don't know if James's version of RSLogix has a built-in function that would find the oldest timestamp. If not, a user routine could be written.

After testing on the LogixPro Simulator, my previous Revision 2 RSLogix program needs a slight change. The XIC instruction for R6:0/EU should be removed in Rungs 025 through 036. At least in LogixPro, these instructions prevent the FFU Unload instruction from running correctly.

Also, Rungs 025 through 036 will need an additional instruction to unseal the Run Enable relays, once each machine finishes with a cycle.

I have Revision 3 available if anyone needs it.

 

[James Mcquade]

Here is my program which will be close to the same when i download it. Our example plc does not have all the i/o, so i am simulating a lot of the i/o the best i can.
the timers have been shortened a lot.

As already stated earlier, any of the 12 stations can be operated randomly.


#1 load part and close door.
#2 press the start pushbutton.
#3 fill the chamber with water.
#4 process the part.
#5 dump the water.
#6 signal operator that the process is over - indicator light.
#7 remove the part.
#8 time delay to confirm part removed and reset the cycle.
#9 next station.

Lancie1,
the program looks a lot like what you have.
My problem is the logic for the fifo unload. I can't
seem to get it right. it works for several cycles and quits.
i must toggle the fifo unload to get it going again.

Any hints or corrections will be much appreciated.

thanks,
James

 

[Lancie1]

James,

I see at least on big problem. A very big mistake is one of the instructions that Unload your FFU. You apparantly are trying to check for when the first address in the FIFO stack (N7:1) is not equal 0. But remember, that value only changes AFTER the FIFO stack is Unloaded, the very thing you are trying to use it to do (a connundrum). You should not use the value AFTER an operation to TRIGGER the operation!

If N7:1 happens to be set to 0 (as it should be each PLC start-up and after all machines have been started), then your unload operation is dead in the water.

You can use the FIFO control word Position to check to see if there is anything in the FIFO stack to be unloaced. The address for your FIFO is R6:0.POS. Try checking R6:0.POS for NEQ 0, instead of N7:1.

Another problem is that for the FFU to advance to the next position, the FFU unload rung must go from true to false to true again. If your trigger is always true (N7:1 always greater than 0 and B12:4 always = 0) , then it will only do one unload and quit. I am not sure that your B12:4 goes "not equal 0" each time a machine finishes the water fill. No, after studying your logic, I am sure that it doesn't. B12:4 gets set only when another machine requests a start. What if all machines have requested starts, got entered into the FIFO stack, and are waiting their turn to run? Now there are no more requests (B12:4 goes to 0 AND STAYS THERE). Then your FFU will not do any more unload operations, even if all machines have not yet had their turn to run.

I think you are mixing up the two functions. FIFO Load should occur ANYTIME there is a Start Request. FIFO Unload should happen: anytime the FIFO stack is not empty AND "the last machine started has finished with the water fill". Note that the second part or the logic should NOT be tied to the original Start Request in any way, yet you are using the B12:4 Start Request word to trigger your unload. I think that is a mistake that will be hard to overcome.

That is why in my program I used the START_POSSIBLE relay that gets set (unlatched) when: no machine is running, OR the next machine finishes filling.

 

[James Mcquade]

Lancie1,

THANKS !!!
Thanks a lot !!

As i said earlier, this is my first attempt at a FIFO and i need all the help i can get.

I will keep you posted.

Thanks to the managers of this website and to all those who offer assistance.

regards,
james

 

[Lancie1]

James,

I understand. It takes some experience to become familar with the concept of a First In, First Out stack of words. I think of a FIFO as a function that separates two things that were previously bound together. In you case, what you want the FIFO to do is keep up with the machine start order, yet allow the actual machine starts to occur at some time in the future (that is not connected to when the Start Request first occurred).

You also need to create a delay between start requests and actual machine starts. FIFOs do not have a built-in time function, so this delay must be created with other timer logic external to the FIFO. To do that, your Start Requests have to be completely separated from the logic that causes the machines to actually run.

Basically your program needs 4 main parts: (1) the logic that enters the Start Requests into the FIFO, (2) the FIFO Load, (3) the logic that checks to see if the next machine can be started (totally separated from and unconnected with the original Start Requests), and (4) the FIFO Unload instruction.

I simulated Revision 3 with LogixPro. I had to limit the stations to 6 due to LogixPro limits, but it did work. I could enter the Start Requests in any order at any time, and the FFU would start the machine in that order, but only when no other machine was running OR the timer for the last machine started was done.

 

[James Mcquade]

Lancie1,

Thanks for the reply & documents.
I have been on the line all day and must be there tomorrow
as well. I will try to look at the items tonight.

thanks,
james

 

[Lancie1]

James,

I think you have the FIFO Load instructions working. The key is getting your FFU trigger logic to work. It needs to have several characteristics:
FFU Unload Trigger Logic
1. The FFU Unload only triggers the FFU one time for each actual machine start time. The trigger logic must go on then off again.

2. The trigger needs to check for 4 states. Two binary bits in parallel can be used to check 4 possibilities. Each machine RUN ENABLE is either ON (condition 1) or OFF (condition 2). If it is off, then (from that machine viewpoint), another machine can start. If RUN ENABLE is on, then you have to check to see if the Water Fill timer for that machine is Done (condition 3), or not (condition 4). If it is done, then the Start Possible relay can be latched. If it is not done, then the Start Possible relay cannot be latched.

3. Step 2 must be performed for all 12 machines at the same time. That is done by stringing 12 sets of parallel branches into a series string, which Latches the "Start Possible" relay, or not.

 

[Paul T]

Hi guys. Sorry, been a busy week.

James, take a look at this and see if it makes any sense. You're almost there.

You can load the FIFO whenever, no need to try and have just one rung. Unload, well that is only one rung in this case, and it goes after you've SET/RESET your RUN COMMAND bit.

Like I said, take a look and see if this helps. I gotta go, have to do some stuff on the floor during their 10:45 - 11:30 lunch break! Sorry I didn't PDF it, you'll have to look with RSLogix.

Paul T

 

[Lancie1]

Paul T,

There is a basic flaw in your logic. Your program still is trying to use the Run Requests (B12:4 word) to control the FFU unload. All 12 Run Requests COULD occur in the first 4.5 minutes after the first machine starts (your fill timers are only set for 5 seconds, so this is not a true test of the real situation). After that, your FFU will not be triggered again, even if only one station is running.

As the part is being processed (approx 20 minutes), the next part is loaded into another station (approx 4 minutes after the part that is in process)and the operator hits the start button.

The sequence of events is:
1. load part and close door.
2. press start cycle start pb.
3. fill area with water (4 1/2 or until sensor says stop).
4. process part.
5. drain water - 4 1/2 minutes.

I ASSUME that Step 3 takes 4.5 minutes. If so, then setting the Water Fill timers to 5 seconds will falsely allow your FFU trigger to work (in a half-@$$ed way), but it will not work when you set the timers to the real 4.5 minutes.

Until the Run Command is completely separated from (disassociated with) the Run Requests, you will have problems getting the FFU to unload correctly.

 

[Paul T]

Paul T,

There is a basic flaw in your logic. Your program still is trying to use the Run Requests (B12:4 word) to control the FFU unload. All 12 Run Requests COULD occur in the first 4.5 minutes after the first machine starts (your fill timers are only set for 5 seconds, so this is not a true test of the real situation). After that, your FFU will not be triggered again, even if only one station is running.

I ASSUME that Step 3 takes 4.5 minutes. If so, then setting the Water Fill timers to 5 seconds will falsely allow your FFU trigger to work, but it will not work when you set the timers to the real 4.5 minutes.

Until the Run Command is completely separated from (disassociated with) the Run Requests, you will have problems getting the FFU to unload correctly.

Huh. I thought it was.

I'm using the RUN COMMAND, which is set when the RUN REQUEST goes down, to unload the FIFO.

The RUN REQUEST is really only useful as a one-shot for the FIFO load command. Without it, the FIFO load would trigger every scan as long as the START PB was made. Really, the only thing I use it for is to keep the FIFO load from triggering more than once.

Now, THAT is a problem later on, after the RUN REQUEST goes down, if pressing the START PB will ALWAYS OTE the RUN REQUEST. If the program is state-based, then that isn't an issue. But, the program probably is not state based and in that case, we need yet another IK in the FIFO load rung to make sure it only happens once, and when it should.

And, sure, you could trigger every RUN REQUEST on a single scan. That's ok, it's why we're using the FIFO.

As far as the unload... I think it's OK. If RUN COMMAND is on for the entire FILL cycle, then I think it works.

I have to admit, I need James to clarify what exactly those timers are trying to do. Are they some kind of test case, or what?

If they are set to cover the "real" time that the station is filling, and running, then it should work. Although, I don't like timers for process control - I want something tied to the hardware that tells me what state the hardware is in.

Better would be a flag, set and then cleared in each station, as the station cycled. Shucks, for this you could use one register - N7:something. Load a "1" when the station RUN COMMAND was set; that could be done in the logic stub we're looking at. Then each station subroutine clears that flag when it is done filling, which I would think would be pretty easy to tie to a station fill valve or float switch or whatever it is that tells the station it's full and ready to process!

And it could all still use some exception handling, and it needs to be cleared on powerup, or command, and all that sort of stuff.

But maybe it's getting there!

 

[Lancie1]

Although, I don't like timers for process control - I want something tied to the hardware that tells me what state the hardware is in.

I agree. If there is a sensor for the Water Fill, then I would use that instead of the Timer Done bits.

Earlier, I remember James saying he was running the program on a simulator. I thought that he probably set the timers to 5 seconds so he would not have to wait the entire cycle. However, that could lead to an assumption that (because he probably cannot press the start buttons of all 12 machines within 5 seconds) this FFU unload trigger method will work. Think about it: You are trying to use something that happened in the PAST to trigger an event in the FUTURE. If you can do that, I want to buy shares in your time machine!

EDIT: I suppose I am going to have to take the James version and modify it and test it to prove my point. I can't think of any other way to get this point across.

 

[Paul T]

I agree. If there is a sensor for the Water Fill, then I would use that instead of the Timer Done bits.

Earlier, I remember James saying he was running the program on a simulator. I thought that he probably set the timers to 5 seconds so he would not have to wait the entire cycle. However, that could lead to an assumption that (because he probably cannot press the start buttons of all 12 machines within 5 seconds) this FFU unload trigger method will work. Think about it: You are trying to use something that happened in the PAST to trigger an event in the FUTURE. If you can do that, I want to buy shares in your time machine!

EDIT: I suppose I am going to have to take the James version and modify it and test it to prove my point. I can't think of any other way to get this point across.

Sorry, I've been editing my last while you were typing this! Go back and read it again, then tell me what I'm missing.

Paul T

 

[Paul T]

OK, Lancie, after re-reading yours I have another version.

- Assume that RUN COMMAND is set the entire cycle
- Create a new flag, FILL ACTIVE, that is only set during fill

Still pretty much what I had before, just with a flag that will clear and allow the FIFO unload to occur when the fill is done. I was not clear on what RUN COMMAND was doing originally... well, I'm still not LOL but let's assume that it is on the whole station cycle. Then, it's useful for addressing one of my concerns but not for the FIFO unload, we needed a new flag for that.

Paul T

 

[Lancie1]

As far as the unload... I think it's OK. If RUN COMMAND is on for the entire FILL cycle, then I think it works.

This is the part that you are not getting. The FIFO as used here only stores 1 set of information: the order of Run Requests. It does not store any times, or anything other than the pointer position. It is not magical enough to know WHEN the next machine should start.

The Run Requests happened in the past, at least 5 seconds ago (but I think more likely 4.5 minutes ago. It is amazing that we still don't know for sure if the water fill takes 4.5 seconds, 5 seconds, or 4.5 minutes!). These Run Requests are not being stored, so there is no good way to use them to trigger a machine start (because the PRESENT machine start should NOT be dependent on WHEN the previous Run Requests ocurred in the PAST.