fifo for 2 machines

[Paul T]

Aha! So, really, the only criteria is that you cannot be FILLING more than one station at once?? And you can only fill ONE at a time??

OK... that is a pretty simple constraint.

So, your "RUNNING" flag just becomes a "FILLING" flag that goes up when the START command is seen, and goes down when the fill is done. As Lancie said, you may want some additonal conditions on that... good thoughts Lancie.

For the FIFO... let's talk about the 12-stn machine for simplcity. You are going to have 12 FIFO load rungs, someplace in the existing logic for the machine. When the START PB for the station is pressed, you load the FIFO with the NUMBER of that station.

Now, you still need the new subr. But instead of having to count stations, you maybe just have one flag - FILLING ACTIVE - that either lets you proceed, or just leads to a RET if it's set.

Assuming you proceed, you look to see if the FIFO is Empty. If it is, nothing is waiting to start and again you RET.

If it's not, you do an UNLOAD. The UNLOAD will put a number... a station number... into the register you've designated as the Unload Register. Now, with that number, you can set the STN START CMD flag for that station. Then, RET.

Another thing you'll want your machine reset logic to do is clear this FIFO. After an EStop, or at powerup, you'll want to make sure the FIFO is Empty else it will suddenly try and start a station. And, what happens if the FIFO tries to start the station but the door is open or some starting IK is not met?? The FIFO has been unloaded of that station, so if it doesn't start how big a deal is that and what do you need to do to make sure your logic proceeds to unload the next station number out of the FIFO?

Also, you will have a small issue in that, if say six stations are in the FIFO stack and the OPR suddenly decides that one of them should not run, well there it is in the middle of the stack and you can't get it out. So, good practice requires that you have ANOTHER flag for the station - something like STN START KILL. If, after pressing the START PB and adding the station to the FIFO, the OPR changes his mind later, but before that station has started, he presses a button and it sets the KILL flag. That flag then goes into your station start logic so that when the FIFO is unloaded, the station doesn't start after all and the logic just continues on.

Some more ideas for ya. Just what you needed, right?? LOL! It's always the exceptions and transitions, not the normal RUN stuff, that kills you.

 

[James Mcquade]

thanks everyone !

i'm off on fridays and the weekend, so see you on monday.

regards,
james

 

[Lancie1]

We have been doing research into the machine process and have discovered that if we limit the stations in process to one at a time, we have plenty of water... We can start the next station when step 3 mentioned above is complete. If we can do that, we can meet production rate and not cause any strain on our resources.

Yes, I thought that was exactly what would happen. Usualy the easy path is taken, even though it means your PLC program will reamain "dumb". By dumb, I mean that it will not know what is going on in the real world, but will be isolated from knowledge about the actual problem you have set out to solve - the problem of too little water. If the PLC program does not actually know WHEN THERE IS NOT ENOUGH WATER, think about what that means. It means that the reason for the machine start sequence will not be part of the program, so at some point this knowledge will be forgotten, lost, thrown in the dust bin. Someone else will come along and ask "why are we not running more of these machines?" The "if we just did THIS, I bet we could increase production" cycle will start all over again.

You can probably make it work without this water sensor from the real world, and make your program live in an imaginary world where there is always just the right amount of water if only certain machines are not started at certain times. However, conditions change, stuff happens, and it is best to get the information from real sources, not have to create imaginary knowledge. The above needed saying, because it could save a lot of grief down the road, but now I will get off my soap box.

I am having trouble understanding how the commands relate to
the station numbers.

The FIFO is a stack of memory word values, so each position can contain ANY 16-bit value. It is up to you to write program logic to cause the number of the station that makes the next Start Request to be loaded into the Source address of the FIFO (N7:0 in my posted example). Then on following rungs, the FFL is enabled to cause the same Start Request to move the number (now in N7:0) to the next empty position of the FIFO stack.

