Hi there,
Last week I posted a message in this topic already: viewtopic.php?f=6&t=181. I still have the same problem. I will explain my problem in more detail. In the process I am trying to simulate, walking of operators is very important. Walking of operators is in fact the bottleneck of the system. Due to the nature of the process in practice, operators handle an entire queue first before moving to another server. This exact functionality is what I require in Enterprise Dynamics.
The model attached shows the process (the attachment is an very small element of the total model) without this functionality. As can be seen, operators are walking around and handling operator calls in FIFO order. In the topic already mentioned, labels are used to store the product used to call the operator to be able to free the right operator later on. This causes some problems, when I run the model in the topic, I get the same error as in my case: "OnEvent>No atom currently selected: cs". I suppose this problem is due to the fact that an operator is coupled to a product. Two more disadvantages of this solution is the fact that an operator travels together with the product, where I want the operator to stay at the server. And products which have to be referenced to, actually have already left the server and have to be kept into the model.
Could you give a solution to my problem?
Thank you!
Problem with operators
Problem with operators
- Attachments
-
- TestModel.mod
- (28.8 KiB) Downloaded 249 times
Re: Problem with operators
This attachment shows my attempt described in the previous post causing some problems.
- Attachments
-
- TestModel2.mod
- (32.08 KiB) Downloaded 242 times
Re: Problem with operators
Hi,
See attached for a solution for your problem.
I implemented new code in:
- Entry and exit trigger of the servers.
- Trigger on call and trigger on free of the operators.
The basic idea is:
- Operators get called by the first product of a batch.
- The first product will also "free" the operator using the freeoperators function.
- However the operator it self will not accept any new tasks (by keeping it's input closed, see trigger when freed) as long as it is required at the server.
- When the batch is finished, the server will tell the operator that it may accept new tasks and the server will trigger the team to start a new assignment loop.
If anything is not clear: just let us know!
Regards,
Marlies
PS We will be releasing ED9.0 soon, it will have a redesigned operator that can handle this kind of problems much easier.
See attached for a solution for your problem.
I implemented new code in:
- Entry and exit trigger of the servers.
- Trigger on call and trigger on free of the operators.
The basic idea is:
- Operators get called by the first product of a batch.
- The first product will also "free" the operator using the freeoperators function.
- However the operator it self will not accept any new tasks (by keeping it's input closed, see trigger when freed) as long as it is required at the server.
- When the batch is finished, the server will tell the operator that it may accept new tasks and the server will trigger the team to start a new assignment loop.
If anything is not clear: just let us know!
Regards,
Marlies
PS We will be releasing ED9.0 soon, it will have a redesigned operator that can handle this kind of problems much easier.
- Attachments
-
- TestModel3.mod
- (37.78 KiB) Downloaded 254 times
Re: Problem with operators
Hi Marlies,
Thanks for this excellent and fast response!
I learned a lot about 4DScript through your solution. However, I do not understand everything into detail, but it is clear what is happening.
I am also looking forward to ED9.0, however I think it will be too late to use it for my current project.
Best regards,
Rutger
Thanks for this excellent and fast response!
I learned a lot about 4DScript through your solution. However, I do not understand everything into detail, but it is clear what is happening.
I am also looking forward to ED9.0, however I think it will be too late to use it for my current project.
Best regards,
Rutger