What controller do you have? Based on that would tell me what version touch sense jobs you have.
I can and will look up what specific outputs 394 and 395 are responsible for.
As far as the last line, I would venture to guess that this is a robot and station touch job based on MTF. It means convert local position variable 1 to master tool frame and save it in local position variable 1. AFAIK, master tool frame is the frame generated when you calibrate the robot to the external axis.
Converts it from whatever frame it was in TO master tool frame. None of the other frame types are dynamic except for master tool. Master tool should have Z going through the faceplate of the external axis and X and Y will change direction if you spin the external axis. This is only necessary if you are doing coordinated touch sensing between a robot and an external axis. The non coordinated touch jobs would not have or care about master tool frame.
I went back through a old DX100 system backup with touch sensing and I do not see any lines where it would wait for the searching outputs to be off. What is the name of the search macro you are using?
Ok.
As far as I know, this is not a standard touch job that I have ever seen in the USA. The various branches of Yaskawa do their own thing and have their own "standard" for what they do. Based on your job, it looks like those specific outputs are there just to make sure there isn't an active search taking place on R2 or R3 before R1 begins the search routine.
If you only have one robot, I would say that those lines are unnecessary. However, you may have another job somewhere that could force those outputs on. I would confirm that there is no way the controller can ever turn those outputs on before deleting those wait lines out. These things happen when you butcher jobs from other controllers and configurations to make them work elsewhere. Leftover code is generally a byproduct of the above process.
Good luck and you're welcome!
