A couple of manufactures I've seen used in industry are Gudel and Easom.
Posts by Nation
-
-
Joint moves are not allowed in tracking programs. Neither are any form of user frames.
If you do need to do a joint move, do it in a non-tracking program that you can call from the tracking program, or use the wrist joint motion option.
-
Take a look at the roboguide help file. Contrary to most programs, it is very helpful in setting up stuff like this.
Specifically, use the seach, and look for "Line Tracking", once you find that, select the "General procedure for setting up a line tracking workcell" option. It goes over it in detail, and is how I learned to do it.
-
No needs to be dual channelThe ABB-RT9 is dual channel, on inputs and outputs.
Does anyone know if a ABB- RT9 safety relay would work with a Fanuc robot using a R-30ib controller. The safety relay would be used with an interlock on a robot cell.Wired correctly it would work. I would recommend you buy one for the fence interlock, and another for the external e-stop chain.
-
The Karel compiler doesn't do any optimization though, so if you do have the source, you can turn step mode on, and then step through the program by watching the line number displayed at the top of the teach pendent. The line number displayed there will match the line number in the Karel source file. Couple that with watching the Karel variables in the data screen, and it works ok for debugging.
-
Have you tried different USB sticks? I tend to stick to smaller ones that are formatted as FAT32.
-
My KAREL is just a signal judgment and there is no motion tasks。If your Karel code does not contain the %NOLOCKGROUP in its compiler directive area, it will, by default, lock the first motion group. You can also verify this by looking at the details of your Karel program.
-
It doesn't look like you need karel at all for this application (plus I am not sure if call statements are allowed in BGlogic programs). I would just write it using mixed logic in TP.
-
Please see attached. I did this in Roboguide with a R1000iA/100F running Handlingtool V8.20.
-
You have to put the %NOLOCKGROUP compiler directive at the top of your program to produce a karel program that will not lock groups.
-
The number after the A is the hexadecimal digit that shows which axes are out of limit. The Hex indicates that the axis numbers are in hexadecimal format.
Based on your message axis 1, 2 & 6 are out of their interaction limit. If you require further assistance you can contact me to give you the Hexademical table interpretation from the oficial FANUC manual.While this was the case on R30iA and earlier, the newer R30iBs just list the axes in question that are causing the issue. You no longer need to look up the hex code.
Also, this doesn't answer my question. Some background: I am writing an offline inverse kinematic planner geared for the verification of boundaries in line tracking paths, and I need to know how the Fanuc controller generates the error listed in the subject of this post in order to accurately test the reachability of all points at all tracking locations (with various offsets to the path). While is seems to be a constant number depending on the J2/J3 interaction when the wrist center is in the positive Z range, it seems to vary once the wrist is below center.
What I am looking for is an equation that would describe when that alarm is to be triggered, preferably with J2, J3, and link lengths as inputs.
-
Figured I would give this a bump.
-
The constant 8 gets passed into FOLL_UP as an argument. It will reside in the AR[1] register if it is being accessed from FOLL_UP program.
-
Does anyone know how the A:2,3 MOTN-017 limit error is calculated? This error occurs when the arm is too bunched up on itself.
It seems to be a consistent J2/J3 interaction number (-78.8 degrees on R2000s, and -81.2 degrees on R1000s), but it stops being constant once wrist center is below the J2 motor.
-
-
I've seen it done where the switch was replaced by some dry contacts driven by the PLC that selected the mode. You would have to ring out the switch in its various states and wire it appropriately.
-
Up the resolution to the max it can go, then run the resulting video (which will be several gigabytes in size) through a video editing program to compress it.
-
What are you rotating around, and what axis? World, a user frame, tool, Rx, Ry, Rz? J1?
-
The robot's internal background task (which you cannot see) is writing to the UO bits, overwriting your GO. Either unmap the UO bits, or reassign the GO to somewhere else.
-
I've done this before by using proface HMIs and the SNPX protocol. You have to be sure that you have the Basic HMI communication (or something similar) in order to enable the SNPX protocol though.