Cancel
Showing results for 
Search instead for 
Did you mean: 

Carry part away in buffer, using different workers

Solution Partner Legend Solution Partner Legend
Solution Partner Legend

I have a buffer which should carry parts away using different workergroups.

 

Part A enter the buffer. In a entrance control (before actions) I get the next destination from a table, and sets the parts destination attribute to that. In the same table I also have a specific workergroup that should carry out the transportation job. 

 

I currently have two brokers, each are connected to a specific workerpool. I change the brokerpath of the buffer to the active brokerpath. Part A requests broker_1.

 

Part B enters the buffer and requests broker_2, while Part A is waiting for a worker from broker_1. The idea is that Part B should be able to exit the buffer before Part A, if the workers in broker_2 are available before broker_1.

Now I get an error, see printscreen.

 

I understand why the error happens, but I don't know how to figure out a workaround. Is it possible to not use a broker in the buffer's broker field and instead request a broker with code, in the same way you don't need to have a MUtarget and use the attribute destination instead?

 

Or perhaps it is better to have just one broker and have the two workerpools connected to a single broker? But then I don't know how to differentiate between the workerpools from the buffer's perspective.

I know it is possible to solve by using several buffers, one for each workerpool, but I would prefer to avoid this.

5 REPLIES 5

Re: Carry part away in buffer, using different workers

Phenom
Phenom

please find attached another attempt

 

by selecting/ prioritizing the MUs with available 

 

operators through the exit control

 

of the buffer.

 

Unbenannt.PNG

Re: Carry part away in buffer, using different workers

Solution Partner Legend Solution Partner Legend
Solution Partner Legend

Thank you for the idea, I did not think of that!

 

But the solution seem to have two major delimitations. 

 

For example (if I understand the model correctly), the necessary dwell time in the buffer becomes a delay for when the workers actually can pick up the parts. By having a low dwell time it will result in a smaller delay, but there will be a lot of method-calls, that might be unnecessary.

 

Also, the products will change position to exit the buffer in a cyclic behaviour, so the product that happen to be the next to exit the buffer when a worker is available will basically be a random mu of the producttype (A or B), i.e. not FIFO at all. In my initial post I know I said that products should be able to pass each other, but not the products of the same type (product A can pass a product B, but a product A can not pass a product A).
This is quite visible if we change the production plan to only 10 products A. The products entering station1 is (basically) in a random order.

 

I do not want to just give you a lot of criticism, I realy appreciate the help. But I am in need of another solution. 
Perhaps it is necessary to "build" a buffer using several bufferObjects in a separate frame. And control the logic from inside the frame. 

Re: Carry part away in buffer, using different workers

Phenom
Phenom
What problem do you have in using multiple buffers ?

Wrapped in a frame you won't see a difference to a single buffer

Re: Carry part away in buffer, using different workers

Solution Partner Legend Solution Partner Legend
Solution Partner Legend

I am trying to develop a flexible library that can just be inserted in models and work with existing models/objects(for example buffers). The library is going to handle workergroups and the jobs they need to execute. 

 

By making custom-objects I will need to replace objects(buffers) with my custom-objects and make sure the existing logic works in my custom-objects as well. This is what I want to avoid.

Re: Carry part away in buffer, using different workers

Solution Partner Legend Solution Partner Legend
Solution Partner Legend

I developed your model a bit further, see attached.

 

I think this behaviour is good enough. All logic is set in a single method, mEntrance. When implementing the library I simply need to call for this method in those objects that can have several different productTypes to transport.

 

The downside is that I can't bypass the necessary delay-time. It is not as a dwelltime in the buffer anymore, but as a wait-statement in mEntrance. It is set to 1 second now, should be good enough.

 

I also need a additional table which contains several custom-attributes for every station. But they should be quite easy to add in models with some coding.