Posts by HawkME

Search for the Troubleshooting by LED in the controller manual.

When you do the auto grid frame set, you can specify the UT # for the camera and it will set that too.

A slightly better hacky method would be to scrape the IO status html. If you browse the robot web server you will find it.

Otherwise you need to purchase a legit communication protocol option.

We are not allowed to post Fanuc manuals on the forum.

Please show screenshots of your vision setup and TP program.

You could test using the Run command in place of the macro and see how it responds to fault, hold, reset, resume via start signal.

Another possible option is to purchase and install the multi-uop option. It allows you to UOP start different groups with different sets of UOP signals. It is a bit of a PITA to setup so I'd only use it if really necessary.

You could try calling it as a normal program from your main program. Then it will behave as a normal program with the ability to pause/resume.

That's what I usually do to get rid of macros.

Don't confuse BG with macro, as they are 2 specifically different things.

I generally dislike using macros unless absolutely necessary.

Can you post the code inside the macro? Maybe there is another solution and seeing the code will help us to determine that.

There are multiple software bugs on Fanuc when going beyond UT 10. If you really need more then Sergei Troizky solution is a good work around.

Pick a UT that won't be fixed, but instead you will change programmatically. For example UT[9].

Then for any extra UT you need, store them in PRs instead. Then whenever needed you can write them back into UT[9].

If it is just for machine safety not human safety then you could use a combination of DCS and BG logic.

DCS could be a less restrictive sized cube, maybe with the corners knocked out by DCS out zones.

Then you could use BG logic to monitor the sum of squares of the current position and ensure it is below a certain limit or trigger a hold or stop signal.

Probably a bug in the complier that Fanuc overlooked.

Usually when move to doesn't work it means you have the robot in a position or orientation that it can't do a straight line move to. Either it would cause the robot to move through itself or flip the wrist through itself. Solution is to jog the robot closer to the position and orientation first.

Have them create a small program. It will be obvious if they can do it or not.

You can start tapering down a little toward the end but I think a little excess may be unavoidable.

You changed your config from NUT to NDB. So I'm guessing your telling the robot to do a back flip.

Then easiest would be to have the PLC monitor the signal and turn on the pause signal when needed.

It can work in BG Logic if you are controlling the UI signals from there (indirectly with flags).

Normally I use the PLC to control the UI signals. If you don't have a PLC then BG logic can act like a mini PLC. Also you can have multiple sections of logic in a single BG Logic program.

Merry Christmas!

In the past I have either used the skip function to monitor the gripper or use a PLC to monitor the signal and stop the robot. It is possible to do with BG logic or condition handlers as well.

Depends on what we are talking about by continuous running loop. If the robot is continuously moving and doing stuff, that's great. I just don't like having a continuous running loop to check for a start signal. A Wait instruction that waits on the signal instead of time achieves the same thing and you can see which line of code it is waiting on instead of a constant blur.

There is really no reason to have a continuous running TP program on a robot. That isn't how they are intended to run and makes troubleshooting difficult. Use a wait instruction to wait on a start signal. The start signal can come from a PLC or the robots own BG Logic.