topic Re: What might be causing a non-update of a task executor's position/kinematics? in FlexSim Forum

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

michael_oconnell — Wed, 07 Dec 2016 21:39:30 GMT

[ FlexSim 16.1.2 ]

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.

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

michael_oconnell — Thu, 08 Dec 2016 16:14:36 GMT

mouseoverupdate.gif

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

sam_stubbsYXX86 — Thu, 08 Dec 2016 18:05:38 GMT

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.

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

michael_oconnell — Thu, 08 Dec 2016 18:33:07 GMT

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.

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

arunTTT2P — Fri, 09 Dec 2016 05:50:14 GMT

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

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

michael_oconnell — Fri, 09 Dec 2016 17:42:26 GMT

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

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

joerg_vogel_HsH — Fri, 09 Dec 2016 18:13:21 GMT

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.

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

michael_oconnell — Fri, 09 Dec 2016 19:08:02 GMT

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.

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

michael_oconnell — Fri, 09 Dec 2016 20:12:41 GMT

That did it. Thanks, @Jörg Vogel

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

arunTTT2P — Sun, 11 Dec 2016 03:53:47 GMT

Thanks