question about processor

hi, everyone.
I have some question about processor.
I want the process time can change by the number of operators, for example, the model include six object, source, sink, processor and three operators. The processor should operate by operator(one or more), and process time change by the number of operators. when one operator is connected to the processor, process time is 60, and two operators are connected to the processor, process time is 40.

can anyone tell me how to do this?

thanks a lot.

I understand your problem. Got a question about this. When do you want to decide how many operators are involved!?
Should they wait on each other? Will processtime change, when one operator arrives later?

operators don't need to wait for each other, and operator's number will set up on the beginning.

when processor is processing, other operators are assigned to the processor, processtime should be changed after other operators arrive.

---------------------------------------------------------------------------

I have another question for Visual tools.
can I use visual tool to pack a dispatcher and several operators ?
I try, but I failed......

just like this picture
http://i.imgur.com/MCAO1.jpg

For your first question you only have to go sure, all operators arrive at same time. You even will need some logic how many operators are needed, if this is dynamic. Than set processing time by the number of used operators you located.

Your second question: The problem apears because you connected processor and Visual tool via centerport. Just connect processor and dispatcher directly via centerport;-)

Yes - let's talk about if operators show up at a later time -

What I'd like to know is - where can I query the remaining processing time instead of using labels or other to calculate? - how does a processor keep track?

Use getitemvar() to find the item's stored fixed resource information for the processor. From the command help:

For example, a Processor uses variable 1 on the item to store the time the item started its processing time, and variable 2 to store the item's processing time.

So getitemvar(item,1) is the (effective) process start time, and getitemvar(item,2) is the process time. The sum of both is the expected process finish time.

(P.S. - this weekend I may try and put together a processor example , with multiple operators that both arrive late and leave early - unless someone beats me to it...)

@Jason

Thanks for pointing me in the direction of the flowitems var#s. Looks pretty straightforward so long as there is no interruption during the operator's utilization. However what I now cannot figure is what happens when an operator is taken away from the process mid process or a breakdown / scheduled downtime occurs. The var #'s don't seem to offer enough info to show how much time has been processed and what remains when the operator returns or another operator shows up to finish processing the item?

Also noticed that when using a multiprocessor the flowitem var#s do not function the same as a regular processor (?)

Thx much,
Ryan

When the processor resumes (after a stop, or waiting for operators) the start time on the item should refer to the new 'effective' value.

This doesn't solve the problem where the process time is dependant on the number of operators that have arrived though, which I don't think is possible using standard operator requests and the standard processor objects.

For input I'd use a table which has the time for a given number of operators, but then I expect a fair amount of customization of the object.
Numops TotalProcessDuration
1 ...........40
2 ...........16
3 ...........12
4 ............9

or even:

1 ........... -1 or 0 to indicate it's impossible
2 ...........40
3 ...........16
4 ...........12
5 ............9


P.S. This bulletin board still lacks may text formatting options. Anyone know how to enter a table?

Hello Ryan,

the hole simulation depends on its events and the the processfinish is an event too. By using the function delayeventsofobject you can change the processfinish time. Time values can be positiv or negativ.

Maybe that is another way.

Jörg

Jorg / Jason

Guys thanks for the replies on this. I have attached a simple model I put together using the var1 and var2 node info from the flowitem to show how the process time (red processor) calculates. Most info on where / how the visual tools are doing the calcs is listed in the textnode GUI of each. That said what I am hoping to understand better is - when the operator gets called away from the red processor to the green let's pretend that at the green colored processor the operators task was to drink a redbull energy drink. Now he is done doing so and will be returning to the red processor to finish the remaining time. How can I use the delayeventsofobject command or another way to alter that remaining process time to be faster based on his new found energy level?

Ryan

Hi Ryan,

I haven't tested much. So far as I know the delay of events works well on the processfinish event. Therefore the function should be called at the last activity on the red processor. I tested that with a senddelayedmessage command in the Queue Strategy of the operator and a delay time of 10 seconds. The command delayeventsofobject is executed OnMessage in the Operator.

It is just a simple start.

Jörg

This is as far as I got using a basicFR to detect the operators coming and going and using the standard requestoperators() call. The table it uses to figure out the process time/ duration is the label table which describes duration based on the number of operators. The code looks at the optimal allocation and figures out ideal work content and inefficiencies of other allocations based on that.

I destroy and reschedule the process finish event instead of working out the appropriate delay, since it's easy to calculate the remaining processing time based on how many operators are working. I changed the object so that process finish calls the message trigger - similar to the way the 'default suggested' triggers fire on the BasicFR.

There's a problem with the number of operators the logic thinks it has (stop/resume code) - probably something to do with a job missed when clearing out the task sequences for the previous item, but I'm out of time. Maybe next weekend.

Have fun!

Surprised no-one posted the fix this week - it was pretty straight forward. Here's an updated version that overrides the default state change of the object and has the fix so that all the outstanding jobs get cleared when the item is finished.

Just keep in mind this is non-standard, and a proof of concept using workaround methods (dirty tricks!). By all means test it and see if it works for you, and if you get problems post back here and we may be able to help.

Waiting for IT to update my version to 5.1.2 so I can review your models. Thanks for posting them.