What might be causing a non-update of a task executor's position/kinematics?

Question

question

Michael O'Connell asked Dec 7, '16 Arun Kr commented Dec 11, '16

What might be causing a non-update of a task executor's position/kinematics?

I have a model that has AGVs with kinematic movements created by way points on the AGV Network. When I run the model to a specified stop time, the physical position/orientation of the AGV is incorrect. However, with the model stopped in the incorrect state, if I select any tab or mouse over any entity (path, control point, agv) in the 3D window, the AGV snaps to the correct position. Doesn't seem to work when passing over an item.

I have updatekinematics commands in custom draw triggers on all AGVs.

I'm unable to attach the model, so I'm just hoping that someone might have an idea about a culprit.

Software Version:

FlexSim 16.1.2

agv draw kinematic

· 1

5 |100000

Attachments: Up to 12 attachments (including images) can be used with a maximum of 23.8 MiB each and 47.7 MiB total.

Michael O'Connell commented · Dec 08, 2016 at 04:14 PM

mouseoverupdate.gif

0 ·

mouseoverupdate.gif (108.5 KiB)

Answer 1 · 2016-12-09T18:13:21Z

Joerg Vogel answered Dec 9, '16

If you want that the runspeed hasn't got an negative effect on the visual result of your model you can create an event by sending a delayed message right at the moment the kinematics ends. On this event you update your kinematics a last time. Because of the mixture of 3D model and ProcessFlow I don't know where I would place the sendmessage command. Typically I send this message when the kinematics starts because the return value is the time the kinematics ends. It is then quite easy to assign the result of the kinematics to a double local variable and use this variable in the senddelayedmessage command again.

· 2

5 |100000

Attachments: Up to 12 attachments (including images) can be used with a maximum of 23.8 MiB each and 47.7 MiB total.

Michael O'Connell commented · Dec 09, 2016 at 07:08 PM

So, I could put such a delayed message in the code for the Way Point that drives the kinematic. I'm already capturing the kinematic end time and can just set the delay to equal that. I've specified speed parameters such that the duration is near zero. Maybe that was screwing with the other draws/updates.

I'll give it a try.

0 ·

Michael O'Connell commented · Dec 09, 2016 at 08:12 PM

That did it. Thanks, @Jörg Vogel

0 ·

Answer 2 · 2016-12-08T18:05:38Z

Sam Stubbs answered Dec 8, '16 Arun Kr commented Dec 11, '16

This is actually performing as expected. The OnDraw code only fires at certain times, (based on the run speed etc.) You're getting to a point where the update kinematics hasn't fired, because the OnDraw hasn't updated yet. Just click the 3d view or press the stop button, and it will update the OnDraw code.

· 4

5 |100000

Attachments: Up to 12 attachments (including images) can be used with a maximum of 23.8 MiB each and 47.7 MiB total.

Michael O'Connell commented · Dec 08, 2016 at 06:33 PM

I understand and that would suffice if it was at run's end, but the wrong orientation seems persistent.

For example, the code that does a rotational addkinematic and an update kinematics fires at 1.57 hrs. If I set stop time at 1.65 hr, I get the situation shown in video. If I run to 1.8 hr, the AGV has moved further on its path, but orientation is still incorrect. Running even longer, after the AGV has switched to a perpendicular path, the orientation is still incorrect.

For what it's worth, Run Speed threshold appears to be around 5.

0 ·

Arun Kr Michael O'Connell commented · Dec 09, 2016 at 05:50 AM

Hi @Michael O'Connell,

Please share a conceptual working model.

I thought that, it is not possible to use Kinematics along with the AGV module. Since the navigator is different.

Regards,

Arun KR

1 ·

Michael O'Connell Arun Kr commented · Dec 09, 2016 at 05:42 PM

So, I decimated the real model, but this one still demonstrates the same behavior.

Running with a Run Speed of 500+ to a stop time of 1.6, the part/AGVs end up horizontal on the horizontal path. If you mouse over any entity, the part/AGVs flip to vertical, the correct orientation. Running at same speed to 1.7, the part/AGVS have moved onto the left hand vertical path, but appear horizontal rather than intended vertical. Mousing over doesn't change anything. Repeating with a Run Speed around <=1, behavior at both 1.6 and 1.7 is as intended - vertical on both.

The kinematics come into play with 2 Way Points, one where AGVs transition to horizontal path, and one where they transition to vertical path. In code for those Way Points, a rotational addkinematic adjusts orientation of a holding entitiy on the AGV.

visualflip1.fsm

0 ·

visualflip1.fsm (410.2 KiB)

Show more comments

question