Process flow to create dynamic speed regulation

Question

question

Pierpaolo asked yesterday Felix Möhlmann commented 11 hours ago

Process flow to create dynamic speed regulation

Hi, I need a huge help in creating a process flow which replicate this problem and your help will be super appreciated.

I have made several attempt so far, but none of them has worked properly. I have to replicate a system in which the cobot speed will be dynamically adapted based on the interarrival time and I have to translate it even in the real world through Modbus connection.

In particular, after the token has been created, I should impose a condition based on the interarrival time to set its movetime.

In particular at the moment, in the model I have set this condition, but I don't know how to replicate it in the process flow.

if (interArrivalTime>=45){

current.centerObjects[1].setProperty("MoveTime",30);

}

if (30<=interArrivalTime<45){

current.centerObjects[1].setProperty("MoveTime",20);

}

if (interArrivalTime<30){

current.centerObjects[1].setProperty("MoveTime",10);

}

Attached you can find the model so far.

PC_1610.fsm

Your help is fundamental to me.

Thank you in advance.

Software Version:

FlexSim 24.2.1

process flow dynamic speed regulation

pc-1610.fsm (75.6 KiB)

Answer 1 · 2024-10-17T07:00:49Z

Felix Möhlmann answered 22 hours ago Felix Möhlmann commented 11 hours ago

You could have an Event-Triggered Source react to the "Inter Arrival Time" event of the source. Since that event will update the robots move time, you can read the property at this point and set a Process Flow variable accordingly.

pc-1610_1.fsm

The action settings in your "Cycle 1" and "Cycle 2" variables don't make much sense. Stopping/resuming the input/output of the robots doesn't have any effect. They just react to tasks received from the queues. You'd need to either stop the robot (object.stop()) or close/open/stop/resume the ports of the queues to control the item flow.

pc-1610-1.fsm (79.3 KiB)

· 8

Pierpaolo commented · 20 hours ago

Yes, I got your point and the part about cycle 1 and 2 is there just because I took inspiration from another model, but at this point I'm sure it is wrong.

I saw your proposal and I want to make few questions about.

1) Is something missing or need to be implemented further or you think is complete?

2) In this case, the process flow token will have the same characteristics (as interarrival time and movetime as in the 3D model)?

3)How can I implement the connection to ModBus and in which moment?

4) Is not necessary to have a decide after the interarrival time has been gathered?

I make you this question since I was thinking to an implementation of this type: event triggered source --> then I need a way to assign a label to the interarrival time of the 3D model (can you explain me how to assign a label to the token which correspond exactly to the interarrival time of the correspondant item?)--> then two series of decide to choose which path the token will take (based on the interarrival time threshold)--> then I would need to place the connection to ModBus--> and then all the remaining part.

Can you please help me in solving it completely or almost? I need it too much!

Thank you and sorry for all the question I made.

0 ·

Felix Möhlmann Pierpaolo commented · 18 hours ago

What I demonstrated is a way to keep a Process Flow variable updated with the 'correct' move time depending on the interarrival times generated in the sources, since that seemed to be your main question.

If those variables are set up as Modbus sensor variables, then any change will get send to the server and all clients have access to the uptodate value. I don't see why a Decide would be necessary.

Since I don't have access to hardware you are supposed to use I can hardly help you set up the specifics you need in order to communicate with the robot. I have created a simple example model though (well, technically two). If you run them both in parallel on the same PC one model will act as the server and one as the client.

The server model writes the content of a queue to a holding register. The client model regularly polls this register for changes. It creates and deletes items in a queue to mimic the content in the server model.

I hope this helps you understand how a modbus connection with FlexSim can work.

modbus-example-server-model.fsm

modbus-example-client-model.fsm

0 ·

modbus-example-server-model.fsm (134.8 KiB)

modbus-example-client-model.fsm (110.1 KiB)

Pierpaolo Felix Möhlmann commented · 18 hours ago

Thank you Felix, very helpful. But do you think it is not necessary to add the connection to ModBus as it was present in my first model? (The connection used in the first model is actually correct, like the IP address and the port as well btw)

And how is it possible to send the changing value to the real cobot?

0 ·

Show more comments

question