Trouble with Tutorial 1.3 and Tutorial 2.1

[mia_mancheski]

Good afternoon everyone!

I need some help with understanding what went wrong with my process flow. At the moment, I am trying to combine Tutorial 1.3 and 2.1 to simulate a material inspection process and storage. I am trying to make it where once the Logistics Team inspects the material, all of the material that passes inspection can then be organized in the floor storage in their respective areas. I was able to get them to organize the material but they kept inspecting the material and organizing it after each box they inspected. I am trying to get them to inspect it first and then organize it but I can't get it done. I tried using "priority" in the model as well as using "list" in the process flow but neither are working. I attached the file for reference. If anyone knows how to make either work, please let me know! I'm still trying to figure out how to make the "priority" and "list" settings work. 

Thanks in advance!

[mia_mancheski]

Here is the file!

[moehlmann_fe]

I am not sure what you were going for with the last part of the Process Flow. The list seems to be not needed at all. The tokens from the Event-Triggered Source can just directly acquire an operator and have it move the item to the Floor Storage. I want to highlight one potential issue with simply unloading to the Floor Storage. In order to be placed in the storage, an item must be assigned a slot in it. When the unload task is started, the Slot Assignment Strategy of the storage is used to assign a slot to the item. When there is not available slot this will result in an error message though. When moving an item to storage in Process Flow it is safer to first use a Find Slot activity to assign a slot (which will hold the token until a slot was found) and only then start the transport task.

[mia_mancheski]

The last process flow was an accident. I had meant to delete it. I had originally programmed the operators to move the objects into the floor storage after inspection but I wanted to try it out where they have to complete the inspection with all of the boxes first, before starting to organize them. I had used the "Paint Slot Labels" in the warehousing section of the model to assign slots. There should not be a time where an item doesn't have a slot to it unless there are too many objects for the slots it was given. I see how you added the Find Slot activity, is this coordinating with the paint slot label or is it a separate part? 

The question still is, though, how do I have the team inspect all of the boxes first and then organize them? I also noticed that one of the team members was just inspecting the boxes and putting them in the queue (never organizing). Should I be worried that it isn't doesn't follow the same logic/behavior as the other operators?

Thanks!

[moehlmann_fe · Accepted solution]

By default, which token gets to acquire a resource (like the operators) when there are multiple pending requests solely depends on the time when the request was created. Meaning whichever token entered the Acquire activity first gets the resource.

You can define a "Queue Strategy" in the resource activity that governs this instead. For example by ordering by a label value that you set before the token enters the Acquire activity. This way you can give certain tasks priority over others.

[mia_mancheski]

Thank you! It is working now. A quick question though, how did you set up the queue strategy? Can I set up a queue strategy that allows me to use multiple operators to complete different processes on the same processor? For instance, what if there was one step that needed 2 operators on one processor, but then needed 3 operators in the next step on the same processor?

[moehlmann_fe]

A Queue Strategy takes the form of an SQL ORDER BY statement, as you can see in the screenshot in my other post. "puller" refers to the token (for Acquire activities, in a Pull from List activity you can define the puller yourself). So when a resource becomes available the pullers are sorted by the "AcquirePrio" label in descending order and then try to acquire the resource in that order.

With regards to using multiple operators: That is up to you how you want to implement this. You could acquire three right away and keep one 'in reserve'. Or you first acquire two and then add another one with a very high priority (meaning set the label to a large value before acquiring the third operator).

[mia_mancheski]

I see. I tried adjusting the storage area model so now it has multiple possible storage areas. However, an error pops up when I run the simulation: "SqlQuery Object". I am not entirely sure what I did wrong. I had tried replicating the model you had sent without making any adjustments and the error message still pops up. I attached the new model to this reply so you can see what I tried to do. I had grouped all of the possible storage areas together so they can work as one unit. Does this error message mean that I need to include another AcquirePrio label?

[moehlmann_fe]

The error message is telling you that the label "Label1" does not exist on all slots.

time: 1482.370633 exception: FlexScript exception: Invalid access to a Storage.Slot label that does not exist at MODEL:/Tools/StorageSystem>variables/slotQueries/1/flexScriptCallbacks/3/codeNode at line 3
time: 1482.370633 exception: SQL Evaluation Exception: FlexScript exception thrown in evaluation of code. Code is: param(1).as(Storage.Slot).Label1. Forwarding throw.
time: 1482.370633 exception: SqlQuery - FlexScript Exception in: WHERE slot.Label1 == $1.Label1 AND slot.hasSpace($1)

 What I did in the other model is to define it in the Storage System properties. This allows to set a default value for the label that gets used when no label was painted onto a slot or assigned in other ways. Additionally, indexing the label speeds up slot queries and most of the time makes sense for labels that do not change during the simulation run.

[mia_mancheski]

I was able to change the Slot Labels as well as the code involved in the Racks from the suggestions you made. However, I am still having a similar issue with the Pallet Racks saying that there was "No slot assigned to item", which makes no sense because I click on the items that are stopping the movement of the operators, and they have assigned slots. I also assigned an item to each slot in all of the racks in case that was the issue too, but it wasn't. I also adjusted the release information for the Material Rack as a resource which helped resolve another issue I was having. I'll link an updated version that I had made.

[moehlmann_fe · Accepted solution]

"Find Slot" currently assigns a matching slot in any of the racks (as it should be I think). The item is however unloaded to the rack that was acquired by the token. The acquired rack and the rack the assigned slot belongs to might not match. At that point the Slot Assignment Strategy of the rack will be used when the unload task starts and try to find a slot. If not matching slot exists, you get the error message you are seeing.

I don't really see why the racks need to be acquired. I guess to that the operators spread out more? If you want to keep the Acquire, find the slot first, then get a reference to the rack it belongs to via the slot reference, then have the token acquire that specific rack.

[mia_mancheski]

Yes! Thank you so much it works now.

[mia_mancheski]

Hello again. Quick question: why is it that only 2 of the 5 operators are helping with the organizing the boxes into slots on the process flow. It isn't always the same 2, but it only 2 working to pick something up and then the others wait until they comeback. If I want to have all 5 operators organizing the boxes at the same time, would the issue be due to a process flow error or is this because of how long it takes to find the proper slot?

[moehlmann_fe]

It's because in order to be able to unload to a rack, the token needs to acquire it as a resource first. So only one operator can currently unload to a rack at a time. As I said previously, I don't really see this as making much sense, but left it in because there might be a good reason why you build the logic like this.

[mia_mancheski]

I see what you meant now. I had set up the logic like this because I wasn't sure as to where some of the slots were and how to make it where the token can acquire the specific rack besides just connecting the racks to the pass queue. I figured that it wouldn't work because how would the operators know which rack to assign the item to if the logic didn't state which group to assign it to, which is why I grouped all of the racks together. Is there a better way to do this? Should I have just directly connected the queues to the racks in the 3D Model?