You unassigned the UOPs, but did you disable them? If you didn't disable them, that could be your problem.
Posts by Nation
-
-
Sorry, forgot to respond to you all. I ended up using a flag that I pulsed for 5 seconds right when the button was pressed, then checked below if the button was ON and the flag was OFF, turn the output on. Worked pretty well. Thanks for the replies!Is this the right way to do it? You are really just checking if the button was on at the start and at the end of 5 seconds, and not if it was released anytime in between those two moments. You could just hammer the button, and if you timed it right, the output event would still occur.
A flag makes looking at I/O and registers easier/quicker. For instance, if your robot has 3 grippers and you want to check that all grippers are open before doing something, you would check something like this:IF (DI[1: Gripper 1 open]=ON and DI[3: Gripper 2 open]=ON and DI[5: Gripper 3 open]=ON), CALL CONVEYOR_UNLOAD;
Now, to make it easier... Go to you I/O page and go to Flags. Add a flag (F[1: All Grippers Open])...
Then in a background logic program, add this line:
F[1]=(DI[1] and DI[3] and DI[5]);
Now, Flag 1 will be ON when DI[1], DI[3], and DI[5] are ALL ON.This way, you can change your program to look like this:
IF (F[1]), CALL CONVEYOR_UNLOAD; *much easier to read and write*
Marker bits are also an effective way to do what you describe. They act like single line BG programs. You have to enable them though, by setting $MIX_LOGIC.$use_mkr to true.
-
I was wrong on where to set the password earlier. You should go to the host comm screen, and the select F4 for [ SHOW ] and then select Severs, select the FTP S1, and then you should be able to set the username and password in there.
-
Turns out I was wrong, according to the 8.30 internet operations and setup manual, the inbuilt ftp server does not support usernames or passwords if the password option is not installed.
-
-
We did this on a job I was on. We used the SNPX protocal to talk to the robots over TCP/IP. In order for this to work, you have to have the SNPX protocol installed on the robot (which makes the robot emulate a GE Fanuc PLC), and then there are a bunch of system variables you have to setup in order to map everything to be accessible via kepware.
-
Whoops. Those instructions were for client tags.
-
.L stands for local, as in the fault will only effect the task that issued the fault. .G stands for global, meaning the task that issued the fault will cause all tasks to respond the same way as the caller.
Doesn't really make a huge difference on single arm robots, but if you are running multiple arms with independent programs, it can become pretty useful.
-
In addition to what HawkME said, here are some others.
Code
Display MoreNone = 128 <- Error appears in the log, but doesn't show up on the TP display line, and doesn't stop the robot. Warning = 0 <- Error appears in the log and on the TP display line, and doesn't stop the robot. Pause.L = 2 <- Pauses the task locally. Allows the robot to complete its current motion segment. Pause.G = 34 <- Pauses all user tasks. Same ^ Stop.L = 6 <- Pauses the task locally. Robot decelerates to stop, but the move is saved and can be resumed. Stop.G = 38 <- Pauses the task globally. Same ^ Servo = 54 <- Seems to preform the same as a STOP, but also shuts off power to the drives. Servo2 = 59 <- Same ^ System = 123 <- Stops everything, and requires the user to reboot the controller. Abort.L = 11 <- Abort the task locally. Robot stops in the same manner as an estop. Abort.G = 43 <- Abort all user tasks. Same ^
-
I extracted contents from manual (Alarm codes list of R-30iB, B-83284EN-1/02) , which includes more info, i.e. cause & remedy.I have no idea if Fanuc teach pendant had those built-in info.
They do, but I have found that the remedies in the diag area of teach pendant tend to lag behind what is in the manual. Other times the fault simply won't be in the diag area, but it will be in manual.
How is this different than pushing the shift key and DIAG at the same time?See above.
-
1: For this, press the STATUS button on the teach pendant, then press TYPE (F1), and then select VERSION ID. Once in there, press CONFIG (F2). The robot will then list every option installed in in. Alternatively, if you have a backup, you can look in the SUMMARY.DG file.
Since this is an educational robot, if you don't have the option, Fanuc will likely give it to you for free (makes a great write off for them).
2: No, it should be taught in your application frame, which can be the same as your cal grid frame, but usually isn't. Think of having a pallet with the cal grid in the middle of it, but the app frame is on the corner. For the second part, you just teach your pick up wherever on the part you want and use the move option VR offset when you teach the pick.
3: It doesn't matter how you jog there, but it does matter what user tool and user frame the robot has active at the time when you hit record. When you hit record, the robot records into the point what user tool and user frame were active at the time. If you try to run to the point with a different user tool and/or frame, the robot will post a fault.
-
Maybe you (or anyone) could answer one more question for me: If I have the UOP mapped to physical inputs (and remote mode active), is that all that is necessary to use the UOP inputs? I am going to look into Fanuc background logic just for my own knowledge, but would it still be necessary in this situation?Yep, that's all that would be needed. This is exactly how I did a PLC-less cell in the past. We had a 3 PB box by the door, with a hold/resume switch, fault reset, and a E-stop.
-
At first I was thinking the control box, but the whole changing the $remote via a system monitor seems janky to me. You could do like you are planning and change the robot to be permanently in remote mode, and then just monitor the cycle start push button via the background logic to start the robot. To the user, it would be transparent.
BG logic functions just like a normal robot program, except your instruction set is limited (slightly to extensively, depending on controller rev model), and no motion is allowed. Once running, it runs the program every 8 milliseconds or so, and will not pause in any situation.
If you can translate your rungs into if statements, it would be very similar to a PLC. The major limitation is that you don't have access to a large amount of timers, since the Fanuc by default only has 10.
-
That seems kind of like overkill. Why not just assign the UOPs to flags (rack 34) and have a background logic program handle everything?
For your remote question, should be fine, provided all your enables and holds and stuff are ok.
-
-
If you have a dryer or electric oven, those typically run off of 220. Just go to the hardware store and pick up an appliance power cord.
Hire an electrician if you want a dedicated plug for the robot.
-
Completely possible. Magswitch does this all the time.
-
The latter. If you step backwards, it will run the same path it took to get there, ignoring the move's movement type you are stepping backwards towards.
So to equate your backwards program, it would look like this:
(J or L, doesn't matter since you start here) P3 2000mm/sec CNT 50
L P2 100% CNT 50
J P1 100% CNT 50 -
There was a thread a while ago about how a Cognex can be addressed as a Ethernet/IP device. I'll see if I can look it up.
Found it: https://www.robot-forum.com/robotforum/fan…-communication/
Not as much info in that thread as I thought.
-
Check $REFPOSMAXNO.Also, if you want more than 10 enabled at once, you will have to modify $REFPOSMASK[1].$MAXREFPOSEN. Of course this system variable isn't documented, so I wouldn't go nuts with it. Increasing it too high would likely decrease robot performance.