Advanced question regarding programming standards

For vision I usually have a base point that is taught in the robot and the vision program just supplies an offset value. That way you can adjust the base point in the teach pendant program.

For vision, the offset will obviously have to come from the vision program, no way around that. But the base point and motion command itself are in the TP program.

Quote from WhyAmIDoingThis

Now our "issue" :

2 mechanical engineers claim that all movement commands should be implemented on the pendant and create program for every single movement , which is

impossible since our vision service is sending position data constantly via pcdk .

Technically all movement commands are being implemented on the teach pendant. The robot is the one that executes the movement you are just updating a PR with new position data.

The robot knows when it can't move to certain positions, and if you have DCS set up correctly it isn't going to run into any other equipment. So the robot isn't going to hurt itself or other equipment in the cell.

So long as it is safe and works well comments about how the code is written seem pretty nitpicky to me.

Also making a program for every single movement sounds super dumb. It would waste processing time if I had to call a different program every time I wanted the robot to move.

Fanuc's standard operational use is in regards to actually using the robot, not programming it. There is nothing in their user's manual that say anything about how you should program something.

It is not industry standard to have the vision program in the pendant. If you use IRVision then it is kind of in the pendant but is pretty much useless without a PC to connect to and program the vision process.

As someone who has written a couple of company robotic programming standards, and implemented many more, I've never seen something like that.

Most customers like having the bulk of their motion path in a single program, separated by process, or part, but a program per motion? That would be a pain in the ass. I imagine it would destroy the motion planner's ability to look ahead. The path would be very jerky.

I would like to read these standards that these mechanical engineers are referencing. Might be good for a laugh.

Heck, I once had a customer (who had a CNC background) who spent an entire day telling me that the only way to prevent the robot from colliding with objects in tight, highly-obstructed spaces was to program everything in Joint. I simply could not get through to him the key differences in the ways CNCs move vs how robots move. And he obviously knew more than me, despite having a grand total of 3-4hrs of pendant time under his belt.

I strongly suspect that this is another case of people who are misunderstanding basic core elements of how robots operate. Possibly they're mistaking "In the pendant" for "TP language" (vs KAREL). Which is a false dichotomy.

I've seen a few vision systems that could be programmed and managed directly from the pendant, with no PC involved, but I don't think any of them are on the market anymore. Just too much hassle for too little payoff. Is their complaint that they can't get the camera's photo/video display up on the pendant? Or is their complaint that they have to have a separate PC for the vision at all?

Fanuc's iRVision system is processed through the robot controller. You can even set everything up from the Teach Pendant, but it is much easier to do from a laptop connected to the controller.

You can also monitor the vision system from the teach pendant as well, but again it is way easier to do from a laptop or PC.

Too much of that nowadays I'm afraid:

- People getting involved in areas outside of their remit (irrespective of background).

- People making comments on how it should be done, when there are no standards.

- People poking holes in a successful solution without being aware of the circumstances.

- People making suggestions to belittle others in order to make them appear more prominent.

When this happens, I just hand everything over, and get them to give me a call when they've stopped measuring dick sizes.

If it's safe and cannot cause injury.

If it's smooth and does not cause collisions.

If it's properly commissioned and debugged.

If it's inline with the customer requirements and meets/exceeds their expectations.

Then Job well done by the team, go and have a few beers and start measuring dick sizes at the bar.