Error when process time is longer than 30s, operator does not finish activity

Question

question

Robert B3 asked Jan 17, '20 Robert B3 commented Jan 20, '20

Error when process time is longer than 30s, operator does not finish activity

Hello,

Does anyone know why the operator cannot finish his activity when the process time is longer than 30s? According to my model, operator should put all products on two queues (half on the below queue and half on the upper) and then next operator should process products starting from below one. The model is attached

When the process is 138s operator is not finishing activity as shown on below ss

But when process time is no longer than 30s, everything works well (beside one products which stays on the queue but its fine)

Thank you in advance for your help!

notfinishedprocess.fsm

Software Version:

FlexSim 17.2.5

process time

138s.png (265.8 KiB)

30s.png (272.6 KiB)

notfinishedprocess.fsm (6.0 MiB)

Answer 1 · 2020-01-17T20:37:16Z

tannerp answered Jan 17, '20 Robert B3 commented Jan 20, '20

Hi @Robert B3,

The queues that the operator is loading to have different batch sizes. If you're passing in 100 objects from Toczenie prowadzenla, there are 50 that go into each queue. The batch size in the top queue is 25, so it can process 2 batches of 25 for a total of 50. The batch size of the bottom queue is 24, however, so it will have 2 objects leftover. This is assuming that the operator delivers the same amount to each queue. To test this, change the batch size to 23 and you'll see that only 46/50 items process, leaving 4.

I think there might be some underlying problems besides this, because the Stats Collector was throwing errors for me when the Process Time was lower than 30. Maybe you could explain briefly what the process is between Toczenie prowadzenia and the two processors, "Fazowanie" and "Gwintowanie"? That way we can go through the logic to make sure everything is set up correctly.

different-batch-sizes.png (30.9 KiB)

· 3

Robert B3 commented · Jan 17, 2020 at 10:21 PM

Hi @tanner.p,

Thank you very much for assistance,

I'm aware of the different batch sizes, but if I set the same amount, the operator assigns one more to the other queue and the riffling won't start.

The logic is: from Leath is coming out 50 products (it takes 138s per one product) which are being devided beetween two intermediate storage area until they get full - 25 each. Once queues are full next operator starts from rifling which takes 77sec per product, right after he finishs he is moving to chamfering position wich takes 29 sec per product.

my issues are: if i set in lathwork 138sec the operator doesn't devide them corectly betwen two queues ( i used methodh - (send to port - the shortest queue)) and the process stops. Please find it in the model

notfinishedprocess.fsm

0 ·

notfinishedprocess.fsm (6.2 MiB)

storagearea.png (214.8 KiB)

tannerp Robert B3 commented · Jan 17, 2020 at 11:11 PM

Thanks for the details on the logic and the specific issues. I have a few suggestions that might help.

First suggestion: Make sure that all the queues and other objects in your model have unique names. (i.e. instead of having 10 "intermediate storage area" queues, have "intermediate storage area1", "intermediate storage area2", etc.) This will avoid confusion in the logic.

Second suggestion: Use "Round Robin" instead of "Shortest Queue". That way, an even number get sent to both queues.

Third suggestion: You mentioned that the items are first processed at "Rifling", then at "Chamfering". If that's the case, these processors should be in sequence. What is happening is that half of the items coming from the Lathe are being sent first to Chamfering and the other half to Rifling. It sounds like all items should go first to Rifling and then Chamfering.

I've made some changes in an updated model. Let me know if the updated model I've attached here does what you're looking for.

notfinishedprocesshelp-1.fsm

0 ·

notfinishedprocesshelp-1.fsm (6.2 MiB)

round-robin-send-to-port.png (21.3 KiB)

Robert B3 tannerp commented · Jan 20, 2020 at 11:18 PM

Hi @tanner.p

It was exactly what i was looking for. Thank you so much for helping me out.

1 ·

question