Posts by Nation

Quote from Erik Olsen

2. I/O Power Fail Recovery:

! Recover IO on power failure
! 1 is Not Recover
! 2 is Recover Sim
! 3 is Unsimulate
! 4 is Recover All
SETVAR $PWF_IO

Quote from Erik Olsen

7. Enable UI signals:
8. Start for CONTINUE only:
9. CTOPI for ABORT:

$OPWORK.$UOP_DISABLE
$SHELL_CFG.$CONT_ONLY
$SHELL_CFG.$USE_ABORT

Quote from Erik Olsen

30. Signal to set in AUTO mode:
31. Signal to set in T1 mode:
32. Signal to set in T2 mode:

34. Set if INPUT SIMULATED:
35. Set if OUTPUT SIMULATED:

$CR_AUTO_DO
$CR_T1_DO
$CR_T2_DO

$INPT_SIM_DO
$OUT_SIM_DO

Quote from Erik Olsen

38. Set if Sim. Skip Enabled:
39. Set when prompt displayed:

$SIMWAITOUT
$PRMPDSPOUT

Quote from Erik Olsen

41. Hand Broken:

! Hand broken monitoring. 1 = off
$SCR_GRP[1].$HBK_ENBL

Quote from Erik Olsen

42. Remote/Local setup:

-- REMOTE_TYPE 1 = Remote ; 2 = Local ; 3 = DIN ; 4 = SOP Panel Keyswitch
$REMOTE_CFG.$REMOTE_TYPE
-- REMOTEIOTYP 1 = DIN; 2 = DO; 20 = UI; 21 = UO; 8 = RI; 9 = RO
$REMOTE_CFG.$REMOTEIOTYP
-- RMT_MASTER 0:User Operator Panel 1:CRT/KB 2:Host computer 3:Remote device none
$RMT_MASTER

Quote from Erik Olsen

73. Position reg matrix form:

! Matrix representation in PRs. 1 = off (cart rep).
$PR_CARTREP

You are on the right track with the TCP.

Your TCP in roboguide is off. Your sim should be the 'ideal' of what the cell should be. Fix that first. Update your simulation programs with the new TCP, and then reexport. Then, update your TCP in your real robot to match and check the programs.

If you are using a user frame for your part, verify that as well.

Check mastering as well. Also, check that all hardware holding everything together is tight.

With all that said, there will always be some minute differences from simulation to reality, and touch ups will be required.

Mixed logic will work. Tested this on a V7.7 controller in roboguide:

1:  IF (DI[1] OR DI[2] OR DI[3] OR DI[4] OR DI[5] OR DI[6] OR DI[7] OR DI[8] OR DI[9] OR DI[10]),JMP LBL[1] ;

SSI[5] NTED is the way do to it safely.

I use it pretty much on every project, but I don't think it is the right tool for what you want.

For cells with recipes, we usually pass in the relevant parameters to the robot via group inputs, and make the programs parametric. No need to drop in new programs every time.

The Tool offset utility might work as well.

Save your new TCP into a different UTOOL number, the use the tool offset utility to convert from the old TCP to the new TCP.

Convert type you would want in this scenario would be: TCP Fixed.

If you have program loader (formerly known as ASCII Upload) you can take the program offline, and change the TCP number in the position section to accomplish the same.

This is exactly what program adjust is for. You can find it under the UTILITIES Menu.

You can adjust relative to tool, or user frame.

Once you type in your adjustments, you have to enable them. The utility will then modify the program with your adjustments. If you save your program out, or clear the schedule, the adjustments will be permanent.

Modify the Group Mask in details of the program to use only the arm motion group.

Drop the HOLD uop for a few hundred milliseconds. That will stop the robot, with the option to resume.

Unfortunately no. There is no way (that I know of, in TP, without Karel) to dynamically create a message command.

A paint robot can be used as a pick and place. I would be careful with the load, as their wrists are not meant for anything very large.

Check your setup menus for setting the profibus ID.

For setting the IO, profibus is rack 67, assuming it is a slave. The IO rack list definitions are discussed here.

Since you are running from a PLC, I would map the UOPs to that rack as well.

Did you jumper the int24v and int0v to the ext 24v and ext0v?

I think the robot will post a fuse error if those aren't jumpered (or you fail to supply external 24v).

To be clear, 24v int should be jumpered to 24v ext. And 0v int should be jumpered to 0v ext.

Encoder battery backup. Disconnect them, and you will have to remaster the robot.

I usually only see that for external axis, or on paint robots.

Use the program adjust or program shift utility in the utilities menu.

Here is what I do:

:PR[95:Tools Offs]=LPOS-LPOS ;
:PR[95,3:Tools Offs]=(-100) ;

The above code zeros out PR95, and ensures it is in Cartesian representation (you don't want to do a tool offset in joint rep), and then sets the z component to -100mm. when used in a tool offset motion modified, will cause the robot to move to that point with a -100mm offset in tool Z.

You can setup iRvision in RoboGuide. It is pretty similar as real life, except RoboGuide's lighting is perfect, whereas in reality, you have to consider it. There is a setup procedure in the help menu.

When you get to the calibration stage, in the CAD library, there is a vision calibration grid in there somewhere.

Connections depend on the controller, and/or the camera. Modern Fanucs use a coax cable, or GigE, with both ports on the main board.

Would you be able to post your packaged roboguide cell, or message it to me privately? I could take a look at it.

Quote from Tarnarmour

I THINK but am not sure that this means that any poses defined in a line tracking program that are outside of those boundary planes will cause an error; in other words I think that it's not the part that's bounded per se, but the poses (which are relative to the nominal tracking frame) that the robot moves to that are bounded.

Points more upstream than your upstream boundary will cause the robot to wait until they pass that bound before attempting to move to them. If the robot is on a previous point in the tracking program, the robot will track that point until the next point comes within the bounds. Points beyond the downstream boundary will cause a "tracking destination gone" error if you attempt to move to them.

Quote from Tarnarmour

A MAIN program that activates the specific Tracking Schedule that you're using, waits for the part detection switch (which is hooked up to a specified DI), then gets the current encoder value. I think that you set the current encoder value using the SETTRIG command. Then, MAIN calls the actual line tracking action.

Use that, in combination of the LINECOUNT[...] R[...] command to get the current encoder count to set into the SETTRIG command. Once you execute those to commands, start the tracking program. Roboguide can also trigger a DI once your part appears, so you could use that as well.

Quote from Tarnarmour

HOW CAN I GET THE NOMINAL TRACKING FRAME TO GO TO THE CORRECT SPOT WHEN TEACHING POINTS?

Use the conveyor jog toolbar. You can move the part forward, or backwards, or set it back to the trigger point. Make sure you have the path node visuals on, and you should see the path attach to the tracking frame when taught.

Quote from Tarnarmour

What is the part detection distance measuring from? If it's really just measuring from the conveyor object in Roboguide, how would this work on a real robot without Roboguide?

It is measured from the origin of your tracking frame. Adjusting it shifts the path up or down stream. If possible, I like to keep the tracking frame origin on the trigger sensor, but if you can't reach the sensor, that is what this is for.

Quote from Tarnarmour

It seems like the tracking frame is moved down away from its nominal position when I try to teach points, making it really hard to actually get any points taught accurately.

Conveyor jog toolbar does this.

TOOL_OFFSET is like TOOL_OFFSET, PR[...], except you have to define what PR it is looking at earlier in the program.

Useful if you have a ton of tool offset points in program, and you want to change what PR is doing the tool offsetting.

I personally never use it.

I attached an example of how to create multiple rails in this thread.