User/Tool Frames

[cobenson]

I have a customer that continues to change the tool frame number and also takes out the hard code I have in the beginning of the program to set the UTOOL_NUM=1.
   I was wondering if there is a variable to set that will keep the tool frame and user frame the same all the time. We only use 1 of each, ever, so there would be no need to change it.

Thanks All,
Corey

[Fabian Munoz]

Switch the key to AUTO and break it in front of him.

Then say   Oooops, sorry 

Seriously, This is not the best solution but why dont you put the uframe value on a  R variable and then check it at the beggining of the program against the proper value
.
Now you customer would have to change the check loop in the program and the value of R.

Now, if he keep doing it, that's fine, just keep charging him for the service call $$$$$$$

[cobenson]

Somar,
    I did think about breaking the key off as well, but not sure my boss would like that too much.  lol

The register is a good idea as well. But that still gives them an easy way to change it as well. But now they would have a harder time anyways.

Your are right, we just keep collecting their $$$$$$$$$$$ and they are happy to pay it. 

[anonymous]

Since the result of your end user's changes isn't mentioned, it's hard to be more specific here. I would expect to see uframe and utool mismatch alarms. It depends on the robot set up.

However, a potential solution may be to define all the frames the same. That is, set the X, Y, Z, W, P, and R values the same for all the tool frames available. That way, changing the tool frame number would not alter the tool path. The same scheme goes with the user frames.

You might find another partial solution through investigation of the following system variables in a System Software Manual:

$SCR.$MAXNUMUTOOL -- Maximum tool frames

$SCR.$MAXNUMUFRAM -- Maximum user frames

Of course, it would be prudent to make an "All of above" and "Image" backup of the controller before modifying these variables in the event of software "breakage."

What about the Password Protection option?

[Routerguy]

I would just passwork protect the programming level that is the sensible easy solution.

[cobenson]

I would just passwork protect the programming level that is the sensible easy solution.

The customer does not want passwords in any of their robots.

[freemanleon]

I think there is another way but the process is a little complicated. Write down the details of frames and tools in PRs, re-value the PRs to frames/tools in Home macro.Therefore in every cycle these frames and tools will be restored. Set the Home macro and other related programms to Write Protection On. AND FINALLY, Control Start to change the variable $MACROTABLE[1].$sys_lev_msk to 7(maybe) or higher. Then nobody can change these macros expect knowing this variable.
This method is some kind of ....sinister however