Thoughts on how to approach this task...

Join Date
Jul 2007
Location
Kiruna
Posts
600
Hi guys,

I have a number of identical machines who share resources such as water, feed material, air, conveying.

All are AB CompactLogix systems and I already implemented coordination of the resources via produced/consumed communications amongst the controllers.

In order to maintain a robust system I do not want any of them to be dependent on each other in the event of loss of comms due to a shut down of one of the machines. Each one should make its own decisions and is aware of the active step of all others.

If one machine is feeding, the others can or cannot depending on max number of users for that resource. This is working correctly.

The problem now is now what happens if multiple resources are waiting on the same resource. Using timers I can prioritize them. So if machine 1 has a 1 sec timer and machine 2 has a 2 sec timer before giving a OK_TO_USE_RESOURCE then machine 1 will always have priority.

What I now realise is I need to make a queue system. So if more need that resource too they will join a queue for first come first served.

How would you approach this for this scenario? If it was in a single controller it would be straightforward but I don't want a master PLC hosting the queue logic as it may not always be online.

Hope that makes sense. I'm not looking for logic, just some advice on how to implement it.
 
You will probably need a Master controller connected to all the "resources" controllers/instrumentation and to each machine CPUs.
The Resource Availability and Machine Resource Access Priority queues will be implemented within the Master controller application.
A mid-tier CompactLogix would suffice; it will be Producing/Consuming data to/from all involved parties.
 
You will probably need a Master controller connected to all the "resources" controllers/instrumentation and to each machine CPUs.
The Resource Availability and Machine Resource Access Priority queues will be implemented within the Master controller application.
A mid-tier CompactLogix would suffice; it will be Producing/Consuming data to/from all involved parties.

That's not an option for this. Given the project, there could be a single machine or even 10 machines. Each machine knows that its partners are doing so can decide if its allowed that resource or wait. There is no need for a master (at least up to now).

If I can somehow create a queue and share the queue with its partners then I'm hoping thiswill take care of it.
 
If you really are against a Master then you will have to rank the machines' CPUs and replicate the resources queues in each application.

#1 Rank CPU will drive the system with its own queue if Online while denying all other ranks' decision making.

If #1 is Offline then #2 will use its own queue and so on.

Each CPU will "look-up" the higher ranks' "permissions" for taking over the resource processing.

Obviously, the more machines the more "rank" permutations will need to be implemented.
 
I would just add another DINT to your produced/consumed tag structure from each PLC.

PLC1 joins the queue - it sees that all other PLC's have a "queue" value of zero, so it assumes position 1 in the queue, and writes a 1 into that DINT tag to indicate as such.

PLC2 joins the queue. It sees one PLC has a queue value of 1, and all others have a value of zero, so it assumes position 2 in the queue, and writes a 2 into that DINT tag to indicate as such.

PLC3 joins the queue. It sees one PLC has a queue value of 1, another has a value of 2, and all others have a value of zero, so it assumes position 3 in the queue, and writes a 3 into that DINT tag to indicate as such.

PLC4 and PLC5 do the same, writing 4 and 5 into their "queue" DINT.

Your material becomes available. PLC1 sees that it is available, and notes that it is at position 1 in the queue, so it sends a signal to whoever produces that "material available" flag that it will accept the material. The "material available" flag turns off, and PLC1 sets it's queue position to zero and begins making widgets. IMPORTANT: ensure that the "material available" flag is turned off BEFORE PLC1 resets it's queue position to zero.

PLC2 sees that it has queue position 2, but nobody has queue position 1. It subtracts 1 from it's queue position and assumes position 1.

PLC3 sees that it has queue position 3, but nobody has queue position 2. It subtracts 1 from it's queue position and assumes position 2.

PLC4 and PLC5 do the same, so now we have:

PLC2=1
PLC3=2
PLC4=3
PLC5=4

Now, PLC4 has an aneurysm and falls off the network. All other PLC's are set up such that if a PLC is offline, all of it's data is overwritten by zeroes. So as soon as this happens, the consumed tag in PLC1-3 and PLC5 that indicates PLC4's position in the queue is set to zero.

PLC5 now sees that it has queue position 4, but nobody has queue position 3. It subtracts 1 from it's queue position and assumes position 3.

PLC4 recovers from it's episode and re-joins the network. Hopefully, a "first scan" condition or a "network loss" condition or something has triggered this PLC to reset it's queue position, so it will see that queue positions 1 through 3 are taken and assume position 4. If, for whatever reason, it has not done that, and it still wants position 3 in the queue, then you will have to make a call as to which machine can have it. I would say that this is such a rare occurrence that for the small amount of times it were to happen, it probably wouldn't cause a problem no matter which way you approach it.