At this time, someone should point out that you may not even need a FIFO (First In, First Out sequencer). Question: Do you really care WHICH machine starts next, as long as the next one does not start before the last machine has finished Step 3? If the answer is NO, then you probably can live without a FIFO, and use much simpler logic, a simple Latch relay called "START POSSIBLE". When that relay is latched, the next machine to make a request will be enabled, but if START POSSIBLE is unlatched, then all remaining machines will have to wait their turn. In case there are more than 1 machine waiting to start (a "tie" condition), they will be started in the order that they are entered in the program rungs.

 

[James Mcquade]

Thanks,
everyone for your responses.

I have been working on the fifo and have gotten a large part of it complete. I am now working on the details of the unload.

again thanks,
james

 

[Lancie1]

If it's not, you do an UNLOAD. The UNLOAD will put a number... a station number... into the register you've designated as the Unload Register. Now, with that number, you can set the STN START CMD flag for that station. Then, RET.

Paul T,
Yes, but UNLOAD may occur much later than the Start Request. Remember that UNLOAD should only happen if the "last machine started" has finished Step 3. Unload should not necessarily happen every time a Load occurs.

I think your method is trying to restrict the LOADING of the FIFO, when it should not. The loading should happen upon any Start Request, but the Unloading should be where the machine start restrictions occur.

The beauty and usefulness of the FIFO is that it allows you to use one set of instructions to Load, but an entirely different set to cause the Unload (where the action happens). I think that is exactly what is needed here.

 

[James Mcquade]

My assigned projects with the exception of this on i am discussing with this site are done and i finally got a breather.

Being the only plc programmer with several years of experience
is a pain at times. everyone wants your help all at once, their problem is top priority. Glad i have a boss to tell me what to do sometimes.

I have written my code for the fifo load, but i am having trouble tying the load, processing, and unload together.

I will look into the program a little deeper before posting my specific problem encountered and program.

regards,
james

 

[Lancie1]

I have written my code for the fifo load, but i am having trouble tying the load, processing, and unload together.

Your FFL and FFU instructions in your PLC program should share certain memory locations. The FIFO, Control, Length, and Position should be the same for both instructions. Source and Desitination should be different addresses. As I mentioned earlier, in your case, the instructions preceding your FFL should be what it takes to move a Station Number into the Source Address of the FFL. But the instructions preceding your FFU should be indicators that the last machine started has finished filling with water. The Unload trigger should not be tied to the FFL Load trigger in any way at all.

FFL/FFU [First In First Out Load/Unload]
Rockwell Software 2000
Use with processors SLC 5/02, SLC 5/03, SLC 5/04, SLC 5/05, all MicroLogix.

Description
FFL and FFU output instructions are used in pairs. The FFL loads words into a user-created file called a FIFO stack on successive false-to-true transitions of the rungs controlling input logic. The FFU (FIFO Unload) unloads words from the FIFO stack in the same order as they were entered.
This instruction is helpful in applications where it is necessary to load and unload values in the same order. An example might be tracking parts through an assembly line where parts are represented by values that have a part number and assembly code.

If you are using a 5/02, 5/03, 5/04, 5/05 or MicroLogix processor, you can use indexed addresses for the source or destination parameters. If you are using a 5/03 OS302, a 5/04 OS401, or a 5/05 processor, you can use indirect addresses for the source or destination parameters.

Entering Parameters
Source is a word address or program constant (-32768 to 32767) that stores the value to be entered next into the FIFO stack. The FFL instruction places this value into the next available element in the FIFO stack.

Destination is a word address that stores the value which exits from the FIFO stack. The FFU instruction unloads this value from the stack and places it in this word address.
FIFO is the address of the stack. It must be an indexed word address in the input, output, status, bit, or integer file. The same address is programmed for the FFL and FFU instructions.

Length is the maximum number of elements in the stack, up to a maximum of 128 words. The same number is programmed for the FFL and FFU instructions.

Position is the next available location where the instruction loads data into the stack. This value changes after each load or unload operation. The same number is used for the FFL and FFU instructions.

Control is a control file address. The status bits, the stack length, and the position value are stored in this element. The same address is programmed for the FFL and FFU instructions.

The control element:
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
Word 0 EN EU DN EM
Word 1 Length
Word 2 Position
Warning! Except when pairing stack instructions, do not use the same control address for any other instruction. Unexpected operation could result with possible equipment damage and/or personal injury.

