During TrackObejct FrameID becomes invalid leading to error -1067450322

Ask Questions Mechatronics & Motion
1

Greetings,

We are currently in the testing phase of our machine, which consists of two Delta D4 robots and two TrackingPaths: one for PICK and one for PLACE. The frames of the PLACE TrackingPath are created and deleted dynamically depending on machine conditions.

A handshake is implemented with the robots so that the frames can only be deleted when no robot is executing a TrackObject(). This is handled in the code such that, when the execution reaches the TrackObject() command, a flag is sent to the PLC via the variable InTrackingPlace.

However, there are occasions when the handshake fails due to the speed of the process and decision-making, and we end up deleting a frame while the robot is already executing TrackObject(). In the process, TrackingFrameSelect() is executed, which returns a Frame ID. If, at the moment the robot executes TrackObject(), this Frame ID becomes invalid, it will cause a fault with error number -1067450322, ultimately leading to a stop.

Is there any way that, when this happens, instead of returning an error, I can manage the situation and program a fallback reaction?

Thanks

2

Hi Frederico,

may I ask what version of mappMotion you are using and also how you are handling the selection of TrackingFrames?
Are you doing the inline (inside of STMotion) selection or frame selection on the PLC side and synchronizing selected frames to STMotion?

There have been similar reports and under certain conditions a tracking frames was deleted while actively being used or at least already selected. The next mappMotion version 6.8.0 will have a fix for that but it’s not yet officially available.

Please let me know your version and implementation details first and we go from there. It could also be unrelated or a different way of deleting frames solves the problem.

3

Hi,

The versions are:
AS: 6.5.2.12
mappMotion 6.6.1

image
image915Ă—724 35.1 KB

Regarding the TrackingPath for PICK:

The frames are created in the PLC, and their selection is done in STMotion (G-code) using the TrackingFrameSelection() function.

I do not manually delete these frames. Either the robot selects the frames, or they are automatically deleted after the conveyor has moved a certain distance. I have experienced the situation you mentioned only occasionally, and I believe it is related to the behavior you described.

However, my main issue is with the TrackingPath for PLACE.

For PLACE, both the creation and deletion of frames are handled in the PLC. The frame selection is performed only in STMotion (G-code) using the TrackingFrameSelection() function.

Frames are created based on the machine conditions, and they are intentionally deleted when those conditions change. For example, if certain place positions become occupied, I delete the remaining frames for those positions, change the machine state, and then create new frames corresponding to the newly available spots.

Because of this dynamic behavior, I need a way to properly handle the case where the robot attempts to track a frame that has already been deleted.

E.G. if the frame is invalid do TrackStop() to a wait positon in MCS, and do a WaitUntilSync() with TrackingFrameSelection() to get a new frame once created.

This would allow the application to recover safely once new frames become available.

Let me know if you need more info.

Thanks.

4

Frederico, thanks for the additional information it paints a better picture!

Just some clarification, you are saying STMotion(G-code), those are two separate languages for robot motion. Since you are using the inline function TrackingFrameSelection which is only avalable for STMotion you are not not using GCode.

Are you by any chance using the TrackingFrameIsAvailable() before calling TrackObject() as an additional safety net? There is a list of additional functions you may be able to utilize to protect from deleting an already selected frame.

Maybe you can mark your place frames with some attribute at the time of creation that prevents them from being selected unless you change the attribute from the PLC.

I’ll think about this a bit more and talk to some folks who may have a better idea.

5

Hello,

Sorry—when I say GCode, I’m referring to the robot program.

Yes, I do use TrackingFrameIsAvailable(). However, I’m going to run a test now by slightly changing the logic, adding one more conditional before calling TrackObject.

What I assume is happening is that, since the interpreter is always looking ahead, it may already read the TrackObject during that look‑ahead, and when the line of code actually reaches execution, the frame may already have been deleted. To mitigate this, I use WaitALAP() to delay the interpreter as much as possible. But I’m not sure yet whether it is effective.

In this new mappMotion update, will there be an option for handling/fallback if the TrackObject command fails due to an invalid Frame ID?
I’ll read about the attribute masks you sent to better understand them.

Thanks.

6

Robot2_Bulk.zip (3.4 KB)

Today I refactored my logic by implementing more checkpoints using TrackingFrameIsAvailable() and by creating a new machine‑to‑robot handshake. It’s worth noting that the handshake is PathSynchronous, so, as I understand it, it is interpreted during the path…

The failure always occurs—and only occurs—at TrackObject(). STMotion stops on this line with invalid Frame ID errors. The behavior has improved, but there are still situations where STMotion understands that it can execute TrackObject(), while the machine has already deleted the PLACE frames. It is very much a matter of timing—when the conditions line up, TrackObject() ends up synchronizing to a non‑existent / invalid frame.

image
image2312Ă—220 29.8 KB

In my process, I try to seamlessly connect the PICK movement to the PLACE movement. This makes the motion more fluid and avoids unnecessary stops. I’ve attached my logic here in case you’d like to review anything. It’s possible that I’m using something incorrectly.

Just one note: some StateMachines are disabled because we haven’t implemented additional functions yet, so you will see a higher number of states.

I still believe that if there were an option where, if TrackObject() returned an error, we could handle a reaction at runtime, it would be an excellent solution.

We would very much like to work around this issue by chaining the movements—but if we cannot find a solution, it will then be necessary to add an intermediate stop to prevent this problem. Which is not our first choice.

I hope this information helps to better understand our problem.

Regarding the mappMotion update you mentioned, will there be anything related to this?

Thank you very much!!

7

Hi @marcel.voigt and @Frederico_Mantovani where we are in your discussion? do we have good idea as a solution?

8

Closed by moderator. Please @Frederico_Mantovani update us with your solution; you can also continue the discussion there if needed.

9

Hello Jaroslav,

Unfortunately, there is no way to implement a reaction to prevent the error when a frame is deleted. Every time a frame is deleted while the TrackObject() is already synchronized, it will lead to a failure in the STMotion program.

Since the place positions in my project involve intermittent movements, I wait for the motion to complete before moving to the place position. Therefore, I am no longer using the TrackingPath in the PLACE operation.

However, I believe it is extremely important to evaluate with the R&D team whether it would be possible to develop a fallback reaction function in case a frame is deleted while TrackObject() is running. For example, allowing us to implement logic that, if the frame is deleted, the system transitions to a safe or standby position.

Thank you.

10

@gabriel.costa @gomesm Could you review the case with R&D?

Thanks
Ciao
Valerio