Pay attention to flowitem references

A.
- the attached model seems that it is out of control. Since it seems to be a display problem as well I have tryied to reconfigure the Graphics and so on ..
- later I have found that the Wafer flowitem (defined by myself starting from the BasicBox) get a wrong reference, possibly when trying to build the GUI for the same model (I made some copy/paste for this subject and I have observed an "edit32" reference in z cells of the Wafer itemflow that should not be there, while I am sure that "edit32" name appears once in my GUI development tries)
- the result but was a total out of control model while in fact if deleting the Wafer itemflow and "re-defining" starting from Cream_layer by only changing the color everything goes well (it can even be any other itemflow, only the name is important in fact, since the sources are set for generating Wafer)

B.
After correction as described there is one more questions that I will have:
- the second conveyor from the defined line (the selected one) has a rise of -3 for the 3rd section. The flowitems correclty shows for the + 3 rising section but not for the decreasing one. I saw somewhere a reference to a centroid attribute but not able to find any details for that

C.
And the last question (in fact not related with the FlowItems): If one processor is asking for at least one operator (during the process, for start up, or for both) and there is no one available (even no connection exist to a taskexecuter or to a dispatcher) the processor will stil be able to perform its task?

Iulian,

I had a look into your model and I think I figured out a few things.

1.
The problem with the Wafer flowitem is that it has no spatialz node. I do not know how and why but the name is blank and this makes the trouble.
I opened the tree for this item (FlowItemBin/Wafer/Explore Tree) and gave the third node under spatial the name ‘spatialz’.
I know that there are/or at least were issues if an object has a negative z-size. So I guess same if the location is negative z.

That’s the first thing I changed.


2.
At the same flowitem Wafer in the FlowItem Bin I added a node under spatial called ‘centroid’. Just select spatialrz node, press space and you have an empty node. Select the node and call it centroid. Rightclick Insert Add Number data (or press ‘n’) and give it the value 1.

I did this and it works, but the flowitems are not really nice displayed, if they go down the -3 conveyor.

3.
That it looks strange seem to be because of the value 90 in Orient Y of the conveyor. I change this back to 0.
If you want the flowitems with a 90 degree rotation, this is not a really easy task, because the conveyor objects are to clever (they take care of the position, rotation, etc. of the flowitems because of curves, decreasing, etc.).
So I can not just use the Entry and Exit Trigger to set a rotation on the flowitems and switch it back.

But I used the Entry and Exit Trigger to switch the size of the item. This seems to work.
I guess, that is also more the way you like to have it, because then the Spacing Value and Spacing Rule are used in a correct way (xsize).
In my eyes in your model this was not correct. It seems right, because if you compare the conveyors it is 0.2773 m spacing in between in both cases, but this is in my eyes because of the spacing on the downstream conveyor (conveyor in front of the conveyor we speaking about). But maybe I am wrong.

I only made the changes for the first conveyor (Conveyor48). For the other conveyors you have to take care by yourself.

One suggestion I like to give you. I would give the object realizable names and sort them in the tree. This would make it easier to find the objects and to get an understanding of the model.
But maybe this is just the German blood in me and as you know the Germans like to be structured .


4.
I am not sure what your simulation task is and why you have all the employees in your model. So I can not give you any help or hints here.

I guess your question C. you can answer by yourself by just building a small test model for this case.
That’s the way how it should work.
If you define operators to a processor to do the process task, the process gets in the state waiting_for_operator. If no operator comes, he will stay in this state.
But unfortunately you are right. If no operator is connected to the processor the processor will just do the task (processing) and do not care about the operator.

I think this is a bug and the Flexsim Guys should take care of it.
Cliff, I am sure you read this, so can you please do a test and take of it? Thanks in advance.

Okay, Iulian, I hope I was able to give you some hints and help.

Good success
tom the (A)tom

Wow. That's one messed up model. I would suggest going back to a previously saved version that was stable, and starting from that point. Those were pretty substantial problems that Tom found with the model, and even in the tree of Tom's model he fixed for you, I noticed some bogus nodes hanging around. Also, if you open the System Console you will see a lot of exceptions and error messages in it.

On a side note, don't use the normal distribution to define process times if possible (no real processes follow a normal distribution anyways do they?) because it can return negative process times.

A processor not calling an operator even though the "Use Operator" box is checked, is due of course to the fact that you do not have an operator connected to center port 1, and yet the "Pick Operator" field by default tries to find the operator there. The "Pick Operator" field purposefully allows you to return a NULL (0) in the field to indicate to suppress the internal call for an operator. The "Multiple Teams" pickoption of the Pick Operator field takes advantage of this fact, so you might want to check it out. Well, you essentially returned a 0 by not having an operator connected to port 1, and therefore the Processor skipped the internal call for an operator (which in turn puts the current process time on hold) in anticipation that you had planned on calling for operators in your own custom way.

I'm not sure there is much we can do about the problem of someone forgetting to connect up an operator, and leaving the default Pick Operator option selected; but I'll add a request to our future development list to bring it to the attention of others.

Hy Cliff,

Thank you very much for your reply. In the mean time I have continued to study and there is still a lot more for me to study.

The posted model does not have any purpose other than to show something that seems very strange when running and that is due simply only because a missing reference that I was looking for almost two days (anyhow it was my fault because I do not know what I did for loosing that reference). This explains the constant inter-arrival time for the sources. Regarding the operators the connection to processor was not forgoten, but was supposed to appear on a later stage. The expectation was for the processor to not do anything till that moment - this might realy generate random behaviour within a large model.

The advice to use the System Console is a very good point (since I totaly forgot about that) and might be very useful for lot of cases (in spite of not able to signal the presented case). As an idea it might be good for these screens (System Console, Compiler Console) to light up if some errors are registered but it can be handled even as it is.

As I said I am using that model still for learning the basic principles therefore I will address one more question:
- the meaning of the TaskExecuterFlowItems showed by the model is to simulate the changes of the shifts
- once reached at the line, the TaskExecuters are replaced with Operators those being connected to the Dispatcher (inspired from the Function that you have posted - createinstance, connect, etc). The visual & label attributes are copied from task executers to the operators and the task executers are destroyed
- the processors are connected to the dispatcher and nothing is done since no operator exist in first stage
- could the newly generated operators be used by the processors once connected to the dispatcher? I could not achieve this - the new operators are considered only after reset (I presume that something must be done to refresh the task sequence but I could not find yet the correct operations to be done).

Please let me know if you have any spot ideea on this issue otherwise please do not spent the time since anyhow my next objective is to carefully study the tasksequences

Iulian

I can't say definitively off the top of my head on this one either. I would have to investigate and experiment myself as well, so let us know what you find. You're trying some possibly "dangerous" things, so don't be surprised if your model crashes...

To help your investigation, you can always go into the Library tree and take a look "behind the scenes" at the behaviour code of the class objects involved.

You might consider using createcopy() rather than createinstance(). At least you should be aware of the differences.

Hi Joe,

The issue relates to the fact that the model should be reset when making connections between objects. I will try to find something else by hiding / unhiding the objects, open / close ports etc.

Best regards,

Iulian