YuMi's unsynchronized movements + SearchL

jeppe

Hi,

I was in believe that searchL wouldn't work well with my Yumi setup, where both hands do their own thing without synchronization. I did a little experiment in robotstudio with VC and it seems to work fine. So is this just a virtual controllers thing, or would it work with real controller as well? At this moment, I don't have real robot to play with.

I'm looking for solution for two things for both arms, and searchL could be the answer in both:

1) Picking part with vacuum gripper. Moving tool downwards (searching) until signal that tells vacuum is created comes on, and movement can be stopped.

2) Optimizing cycle times on shared areas in robot's workspace. There's areas where both arms can't go same time, and if one arm is in this kind of area, another will move to waiting point, if it needs to get to the area as well. I'd like to terminate this movement and proceed right to the area, if it comes free while moving to the waiting point.

Thanks for help!

YuGo

Hi @jeppe

Why you told that the searchL is not working as expected? The VC simulate almost perfectly the dinamic behavior of a RC.?

Just some tips for searchL and yumi: be sure that the TCP is correctly define and the mass, inertia and center of gravity is properly declare otherwise the stop, path stop or soft stop will be longer.

For the sharing working area probably a solution is to use the worldzone, as describe in the RAPID manual.

I hope that it help.

Regards, U.

jeppe

Why you told that the searchL is not working as expected?

Technical reference manual - RAPID Instructions, Functions and Data types; seachL; Limitations:

"If using SearchL, SearchC or SearchExtJ for one program task and some other move instruction in other program task, it is only possible to use flying search with switch \Sup. Besides that, only possible to do error recovery with TRYNEXT."

because of that, i've made assumption that it shouldn't work, at least with the real robot...

For the sharing working area probably a solution is to use the worldzone

Monitoring shared area isn't the problem. As i said, i'd just like to reduce cycle times by terminating movement if there's no more need to it. But I did some testing, and it seems that using searchL (for terminating ongoing movement to the waiting point if area comes free before reaching it) doesn't make such a big difference. But once the productions increases, these tenths of a second cycle time reductions count more and more

Anyway, thanks for the respond!

-Jeppe

YuGo

Hi @jeppe

Technical reference manual - RAPID Instructions, Functions and Data types; seachL; Limitations:

"If using SearchL, SearchC or SearchExtJ for one program task and some other move instruction in other program task, it is only possible to use flying search with switch \Sup. Besides that, only possible to do error recovery with TRYNEXT."

Thats true, but only when you are doing a total coordinate movement (so you are inside a SyncMoveOn/off block). Otherwise you can use the instruction without any limitations.

Monitoring shared area isn't the problem. As i said, i'd just like to reduce cycle times by terminating movement if there's no more need to it. But I did some testing, and it seems that using searchL (for terminating ongoing movement to the waiting point if area comes free before reaching it) doesn't make such a big difference. But once the productions increases, these tenths of a second cycle time reductions count more and more

Oh, now I understood your point. You can enable/disable an interrupt on the worldzone's signal in order to change the movement while you are reaching the waiting point.

It could decrease the cycle time but is not so easy due to the delay of interrupt (2-30ms) and the stroring of the path.

Regards, U.