Posts by HawkME

The offsets are relative to the vision reference position that you teach in the vision process.

It won't work correctly with CNT, only with FINE. Can you move your P[10] further away and then use DB with Fine? If that isn't an option then the only other way I can think of is to monitor the position in BG logic and turn off the spray signal when it's past a certain positional value.

I'm not aware of any function that will do that for you. You will have to come up with your own algorithm.

You have to program all of the robot motion. Just make a program to go around it.

Can you post your program?

If you are using linear movements then the end of arm will stay vertical to pick up the bottle. I'm guessing you are using joint moves which is causing the problem. Should be all linear moves when picking from this grid of parts.

No. Feedback is for the monitoring system. Relays are typically used due to it being dry contacts.

There is a path optimization function in RoboGuide. It's been awhile so I don't remember the exact menu, but the results it produces are fairly common sense. Use 100% speeds and CNT100 where possible.

Touching up the tool frame is a good first thing to try. Just make sure you take a backup first.

You could create a user frame offset at 45 degrees to make teaching your path simpler.

saberlars that doesn't answer the question. Override % is not the same as command speed.

I'm assuming in this case there should be a register that is setting mm/s for a linear move. Keep in mind that there will be accel and decel time at that start and end of the move where the robot will be significantly slower. Also if you are using CNT then it will blend that speed with the speed of the next move, as well as decelerate around corners. Also, your command could violate a speed limit of the joints of the robot.

The regular M-710 has a very solid wrist. The 50e is an offset wrist. I haven't used that particular variation, but it would obviously be less robust than a solid 2 bearing "shackel" design.

How complicated is your path? If it isn't a crazy 3d shape, then consider writing the program yourself without using CAD to path. Generated code is always much larger than if you write it yourself, and generally messier too.

Are you sure there aren't faint little scribe marks that you missed?

Does the robot and program use a tool frame? If so touching up the tool frame may help.

Otherwise, you could put it in the position you measured to the blade. Record J6 joint position. Jog J6 until it's even on both sides of the blade, then record that position. Subtract to find the difference between the 2 angles and move to that # of degrees from 0. Then you can master J6 at that position to zero it. If you go the wrong way then you would need to go double the amount the opposite direction and remaster again to correct.

It may be an axis speed limit issue. Usually there woul be a warning that appears if that is the case.

Also it is a collaborative robot. It may need to reduce speed when the reach is extended in order to maintain safe force limiting.

Is it approaching a Fine moment? Are you sure it's not the normal decel as it approaches the point?

That would be cool if it is built in now. I'll have to try on a newer robot.

You need Ascii upload or use offline software to compile the ls file to tp.

Will be interesting to see how it rolls out. A language like Python would be very nice for complex calculations or processing arrays of data. Doing that in TP is very slow and ugly. As long as it has good support for online trouble shooting and editing. If it's another black box like Karel then I will be disappointed, but since Python is an interpreted language then there's no reason that it couldn't support online monitor/edit.

Autoexec will run continuously if you add a jump lable.

In system config check if there is an auto exec program selected.