No normally while its updating you can't navigate the menus. I've had a few fail but i can normally do it again and it works. I have had to re-download the auto-update again onto a different USB but its always worked one way or another.
Posts by c3ture
-
-
All the V8.30 robots I've dealt with have had it but I think the oldest is V8.30P/21, I don't remember for sure. Did see a tech note that its been added to other version of V8, V8.10P/28 and later has it now for example. Just an FYI on the auto update, going above V8.30P/29 can take a long time, like several hours to do it. It also creates an issue with a welding robot because it enables AI4 (feed motor current on a Lincoln Welder, not sure about others). It turns it on but doesn't set it up and map it, you have to do that.
-
Using UT1 with a password USB is only available on v8.30 and higher on the R30ib controller.
-
Would this happen to be an operator interfaced robot or one that gets e-stopped or fenced alot? I've seen an issue that causes idle cpu percentage to decrease over time when a robot is e-stopped or fenced a lot. It will start getting abc overrun faults and collision detects in mid air. Normally a cold start and reloading of the program will make it go away for a little while until the cpu percentage gets low enough again to cause the issue again.
-
I’ve seen this done before but it wasn’t really disabling the ipendant. It was using the Plc and robot DIs to log into the robots internal password protection system instead of using passwords or USB on the pendant itself. It was done using Karel and some of Fanucs hidden password variables.
-
It’s a subscription based monitoring device that Fanuc offers. Cost is based on number of robots up to 100 and after 100 it’s the same as 100. It’s avalible for R30ia v7.7p/51 and up and R30ib v8.3p/24 to 32 as an option with a pac code and 8.3p/32 and up as a free option. I do know that’s it’s able to be added to older V8 robots as a custo but it has limited functionality on those. Depending on what version of software and robot model you have it can do different things such as low pulse coder battery, pulse coder noise, RV health monitoring, motor health monitoring, TP and variable change logging, estop severity logging, etc. There is some addition options spot and paint robots as well. It works by uploading data from the robot to a local collector which in turn sends data to a Fanuc server that runs some analysis on the data and when it finds something wrong it sends it to you and someone at CRC. Depending on how you have it set up it can go as far as CRC sending the part needed to your plant and schedule a service tech to come make the repair.
-
It doesn't have a screen ID, access to label keys looks like this in an editor (Notepad ++ for example)
<GLABEL level="1" name="TOUCHUP" access="1"/>
and like this when its saved as XML
<GLABEL access="1" level="1" name="TOUCHUP"/>+
If you open a file on the robot called "TPMENU.DG" it will have a list of the menus installed on that robot with Soft Part ID and screen number. For items that are labels controlled by function keys its normally the name that's listed above it on the screen. For individual commands in a menu, its in a section labeled "XML Syntax for Password Configuration File" of the arc, handling, spot, and paint tool set up and operation manuals. I would suggest reading that section in whichever manual you have, it will help you greatly. -
It wasn't the reloading of the software that fixed the robot, we had tried that and it didn't correct the issue. It was actually the CPU change that fixed it. We had aimed to put the CPU board in a different robot and test it but never had the time to do it before the problem CPU was trashed. When it happened every linear point in the robot was about 10 mm low uniformly across all the programs. Normally when a joint is off its not uniform like that across programs, its off in relation to how the robot joint is oriented at that taught point. To check for something mechanical I would teach some points to a couple of reference positions in the cell, making sure they weren't all attached to to something that shares the same floor mount. Teach the point and teach several addition points with the robot in several different orientations but the same x,y,z location. If its something mechanically wrong with the arm you should see the robot off in different directions depending on the robot orientation.
-
It stores 100 entry's before it overwrites and its saved in a file called ERRPWD.LS. That may seem like a lot but it can be overwritten very quickly if someone logs in often or makes multiple changes. You may want to look into using Karel to save the log to a CF card or to somewhere on the network ever so often.
-
I've seen something like this happen once that wasn't a mechanical issue. It was a 120ib with a RJ3ib controller in a welding application. The robot ever so often would be off in Z. You could adjust the robot back and it would be fine for a week or two and be off in Z again. We tried a lot of different things, replacing parts / electronics including swapping the entire arm out with another robot but the problem remained. Ended up swapping out the CPU board out with a spare and loading the imagine back and it corrected the issue.
-
It doesn’t the passwords control what a user can do though the teach pendant. Functions the robot does by itself in the background still operate normally.
-
We do this on a large number of robots, the only real limit to it are the number of users and where you can log in from. 100 users and the front of the controller on a R30ib robot older than 8.3 and 200 and either the TP or controller on 8.30 and newer. You simply set it up on one controller, enable passwords on the others and copy the syspass file into them. The hardest part I have found is writing the xml file if you want custom levels of access.