Conveyor items stop with moving space > 0

Question

question

Patrick Zweekhorst asked Jun 18, '20 anthony.johnson commented Jun 19, '20

Conveyor items stop with moving space > 0

Hi,

Attached is an example model from my conveyor problem. There is a main conveyor loop with some stations attached to it. In the example you will see part of this loop and 1 station. The items on the conveyor should have a distance of 1.36 meters in between them, which is the setting at the moving space for the belt conveyor. 4 items are removed from the loop and directed to the station. The fifth item should just continue on the loop:

However this is not happening. This 5th item just stops and will never move again. The roller conveyor don't have any moving distance (although I might need that for the roller conveyors on the loop). The belt conveyor is non-accumulating. How can this be solved? I noticed that if I remove a traversel from the 4th item the 5th item continues to move. However I am a bit afraid that this might break other stuff in the conveyor network. Is there a clean solution or work around available?

The example model:

ConveyorMoveDist.fsm

I tested this in the latest release (20.1.3 and 20.0.7)

Thank you for any tips

Software Version:

FlexSim 20.1.2

conveyor flexsim 20.1.2 item stop move distance traversels

1592465222365.png (72.2 KiB)

conveyormovedist.fsm (48.9 KiB)

Answer 1 · 2020-06-18T14:59:56Z

anthony.johnson answered Jun 18, '20 anthony.johnson commented Jun 19, '20

While this behavior is weird given the branch-off, it is technically by design. By specifying a move/entry space larger than the item length, the item will "stay on" the conveyor (it is still seen as an item that is part of the conveyor's set of conveying items) even after it is physically off the conveyor. Thus, if that item stops later down the line, it will stop the upstream nonaccumulating conveyor.

I measured the distances behind the item:

They are only 1.2 meters added up, meaning the item is still "on" that conveyor, and thus the conveyor will block when it blocks.

We could look into this, but I'm not sure exactly what we should do about it. Imagine that this was not a branch-off but a straight inline chain of multiple conveyors. In that case the conveyor would be acting properly IMO. Since the transfer is an inline transfer, the system sees this situation the same as it would that straight inline scenario.

1592492079866.png (197.6 KiB)

· 4

Patrick Zweekhorst commented · Jun 19, 2020 at 02:43 PM

Hi @anthony.johnson

I think your explanation makes sense. In this specific case the behavior looks a bit strange, but as you explain, how should FlexSim know what we need in the case?

While playing with the model yesterday we found that if we remove the first conveyor traversel point on the item when it enters the pick lane everything works as we want. You can see this in the attached model (TestLoop1). We were glad that the problem could be solved with such an easy change.

After changing the speed of the conveyor (to 1.5m/s) the model does not work anymore. The trays stay on Conveyor100 and the photo eyes is always blocked. This might definitely have to do with the fact that we removed the traversel node on the item. If you also think that is the case our solution just is not working as good as we hoped. If something else goes wrong we would like to get some advice on that.

Since our first solution did not work, we are looking at different options. One of those is in attachment TestLoopExitTransfer. This seems to be working pretty well. The only downside is that the item makes a small jump between the exit and the entry transfer. The other thing is that if the pick conveyor is full it is possible that one item stays in the entry transfer. This looks a bit strange and as we think of it right now can only be solved by making some extra logic on the point controlling the number of trays to the pick lane. Is this solution the way you would solve the simulation problem we are facing now?

The last thing we played with is with the transfer type. As you mentioned our transfer is an inline transfer. If we don’t have an inline transfer the loop conveyor would not get blocked when there are items at the pick lane. Is there a setting on the transfer such that we can say that this “stops” the looking ahead, like if it was not an inline transfer, but the item does continue moving short side leading?

I hope this comment is a bit clear for you since the problem is a bit hard to explain. If not just let me know.

BTW is there a way we can make the conveyors look a bit better?:

Thank you for your fast response yesterday and all the information you can provide.

TestLoop_1.fsm

TestLoop_ExitTransfer.fsm

0 ·

1592577679457.png (92.2 KiB)

testloop-1.fsm (185.4 KiB)

testloop-exittransfer.fsm (69.1 KiB)

Patrick Zweekhorst Patrick Zweekhorst commented · Jun 19, 2020 at 02:48 PM

One other downside of the entry and exit transfer solution is that is we mode one of the conveyor new regular transfer will be created. Is this something we can avoid somehow?

0 ·

anthony.johnson ♦♦ Patrick Zweekhorst commented · Jun 19, 2020 at 06:44 PM

One option is to make the conveyors accumulating instead of nonaccumulating. When you think of belt conveyors in real life, generally the reason they don't accumulate is not because blocking items "perpetuate" their blocked-ness down the line, but rather because the system is designed so that items on belt conveyors will never block. Thus, you can use an accumulating conveyor, and just make sure it never blocks, or put photo eyes on the outfeed conveyors that would stop a motor if the outfeed conveyors back up too close to the main line conveyor. This is probably how people would do it in a real system anyway.

The other option is to only have the line's "entry" conveyors have a large entry space, and all conveyors that are outfeed conveyors will have normal spacing. Since it's a nonaccumulating system, once the entry space is ensured on the first entry conveyor, it will keep that way on subsequent conveyors.

0 ·

anthony.johnson ♦♦ Patrick Zweekhorst commented · Jun 19, 2020 at 06:46 PM

As for the weird drawing of the rollers, that's a bug with conveyors that don't have a width of 1. I'll get that fixed for the next release.

0 ·

question