fifo for 2 machines

...just with a flag that will clear and allow the FIFO unload to occur when the fill is done.
You are getting there. There is one other condition: When the first machine is started, no machines are running, therefore the FFU should occur immediately, because there is no waiting for a previous Water Fill. That is the challenge, and you are probably going to end up with some logic that looks amazingly like my Start Possible relay.
 
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.

Still not seeing it. Sure, the FIFO only stores the run order; the timers, at present, set the flags that control WHEN the FIFO is unloaded.

RUN REQUEST is set when the START PB is pressed. It latches. Nothing happens; the FIFO has not been unloaded yet.

All FILL ACTIVE flags are clear and now the FIFO is not empty. We unload the FIFO. On the next scan, one of the twelve stations starts (thank god this isn't the 36 station one!) and sets one of the 12 FILL ACTIVE flags.

RUN REQUEST goes down on the same rung that FILL ACTIVE is set. Well, we never cared about RUN REQUEST anyway except as a lockout on the FIFO load.

FILL ACTIVE goes down in 4.5 min, or whatever the timer is set to. Until FILL ACTIVE goes down, the FIFO cannot be unloaded. As soon as FILL ACTIVE clears, the FIFO is unloaded if it's not already empty. The next station out of the FIFO sets FILL ACTIVE and RUN COMMAND. Then that FILL ACTIVE goes down in 4.5 min.

?? What else is there to do?

Paul T
 
Last edited:
You are getting there. There is one other condition: When the first machine is started, no machines are running, therefore the FFU should occur immediately, because there is no waiting for a previous Water Fill. That is the challenge, and you are probably going to end up with some logic that looks amazingly like my Start Possible relay.


Yeah, this addresses my comments about clearing the FIFO, clearing the various flags. That logic has to be added someplace too. And, we both agree I think that it would be better to have some flags tied to the station states... preferably though sensors or actuators... that were telling us what each station was really doing through the cycle.

Also, the FIFO unload register should be cleared every time a station is started; if it's never cleared, then the logic will hang up if the last station out of the FIFO is the next station that has it's START PB pressed.
 
Last edited:
Also, the FIFO unload register should be cleared every time a station is started; if it's never cleared, then the logic will hang up if the last station out of the FIFO is the next station that has it's START PB pressed.
This is where an input feedback from each machine is needed, to unlatch the Station Run Commands B12/65 to B12/76. I am going to ASSUME that there are "Station Finished" inputs available to reset the Station Run bits. Otherwise this program is flying blind.
 
For those of you (us) that are reluctant to FIFOs; here is a very simple ladder code (S7 again, sorry!) to find the least number (read:time stamp) >0. Two values are checked, the result is passed to the next block call check. 11 calls are neccessary in this particular case. The index of the lesser valid stations time stamp is passed between the block calls. After the final call, the result is either 0 (= no pending requests) or the station index of the first start request (and the timestamp also, as a bonus
icon7.gif
).


FC136 is the 'floor' value finder.
FC141 shows the use of FC136.
The purpose of this post is shown in post#31.

Have mercy with my explanation attempt. It may be non-pedagogically and bad English, but I think you prefer it before Norwegian.
icon12.gif


Kalle
 
James,

I revised your last FIFO SAMPLE program. I only changed the necessary things to make the FFU work correctly (unload based on machine state instead of Start Requests).

There are a lot of relays, bits, and timers that can now be deleted, but I left those in so you would recognize it as the same program!

EDIT: The File 3 Station 1 rungs got cut out of the PDF file, so I have resaved it.
Still not seeing it. Sure, the FIFO only stores the run order; the timers, at present, set the flags that control WHEN the FIFO is unloaded.
That was the problem in a nutshell: the Water Fill Timers T15:1 to T15:12 DID NOT control when the FIFO was unloaded. Instead they only controlled when the machine O:5 Run outputs were energized.
 
Last edited:
7. system recognizes part is removed and resets station for
next part.
James, Inputs that signal the above Step 7 were missing from your original program. I made some up (I:1 to I:12). You should do "Find and Replace" and swap for the real machine input sensors that signal "the part is removed".
 
James,

I revised your last FIFO SAMPLE program. I only changed the necessary things to make the FFU work correctly (unload based on machine state instead of Start Requests).

There are a lot of relays, bits, and timers that can now be deleted, but I left those in so you would recognize it as the same program!

EDIT: The File 3 Station 1 rungs got cut out of the PDF file, so I have resaved it.
That was the problem in a nutshell: the Water Fill Timers T15:1 to T15:12 DID NOT control when the FIFO was unloaded. Instead they only controlled when the machine O:5 Run outputs were energized.


OK... Lancie, I still don't see what's wrong with the second program I posted. (Although... as I think about it, maybe I missed an XIC in front of the FILL ACTIVE flag, duh! Keeo reading, LOL.)


The intent is:

START PB loads the FIFO.

When there are no FILL ACTIVE flags set, the FIFO is unloaded. This is trivial, and I thought it was what we wanted. If no FILL ACTIVE flags are set, nobody is using water. Now, with the 12 station and 36 station machines together, more logic is needed but for just one machine the FILL ACTIVE flag is fine.

RUN COMMAND and FILL ACTIVE are set on the next scan after the FIFO is unloaded. When one of the FILL ACTIVE flags is set, it locks out the FIFO unload. Eventually, the fill timer times out, FILL ACTIVE clears, and the FIFO is unloaded again.

RUN COMMAND is high until the station cycle is done; at that point, the START PB is active again and that station can again load the FIFO.

So, if in fact you put the time required to fill, and then the time after that required to complete the cycle, into James' timers it will work. The START PB will load the FIFO; when no FILL ACTIVE flags are set the FIFO will unload; when the station RUN COMMAND goes down, the station PB will again be active and pressing it will load the FIFO to run that station again.

Lather, rinse, repeat.

The whole point to a FIFO is to capture a series of events at one time, and act on those events at a later time... in the same order that they occurred. I am pretty sure that the second mod I made to James' program is doing that.

NOTE: I'm home today, not at work... so I can't see the program since I didn't PDF it. FILL ACTIVE is supposed to be ON while the fill timers are running, and OFF afterwards. If I forgot to put --|/|-- (Tmr DN) in front of the FILL ACTIVE coil, then duh! LOL. Yeah, that would not work. The whole point is that the FILL ACTIVE flags are set while James' fill timers are running, and OFF when they time out. Given that, his logic in PRG 5 is fine with the FIFO unload at the end and will work.

This stuff with N7:0, ONS bits, and one rung with the FIFO load is just plain silly. Load the FIFO with the station number when station START PB is pressed; unload it when no FILL ACTIVE flag is set. The WATER FILL timers DO control that unload if the WATER FILL timers are set to 4.5 minutes or whatever it really takes. Granted, it would be better to use the fill valve state rather than a timer to control that, but the FIFO logic is fine either way.

Well, everybody have a good Labor Day! I'm out of town for the weekend, I'll check in when I get back.

GL James, take a look at what I wrote and let us know if it helps. I think it should. If I missed the --|/|-- in front of FILL ACTIVE, my apologies to you and everybody - yeah, that would confuse things. Eh, I had to get back to my own work!

Paul T
 
Paul,

Yes, I think you are on the right track now. The program now needs a good clean-up, tightened up, and all the extra rungs and subroutines deleted, comments checked for correctness, and other comments added.

I don't recommend using multiple instances of the FFL instruction for the same stack. I do not know what the results of that will be.
 
Last edited:
Paul,

I simlated multiple instances of the FFL with the LogixPro simulator.

Results:
(1)With all Start Pushbuttons ON, only the first FFL was incremented to Position 1, and the others were ignored. The FFL loads the first true rung, but then since the FFL trigger does not go off again, the others do not see a false-to-true transition, so do not step to the 2 position.

(2)With only one Start Pushbutton ON, the FFL quickly loads all 12 positions with the same number, because it does one load every scan of the PLC. To load correctly, each FFL must be triggered one time for each Start Request FOR ONE SCAN ONLY. Your first machine will probably start and work correctly, but because your remaining 11 Start Requests do not go back off until a much later time, I think if you use multiple FFL instructions, then it is going to be difficult to get the load trigger logic to work correctly.

In this project, because more than one station can request a start at the same time, then the FFL needs trigger logic that is on for one scan, then gets latched off until that machine has finished its run cycle. (The R6:0.EN enable bit can be used to do the latch off) As of now, we don't have any inputs that tell us when the machine cycle is done.

On the other hand, the FFU trigger logic only has to go on, but then can go off at a much later time (not after one PLC scan but after the water fill), because no other machine can run when one machine is filling.
 
Last edited:
In this project, because more than one station can request a start at the same time, then the FFL needs trigger logic that is on for one scan, then gets latched off until that machine has finished its run cycle. (The R6:0.EN enable bit can be used to do the latch off) As of now, we don't have any inputs that tell us when the machine cycle is done.
If a station is allowed to enter Run Requests even when that machine is already running, a savy operator could quickly enter 12 requests first thing in the morning, then have his machine running all day long without any waiting. That is why feedback from the machine steps is needed, to latch out any more run requests after one is entered into the FFL. I suppose that the FFL stack could be checked each time to see if a requesting station has already been entered. Each of the loaded stack positions would have to be checked (before allowing the FFL to load another station number), and that would require a lot of rungs. It would be easier to have a feedback signal that indicates when the machine is finished with its run cycle.

Basically, the First In, First Out Load operation needs to have two steps. The first step allows any non-running station to enter a Run Request at any time in any order. The second step is where this request gets loaded into the FFL.

The second step occurs: when the FFL is not busy with another load, and it must be active until the Control Word Enable goes ON (R6:0.EN is "1", showing that the FFL has been incremented one position). Without this positive acknowledge feedback, the FFL may not be loaded correctly. A timer should not be used, because it cannot be set to exactly equal the variable scan time. Without positive acknowledge, one station may get more than one entry, or it may get no entry at all if it happens to make a request at the exact same time as another station.
 
Last edited:
Paul,

I simlated multiple instances of the FFL with the LogixPro simulator.

Results:
(1)With all Start Pushbuttons ON, only the first FFL was incremented to Position 1, and the others were ignored. The FFL loads the first true rung, but then since the FFL trigger does not go off again, the others do not see a false-to-true transition, so do not step to the 2 position.

(2)With only one Start Pushbutton ON, the FFL quickly loads all 12 positions with the same number, because it does one load every scan of the PLC. To load correctly, each FFL must be triggered one time for each Start Request FOR ONE SCAN ONLY. Your first machine will probably start and work correctly, but because your remaining 11 Start Requests do not go back off until a much later time, I think if you use multiple FFL instructions, then it is going to be difficult to get the load trigger logic to work correctly.

In this project, because more than one station can request a start at the same time, then the FFL needs trigger logic that is on for one scan, then gets latched off until that machine has finished its run cycle. (The R6:0.EN enable bit can be used to do the latch off) As of now, we don't have any inputs that tell us when the machine cycle is done.

On the other hand, the FFU trigger logic only has to go on, but then can go off at a much later time (not after one PLC scan but after the water fill), because no other machine can run when one machine is filling.

Ah. Thanks, Lancie. Great catch... I had forgotten about that.

I know that you can use the FFL in multiple places, because I have two similar machines (I just checked, LOL) that load a FIFO for a four-into-one gantry with any of eight FIFO rungs, each rung loading the same FIFO of course. In that machine, the FIFO false-to-true transition is not an issue. The programs use state logic. When the load is triggered in one of those eight places, it will be "a while" in program terms until the machine state is again such that I would be loading the gantry. Since it's singulating four into one, the part loaded has to be moved and unloaded before the FIFO load might again be active.

Anyway, following is v3 which takes the fact that the FIFO Load must go false into account, and cleans things up a little in the FILL subroutine.

If you have time, try it but I think it will work for simultaneous START PBs. The FIFO Unload is still OK since, once a fill is triggered by a FIFO Unload, it is "a while" before the system state will be such that another unload is possible.

Paul T
 
Last edited:
To All,

Thanks for your help and support in this project.
I worked on it on friday and have the basics working correctly
for the Fifo Load and Unload. I still have some questions
on the operation of the unload, but i need to study the code a little more first before posting.

Yes, i used a 5/03 plc with a 7 slot rack and limited i/o to test the logic. Timers were shortened from 5 minutes to 5 seconds to keep from going to sleep while the process timed out. The cart removal logic is also another area in which timers were used since i didn't have the i/o.

Never the less, i a pleased with what has been done and will begin combining the logic into the actual program after a little more studying has gone into the process.

While i was off, engineering ran the machine using manual controls before a customer came by and discovered that debris was in several pipes preventing water flow to the stations and it was cleaned out.

During the customer visit, he brought several parts he wants us to manufacture of various sizes.

Their consensus is to put in sensors to monitor the water level and they have been ordered. No big problem, we have numerous sensors at the plant.

I will post more questions after i study the program a little more.

Once again, thanks everyone for your help and efforts.

Regards,
James
 
Hi everyone,
Thanks again for your help.

I am attaching my latest program from our bench plc and everything seems to work correctly. lots of the i.o are simulated.

I still need some help in answering a question.
How does the FIFO Unload work?
From the documents provided and your discussions, i have been able to get it to work, but i want a better understanding of the process before putting it in the actual machine.
i need to be able to write a document telling how it works so i don't get calls at 1 in the morning.

thanks again,
james
 

Similar Topics

I am not sure if this is possible but if there is a way, you guys would be the ones to know. I am currently working on a project where we are...
Replies
7
Views
226
Hello all, I'm using a 5069-L330ER in a project and I need to essentially capture some data that will be shown as a trend on a screen. The data...
Replies
9
Views
966
Hello! I have a network of conveyors bringing raw product to 4 machines. A sensor in the hopper of each machine calls for more product. I'm...
Replies
15
Views
5,886
Hello everyone, has anyone out there ever made a FIFO using an FFL and FFU instructions on a Micro800? I have tried setting it up just as I would...
Replies
9
Views
3,125
I have a bottle capper that is using an encoder and FIFO logic to track the free standing bottles passing through a bottle capper. I have checked...
Replies
31
Views
11,685
Back
Top Bottom