Adjust your boundary so it compensates for the size of the EOAT.
DCS is another option but you have to make your own handshake logic or IIC for more features.
Adjust your boundary so it compensates for the size of the EOAT.
DCS is another option but you have to make your own handshake logic or IIC for more features.
Excellent summary Skyfire.
I'd like to add one correction. BGLogic doesn't need wait statements and in fact doesn't allow them. It will manage just fine and won't hog resources. It is non-blocking, just like a PLC program.
I think you may be thinking of autoexecute programs?
Fanuc has a specific input for this called "Hand Broken". It is a pin on the EE connector on the shoulder of the robot. In the manual it is labeled xhbk.
Or you can use any regular RI or DI and program your own stop logic in BGLogic.
I'm not a fan of those types of organization systems. Eventually they get out of order and become more confusing that helpful. Instead, I recommend naming a "Main" program, then just name everything else words that describe what it does. For example:
MAIN
PICK_PART
PLACE_PART
TOOL_CHANGE_MAIN
TOOL_CHANGE_PICK
TOOL_CHANGE_PLACE
WELD_XXX
WELD_YYY
The robot should very easily reach that speed, something must be incorrect in your setup or how you are viewing the results.
Check the system variable for program override.
Also, try changing all move to Fine moves just for a comparison.
What is your override percent and program override set to?
How long is your motion segment?
It is reliable while running a program. It will change as the robot accelerates.
There will be a small lag when passing it to your external device (3d printer control) which is what the paid Speed Output option corrects. It allows you to adjust the lag time in milliseconds and then outputs the predicted speed.
Without the option you will see some delayed reaction when accel/decel occurs but it may or may not be acceptable in your situation.
To monitor current TCP speed:
Set $SCR_GRP[1].$M_DST_ENB to true
and monitor $SCR_GRP[1].$MCH_SPD.
Note, this variable only updates while running a program, not while jogging.
If you purchase the Speed output option you get an even better speed signal that is predictive of the motion planner instead of reactive.
Unless your PLC logic is turning off this signal, You are loosing Ethernet comm from the PLC to the robot.
Try adding an a "short circuit" branch to that output so you can prove you are never turning it off with your PLC logic.
Then check for loose or damaged Ethernet cables and switches from the PLC to the robot controller.
Unfortunately you can't uninstall options. Take an image backup, then you must request and pay for a reburn software set from Fanuc.
Always take an image backup before installing any new options. That is the only way to roll it back.
Post a screen shot of the actual memory values on the TP.
You can't just choose the optional 180/-180 in the menu, you have to purchase the robot mechanically with that option. The question on the TP screen is to confirm which mechanical option you already purchased. Change it back to 170/-170 before you damage the robot.
basically buy the robot and work out a way to mount it on something like a forklift with everything on that. Does this sound doable to you?
Sounds like some Willy Wonka sh*t.
There is a UO signal for battery alarm. Just use that.
15mm/s is the same in T1 and auto if you are running at 100% override.
Anything 250 or less is the same. Anything over 250 will be reduced to 250 in T1.
Perform troubleshooting by LEDs as shown in the manual.
When it fails there will be an alarm in the alarm log that tells you what line of code it failed on. Can you post the ASCII code that you are trying to compile?
If you are using an AB PLC (compact or control logix) then you can directly control the motion using your PLC and kinetix servo drives. You would program it all in ladder logic using motion instructions.