Status bits in the control element include:
12 = EM (empty) bit
13 = DN (done) bit
14 = EU (FFU enable) bit
15 = EN (FFL enable) bit

Note: Any offset value present in S:24 is overwritten with the position value when a false to true transition of the FFL or FFU rung occurs. Make sure to load the correct offset value back to S:24 after a FIFO execution if you use indexed addressing within your program.
In an FFU, S:24 holds the exit position.
In an FFL S:24 holds the entry position.
Rockwell Software 2000

 

[todster]

Probably a bad idea but what about something based on round robin and priorities. Say A = highest D= down for maintenance. Priorities could be based on idle time, station temp. or whatever you want.
For The logic something like Mov 0 into Nx:x on 1st scan or any reset or estop. Hit the start button and mov 1 into Nx:x. Now all the stations have logic that goes something like Station 1 "if Nx:x = 1 and ok_to_start_cycle and priority is A and not D then start_enable_bit1". Next rung "If Nx:x =1 and not start_enable_bit1 then Mov 2 to Nx:x"
Station 2 "if Nx:x = 2 and ok_to_start_cycle and priority is A and not D then start_enable_bit2". Next rung "If Nx:x =2 and not_start_enable bit2 then Mov 3 to Nx:x" so on so forth.
The start_enable bit can then be used in other rungs before actually starting the cycle.

 

[Lancie1]

Todster,

That is a good method, and it will work. James has indicated that the station starts could be random (not in numerical order but based on when operator is present and machine is ready). For that reason, the system must be able to accept a start request from any machine in any order at any time. But the Start Enable must not be ON until the previous machine that started has finished filling with water. Could you adapt your method to allow random start requests (instead of numberical order)?

 

[todster]

Todster,

That is a good method, and it will work. James has indicated that the station starts could be random (not in numerical order but based on when operator is present and machine is ready). For that reason, the system must be able to accept a start request from any machine in any order at any time. But the Start Enable must not be ON until the previous machine that started has finished filling with water. Could you adapt your method to allow random start requests (instead of numberical order)?

I don't think it's anything to really adapt. Just create the priority logic that would determine when a station should be priority A B or C. You could also create logic that would generate a random number and move it to Nx:x. If that isn't ready next random. Or, Why not use the start requests as part of the priority logic. A is anything with a ready state and B is pre-ready (it's ready but the operator hasn't signaled for it yet), C is currently in use, D is locked out, skip station always. Create a filling logic that uses a timer , if the 4.5 min loop is exceeded, set bit for alarm, otherwise if Fill_timer_DN and cycle_complete and No alarms, then set bit for Next_Ready.
There's a million ways you could branch and test before enable.

 

[Lancie1]

You could also create logic that would generate a random number and move it to Nx:x. If that isn't ready next random.

Sorry, I didn't explain it well. The 12 stations will have start requests that ARE random (they can occur at any time in any order - no need to generate random numbers). The problem is how to handle these randomly-occurring requests so that the first one gets started first, and the second one gets started second, and so on. That is the only function that the FIFO needs to perform for this problem.

 

[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

 

[roushan]

yes you can use fifo.its a good idea.and i am sure it will work.you use fifo(ffl) to store the value..give some time so that the next processor could scan that valve. then you unlatch(ffu) it by the timer with preset will based on scan time of next processor...you can use integer/string in whatever u r comfortable.
i have used it in Indian oil corporation project.

 

[Lancie1]

I had some time, so added more detail to FIFO Load and FIFO Unload. This program Loads FIFO with Station Number of Next Station to Request Start.

FIFO Unload is only performed if: No station is running, OR Last Station has finished Water Fill. Because James did not provide any inputs for the Station Water Fill, I used timers to represent the time from Station Start until Step 3 Filling is finished. If each station produces a flag bit that shows when the Step 3 is finished, then that could be substituted (and be more accurate)in place of the 12 timers in my program.

The ZIPPED file is a RSLogix500 program (*.RSS).

 

[Lancie1]

Revision 2 provides better control of FIFO Load operation, and uses Timers to reset Run Requests so that only one input bit is needed from each station machine.