Does that work the way you're after?
 
Each CPU has their own queue position
Cpu1.Resource1_que_pos = 0

Each CPU can see each others queue.
Cpu1.Cpu2_Resource1_que_pos = 1
Cpu1.Cpu3_Resource1_que_pos = 0
Cpu1.Cpu4_Resource1_que_pos = 0

To join the queue, place your CPU number in the next highest slot. CPU3 joins queue.

Cpu1.Resource1_que_pos = 0
Cpu1.Cpu2_Resource1_que_pos = 1
Cpu1.Cpu3_Resource1_que_pos = 2
Cpu1.Cpu4_Resource1_que_pos = 0

Now you are not "in" until you have been the highest CPU number at that queue position for 2seconds or whatever. If you lose the tiebreaker, you rejoin the end of the queue.

Cpu1.Resource1_que_pos = 3
Cpu1.Cpu2_Resource1_que_pos = 1
Cpu1.Cpu3_Resource1_que_pos = 2
Cpu1.Cpu4_Resource1_que_pos = 3 //received 50ms after joining the queue yourself)

Cpu1.Resource1_que_pos = 4 //rejoin at que POS 4 because CPU4 has higher priority than cpu1
Cpu1.Cpu2_Resource1_que_pos = 1
Cpu1.Cpu3_Resource1_que_pos = 2
Cpu1.Cpu4_Resource1_que_pos = 3

Now if the person in front of you leaves the queue, take their spot.
 
Well First of all, it seems those down under boys think alike 🍺 and it sounds like a viable solution. I just want to throw out something different to think about. Would a simple handshake work between all machines. I don't use produced/consume very often but I seem to remember they update on a 20ms cycle. So if each machine has a status array of DINT for the other machines you can have each machine reset the other machine status DINT every 40 or 60ms and the active machine is updating its status every 20ms. So, unless a machine finds resource inactive it cannot use it. That way if the Machine is shutdown with an active resource the others will reset their status word for that machine on a time cycle and it will not set again since that machine is off. An Array of 111 DINT would allow 10 DINT Status Words for each of the 10 Machines and 10 control words. Use the bits of the Status DINT To Know if the resource is inactive. Then each Machine would have a Control DINT to activate resource code when found available. Basically everybody monitors everybody with separate status bits and uses what it finds to set control bits. Also use Control Word to Set Status Words.

The Array 111 would allow the Following:
Array words 1-10 would be used for control words for Machine 1-10. (0 not used)

Array words 21,31,41,51,61,71,81,91,101 would be status words for Machine 1 to other machines. Word 11 would not be used. No need for machine 1 to monitor machine 1 status. That way words ending in 1 would be monitored for Machine 1's active resources. Then, by setting bits of the Control Word when Status Bits allow, you only need to copy Control Word Value to Status Words to set all Status Bits.

Machine 2 Status 12,32,42,52,62,72,82,92,102 (22 not used)
...
...
Machine 10 Status 110,20,30,40,50,60,70,80,90 (100 not used)
 
Red Lion gateway. Simple and effective. You guy's talk too much.

And you clearly don't read enough. The OP is looking for a solution that doesn't have a single point of failure. Adding a red lion gateway will not achieve that objective.

ASF and Australian's solutions will.
 
First, this seems like a typical "Sequencer" application. (search pump sequencer)

To answer your question, create a universal Sequencer Logic routine and add this identical routine to every Logix processor involved in this process.

Each processor will be capable of controlling the Sequencer logic.
Only one processor will actually control the sequencer.
When one processor goes offline the sequencer control is taken over by the next processor.
Assign each processor a number and a hierarchy of control so #1 is master and when that one goes offline, Sequencer control switches to processor #2., #3 and so on and so forth
 

Similar Topics

https://rockwellautomation.custhelp.com/app/answers/answer_view/a_id/1133982 What kind of hiccups could be expected before Rockwell puts out...
Replies
8
Views
4,405
I was replacing a VFD today, and when I powered down the MCC bucket, the SCADA went into alarm (as I would expect it to). I acknowledged the alarm...
Replies
24
Views
5,366
Called to a site and am neck deep currently ;) running, but issues. Phase 2 completion has been running for almost 2 years no issues. Controller...
Replies
3
Views
1,615
Hi All, I am building a Profibus network using a Mitsubishi QJ71PB92D Profibus Master Module. Current Setup: - 1- Profibus Master (Resistor On)...
Replies
13
Views
2,607
Good Afternoon , I have used many 1794-AENT Ethernet Adaptors , and never had this problem . I used BootP and assigned the IP Address , sent...
Replies
1
Views
1,860
Back
Top Bottom