question

Mikael B avatar image
1 Like"
Mikael B asked Jason Lightfoot edited

Setting outbound item to stored state

Is it possible to set an outbound item to a stored state again? Ive tried by setting assignedslot = currentslot, while the item is still in its current slot, but this seems to create a duplicate of the item in the slot.

*EDIT*

Ive made a demo to demonstrate the problem, link at the bottom of the post.

As you can see, setting a storage item to outbound, and then reassigning the slot, to set the storage item to a stored state, creates a duplicate slot item.

Is this an intended feature or a bug? Is it possible to achieve the same result an easy way without creating duplicates?

I managed to find a pretty messy workaround last night, where i first reassign the slot to the storage item after it has been set to outbound, then move the item out of the rack to a queue and back to the rack again with Move Object in process flow. This method seems to fix the duplication issue, but its not a very smooth workaround.

slotItemDuplication.fsm

FlexSim 20.0.10
flexsim 20.0.10outboundstorage.item.statestored
· 3
5 |100000

Up to 12 attachments (including images) can be used with a maximum of 23.8 MiB each and 47.7 MiB total.

Joerg Vogel avatar image Joerg Vogel commented ·

Have you tried to replace

storageItem.assignedSlot = 0; // with
storageItem.assignedSlot = NULL;

? Because if "0" is a valid reference to a different node, then you would naturally assign two values to the assigned slot node and you get a count of two.

0 Likes 0 ·
Mikael B avatar image Mikael B Joerg Vogel commented ·

I tried it just now in the attached demo model. Returns the excact same result.

0 Likes 0 ·
Joerg Vogel avatar image Joerg Vogel Mikael B commented ·

I get to the same result.

0 Likes 0 ·

1 Answer

Lars Jacobsen avatar image
0 Likes"
Lars Jacobsen answered Jason Lightfoot edited

You can set the outbound state using Storage.Item (not Storage.Slot.Item). I.e.

Storage.Item item = Storage.Item(token.item);

item.assignedSlot = item.currentSlot;

To get a fast and accurate response, please provide as a minimum the exact code and preferably also a model with the problem.

· 6
5 |100000

Up to 12 attachments (including images) can be used with a maximum of 23.8 MiB each and 47.7 MiB total.

Lars Jacobsen avatar image Lars Jacobsen commented ·

@jason.lightfoot Can you help? It seems to be a bug

1 Like 1 ·
Mikael B avatar image Mikael B commented ·

I updated the original post with a demo model and more information, which i hope clarifies the problem!

0 Likes 0 ·
Jason Lightfoot avatar image Jason Lightfoot ♦♦ Mikael B commented ·

Thanks for this information - it does look like a bug or unsupported behaviour, where assigning the slot doesn't first check if the storage items currentSlot is the same as the assigned slot. If it is it should just create a pointer node that references the same node as the currentSlot pointer.

We could create a user command "reassignSlot" as a workaround that would just create the correct pointer nodes in the tree, but that might miss something happening in the background in the class. You can try it at your own risk with this code:

Storage.Item storageItem = Storage.Item(Model.find("Rack1/Box1"));
treenode si= storageItem;
createcopy(node("currentSlot/1",si),node("assignedSlot",si));

I'll add a note to the dev list to consider supporting slot reassigment for items that have been unassigned.

1 Like 1 ·
Mikael B avatar image Mikael B Jason Lightfoot ♦♦ commented ·

Thanks for your input Jason!

I think i will continue to use the workaround i found, to avoid accidently corrupting the model just to be careful.

Step-by-step walkthrough for future reference:

1. Assign current rack and a queue to token labels (token.rack and token.queue)

2. Assign slot (custom code activity):

Storage.Item obj = Storage.Item(token.Item);
obj.assignedSlot = obj.currentSlot;

3. Move Object activity (move token.Item to token.queue)

4. Move Object activity (move token.Item to token.rack)

5. Restack slot (dont know if this actually does anything, implemented just in case):

Storage.Item storageItem = Storage.Item(token.Item);
Storage.Slot slot = storageItem.assignedSlot;
slot.restack();


By hiding the queue, this wont be visible in the model view and will happen instantly, but i have no idea how this acitivity block affects performance and model run speed.

0 Likes 0 ·
Show more comments