globally affect overall speeds with $MCR_GRP[1].$PRGOVERRIDE. It can be set in programs to only affect programmed speed, such as running at 75%, while the General Override is showing 100%. It is 'multiplied' by General Override for each programmed motion, so a $MCR_GRP[1].$PRGOVERRIDE value of 50 would yield half-speed if General Override is 100% or quarter-speed if General Override is set to 50%.
Posts by Jaycephus
-
-
$MCR_GRP.$PRGOVERRIDE is a program-settable override (default to 100) that affects program motion and is 'multiplied' with $MCR.$GENOVERRIDE, so 50 x 100 = half-speed. Useful because Operator can always bump up the general override if that is set programmatically at some point. But with General Override at 100%, $MCR_GRP.$PRGOVERRIDE can be used at a critical point to step down to a lower override, globally affecting overall speeds while General Override is still showing 100%. Operator could still dig in and set this var if they can access vars.
-
$SCR.$coldovrd Name: Cold Start Override
$SCR.$coordovrd Name: Coordinates Override
$SCR.$tpenbleovrd Name: Teach Pendent Enable OverrideThe above only set the default value of the General Override at Cold Start, when switching Coord systems on the Teach Pendant, and enabling the Teach Pendant.
They default to '10', I believe, so when turning on the TP, you see the General Override switch down to 10%.
So, those will not set you back to 100% upon entering AUTO.Flatcurve has the comprehensive answer, except there is another var that can be used to great effect. Doesn't put you in 100% when switching to AUTO either, but it is a way to leave General Override at a fixed 100% while programmatically affecting overall speed override in your programmed motion.
$MCR_GRP[1].$PRGOVERRIDE is a programmable scaling factor for programmed motion override, affects only programs to make them run slower even though the General Override is set to 100%. ($PRGOVERRIDE 100 (default) =100%, full speed) This would be a way to insert an override for a section of code that is less than 100%. The advantage is that the general override can stay at 100%, but when the robot is carrying something massive, you can easily override the General Override without changing it from 100%. So operators can't intervene and bump it back up to 100% without editing code or manually changing this var until a program sets it back. $PRGOVERRIDE is multiplied by General Override and programmed move speeds, so all else being maximum, a $PRGOVERRIDE of 50 will yield effectively 50% speeds.
-
With HandlingTool, you need the optional Constant Path option installed. Seems to me this would be especially needful for welding, but I'm sure it is still an extra option, knowing FANUC. Without the Constant Path feature, Override level changes, among other things will result in different corner paths. One quick way to check if you have it and it's enabled is to look for $GROUP[1].$cnstnt_path var set to TRUE. Not sure if this var exists even when the option isn't installed.
-
Dave, that gets filled in automatically when the connection is made successfully. It is a read-only field in the Robot when it is the adapter.
When setting up a scanner to adapter connection between two robots, you only put in the adapter IP number on the scanner side. If all settings are correct, and the adapter responds, the scanner's IP number will then appear in the Adapter robot, and the connection will then display as 'running'.
So, the adapters are not given the IP number of the scanner. I know that much to be true, anyway.
-
ASCII option has been around for a while. I have no idea why it's not standard, but that's FANUC for you.
It's ~$500 list, I believe. Relatively cheap in FANUC option terms, but insane in the real-world, given the functionality included in competitors. It is a compiler, though, but pretty basic and very minimalistic.
It doesn't matter how you transfer the file into the robot, you need the ASCII option to translate the .LS to a teach pendant program at transfer-time. So putting them on a card and moving them into memory won't do anything without the ASCII option. Obviously, there is the offline method of converting, but then you are loading the pre-compiled file, not a .LS file.
There used to be a 30-day license with a new installation of Roboguide. Not sure if that still exists given the way Fanuc is clamping down on things to claw at every penny. If so, for an emergency, you could install it on a fresh computer and use it for a month, maybe.
-
(Edited, previously had run the mastering procedure wrong, but I still have a slight issue.)
I have a Fanuc R-30ib R-2000 that was briefly used by a customer before they went out of business and we bought it back cheap. It was still mastered with the factory numbers, and now seems to be properly mastered again, except that there is something weird about Joint 6.
After re-mastering (after a complete software installation with updates and upgrades), using the factory numbers, all axes line up except J6. It's like the zero witness-mark sticker got moved, but it didn't, since it is right in the middle of the machined flat on the tool plate. The other one is in its normal place on the bottom of Joint 5. So it has the appearance of the tool plate having 'slipped', or having been pulled off and put back on in a rotated position.
It is like it is still perfectly mastered, but the tool-plate has been shifted on Joint 6 by about 1 degree. What could have happened that my J6 witness marks don't line up anymore? All other witness marks are perfectly aligned after this process when the robot is at 0,0,0,0,0,0.
Maybe that joint had been messed with in some way while it was briefly out of our possession?
The procedure I used was where you put in all the factory numbers to both Master Count and Ref Count, make sure the robot is on its witness marks, and then do a Quick Master and Calibrate. All the Master Counts after this match the original perfectly after this, except for J6 which is significantly different. So I assume something physical must have happened to this axis, and thus I should single-axis master this to the witness mark if that little offset bothers me?
-
I know that Fanuc does this to keep information out of the hands of non-integrators, and competitors. They may believe that disseminating this info hurts their bottom line, but that is stupidly wrong. But they aren't unique in that error. Nintendo also takes this approach with YouTube videos of any and all Nintendo game-play. Just trying to show how fun a Nintendo game is with a YT video will get you a copy-right flag. Doing a positive review of the game? Copy-right infringement. Well, not 'legally' in the US, due to fair-use laws, but via YouTube rules, the claim can be made by Nintendo, and it only takes a few of these flags to get your channel taken down by YT. So Fanuc is hardly unique in going overboard to the obvious detriment of their own product.
Here is the license agreement on the Fanuc integrator and customer site (CRC) when you go to the eDocs section:
QuoteIn consideration for access to FANUC America's product information, I acknowledge and agree to comply with any and all local, state, federal, provincial, territory or commonwealth laws, rules, regulations, orders, conventions, ordinances and standards of the country(ies) of origin and destination that relate to importation, exportation and licensing or that relate to intellectual property rights, including trade secrets, patents, trademarks and copyrights of FANUC America; to treat all such products as the confidential and proprietary property of FANUC America; and further acknowledge that dissemination to third parties is strictly prohibited by FANUC America.
I'm not sure, but that could be read in such a way that stuff I read in these manuals cannot be spoken of or written about on these forums.
Not that the manuals are all that good. It's not that their wrong, but critical information might be in the Software Installation manual, which you never thought to read, since you are trying to use Handling Tool, not install software. And you have to save them off so that you can properly search them (or do an "open in new tab" to break the pdf out of its frame so that browser search will work on the pdf itself. BUT a large manual can be broken up into more than 10 or 20 PDFs, so a global search requires you to go through them all, or save them off and weld them back into one manual. Fanuc's global search works sometimes, maybe, and definitely fails sometimes.)
Anyway, I've felt like a wizard who's amassed a lot of Secret Knowledge for a couple of decades now, due to the difficulty or impossibility of finding the answer to something critical in a robot manufacturer's shipped paper manuals, and due to, in Fanuc's case (and Adept's in my past experience), to how needle-like the critical piece of information is in Fanuc's huge collection of individual PDF hay-stacks, and also due to the lock-down of information even though we live in the internet age. (I just had the experience of looking through the actual robot system variables, not finding a particular var listed in the manual of system variables (common occurrence), and also not finding that var in a google search.)
-
You guys know that Fanuc Robotics keeps records of all robots based on F-number, right? It's free and fairly fast to request the original mastering data from Japan via the Fanuc website. Maybe you have to be an integrator to get the special treatment or something, but it worked for me.
It's not always useful to have the factory mastering, but as long as the robot's never had a motor taken off or a gear-box replaced, losing the original mechanical relationship between the motor-encoder and the robot axis itself, then the factory mastering data 'can' still good. Exceptions are if it's ever lost battery power and then been jogged somehow and zero-point mastered.