Posts by Nation

For really accurate placement, Roboguide has a calibration feature for objects/fixtures. With it, you teach a set of points on the cad in roboguide, export the program, teach the same points on the real robot, and then reimport. Roboguide then moves the fixture (or the robot, depending on choice) to match what was taught. One go around gets you within a couple of mm, and a couple of go arounds gets you within a mm typically.

Not fully. That file just contains your SafeIO mapping and configuration.

Usually you have to call up tech support or your sales guy and get them to email it to you.

That will remove all files, and IO configs, and everything else.

My method would be to connect to the virtual robot via ftp and remove the files that way. Another way would be to use a .cm file, described in the sticky.

The latest version of roboguide can generate predicted DCS stop volumes. That would be one way.

The problem is that you have two devices writing to the same address (the slave IO and Kepware). The slave writes every 8ms, while kepware writes every second or so.

You need to remap your UI to something that won't be written to by another device. Try mapping it to the internal registers, the flags, or to the memport.

Also, you are not supposed to write to UO. Those are status bits from the robot. If you write to them, the robot will just overwrite whatever you wrote. Only read UOs.

Quote from kotam

Pushing my luck: We have a document "B-82725EN-2/06" that shows the connections to the EE. The diagram shows a PNP transistor on the EE end with 24v, R01, and Load legs. Can someone tell me if this is in the EE unit or it should be added outside the robot circuitry. Per above, tech attempted to install transistor into the circuit and possibly reversed the 24v and R01 on the transistor, ?possibly sending the load voltage back into the R01 pin?

The transistor in internal to the robot and does not need to be wired. On the diagram you should see a box that states "mechanical unit". Anything in that box is internal to the robot and does not need to be wired.

Sounds like you will have to separate the trigger into a separate task, or into a background task. In that task you would remember the count when the trigger switch was hit, then use that count in your PNS program when you start your tracking.

Reduce your search space. Is your geometric pattern match searching for stuff on the part that don't matter (shadows, etc)? Is the allowable contrast set really low? Is your max pixel deviation set really high?

Because in your first shot IRVision is running through more of its search parameter space to find the part (angle, size, contrast, etc), then it moves above the part and it doesn't have to search as deep (angle is now near zero, contrast is close to taught, size is close to taught, etc).

Contrary to most programs, Roboguide's help file is very extensive. Check it out for positioner setup. Also, if you haven't, install the example workcells. There might be one setup in them.

The robot monitors the torque required (or more accurately, the current draw of the two servos) to move between those two points, and from there, back calculates the payload's mass, CoGs, and inertias.

I found a paper on it if you would like to dive more in depth: https://hal.archives-ouvertes.fr/hal-00362677/document

I wrote a program a while ago that will rotate a program around its own userframe in Z in TP. Check out the thread here.

HawkME in that thread also goes over how to do it with the matrix function from the vision support tools option.

Do you want to rotate the whole program around the user frame's axes, or do you want to rotate each point around each point's axes?

As far as program adjust limits, those are all handled in the $PRGADJ system variable.

In TP, as far as I know, there is no way to test if a program exists before calling it. You could do it in Karel fairly easily though.

Do what Racermike said, but instead of restoring the robot from the backup, click on the modify existing robot radio button.

I think the robot will ignore those parameters unless you have the basic hmi option installed.

I recommend osfmount in order to mount the image.

First, go to MENU -> SETUP -> ERROR TABLE.

Then under FCode, type 11 for SRVO, under ECode type 171, and then under Sever, change it from DEFAULT to STOP.

As far as I know, no.

As a work around, you could increase the severity of the SRVO-171 fault via the Error table, and have the robot pause when that fault is issued. Whatever line the robot stops on would be the line number. This solution depends on you being able to stop the robot/line though.

Another option would be to run the program through in roboguide and look at the task profile. It logs faults on motion lines.