Search for $PWR_NORMAL (should be the COLD START Autoexec program) or $PWR_SEMI (should be the HOT START Autoexec program) in your system variables.
DS186 Exactly! Those variables.
We have some 2007 vintage robots running v7.x using the Cold Start program.
Look in the System, Config menu to see if you have an option to select a Cold Start file to run when the robot boots up. This file can run in the background by jumping back up to a LBL. You can monitor I/O and might be able to turn that variable off. We use an IF statement then JMP to a LBL to change the I/O desired then JMP back to the main loop.
If you have the HMI (SNPX) option or the ModbusTCP option you can read/write the I/O and registers (R, PR, SR, System Vars) using Modbus TCP. There are some good Python libraries for ModbusTCP. Search the forum for python and HMI
set a Register equal to the PR number, then do an indirect reference to the PR. R[2] would be the counter register and R[1] is the reference register. PR[[2] is set to the value of the PR with the indirect reference.
R[1] = 10 + R[2]
PR[2] = PR[R[1]]
Try exporting as .x_t. I've had success with that.
Nation, are you exporting as .x_t then converting to IGES? I don't see that extension for importing. We use that type of file for NX exports a lot for other applications and it's much better than IGES or STEP. Wasn't sure how you get it into Roboguide.
verify your robots are mastered correctly. I had a similar issue and found one of our techs did not line up the axes on the lines correctly when remastering the robot after a battery failure. It would rotate perfectly around Z after that.
See if you can find something near here. (insert your user name)
C:\Users\<user name>\AppData\Roaming\Robot Neighborhood
This variable is for the general override speed on the pendant. $MCR.$GENOVERRIDE We modify it in background programs or through our HMI's.
Contact Fanuc America and ask for information on QSSR. We had a call with a Fanuc rep but have not used this.
Glad you got it working. Thanks for the information on activating the User Data.
I agree, the robot doesn't know where it is in the cell. You can update an existing robot in a project by clicking on the Serialize Robot button. It will bring up the same window that you use to create a new robot from an AOA backup. This is nice in HandlingPRO when you have other equipment that you don't have to recreate in a new project. This has been a big time saver for my team now that we know about it.
How are you loading the backup into Roboguide? Are you using the Serialize Robot button that is shown when you view the robot properties? I'm assuming that would just update the robot programs, etc. when you load the new backup and not move the actual robot in the cell.
I have 1 scanner defined in the Ethernet/IP list for my camera. The configuration for this device should be in the attached spreadsheet from my earlier post. To trigger the camera, I turn on the Enable DO then pulse the Trigger DO. My results come through the CIO-Micro and a different range of discrete inputs because that is how my vision guy at that time knew how to do it. So I can't help much on getting data back through the EIP inputs. I do use the ONLINE input to verify the camera is ready and I can see the TRIGGER ENABLE input turn ON. If you have the I/O setup as shown in the spreadsheet and you can see the camera ONLINE in the Ethernet/IP window, you should be able to trigger the camera and see some DI's change state. My camera is showing as OFFLINE below because it is from the Roboguide project.
You can modify your tool variable directly in your program. Reference the TRSF for the gripper and adjust as needed. You could enter the values directly or apply an offset, etc.
Direct Entry: tlGripper.trsf={0, 0, 150, 0, 0, 0}
Offset current Tool: tlGripper.trsf={0, 0, 150, 0, 0, 0}*{0,0,nOffset,0,0,0}
Perfect, thank you. I'll contact spare parts.
HawkME, do you have the software part number for the CAD Converter? We currently have 3 server licenses for HandlingPRO and would love to add that option. I emailed spare parts but have not heard back from them.
You can also map the UI/UO to Flags and then use background logic to assign DI/DO to the flags. One nice thing is that Flags can be mapped as an input or an output.
Then F1 (Type) -> Master/cal -> QUICK MASTER press Enter and F4(yes),
You may need to Zero Position Master since the encoder counts were lost when the batteries failed. Seems like The QUICK MASTER option is not working correctly.
In the robot pendant, go to Menu, Setup, Host Comm, HTTP. In the HTTP Setup menu, highlight the A in the KAREL row then press the F3 button for UNLOCK. The A should change to a U. Try clicking on Comment again. I just tried it in Roboguide and it worked. I've done this for several real robots over the years.
Try looking in the SNPX variables to see if there is an address that matches 4322. The example below shows 2 entries in the SNPX settings to send robot variables to the HMI. The 1st has an address of 1201 and the 2nd is address 9101. These "addresses" are robot addresses that external devices can map to to view/edit robot variables. You can look in the Teach pendant for the variable list or view the system.va file in the MD directory in the robot.
[*SYSTEM*]$SNPX_ASG Storage: CMOS Access: RW : ARRAY[80] OF SNPX_ASG_T
Field: $SNPX_ASG[2].$ADDRESS Access: RW: SHORT = 1201
Field: $SNPX_ASG[2].$SIZE Access: RW: SHORT = 1
Field: $SNPX_ASG[2].$VAR_NAME Access: RW: STRING[37] = '$MCR.$GENOVERRIDE@1.1'
Field: $SNPX_ASG[2].$MULTIPLY Access: RW: REAL = 1.000000e+00
Field: $SNPX_ASG[9].$ADDRESS Access: RW: SHORT = 9101
Field: $SNPX_ASG[9].$SIZE Access: RW: SHORT = 40
Field: $SNPX_ASG[9].$VAR_NAME Access: RW: STRING[37] = '$TP_DEFPROG'
Field: $SNPX_ASG[9].$MULTIPLY Access: RW: REAL = 1.000000e+00
