Posts by flatcurve

    I'm trying to write a KAREL program that will create a TP program and populate it with a bunch of motion commands. The problem I'm having is it seems like there's a way to make a TP program (CREATE_TPE), but no way to add new lines or instructions to it. So what's the point of that command? I can modify existing motion commands with the SET_POS_TPE, but not create new points. So I tried to just create an LS file and use position registers to make it easy, but I keep running into problems with the /ATTR section of the program causing ASBN-002 syntax errors when loading.

    Anybody done something like this? I know there's got to be a command set for it, because FANUC has KAREL programs that basically do this.

    This error means the macro was aborted while executing. It doesn't have anything to do with editing. It's probably a situation where the conditions aren't right for it to run. How are you executing the macro? Is it triggered by I/O or is it a manual function?

    Also, for future reference, on an iPendant you can go to the active alarm screen or alarm history page, highlight an alarm, and press SHIFT + HELP/DIAG to bring up a more detailed description of an error.

    a problem about the touch-screen, but a little different:

    I have a HMI panel created on the screen, which allows the operator to manually jog inverter-driven tables. The jogging between two opposite positions may take about 70-80sec, but after about 60sec of continuous touch on the screen, a "Touch Screen fatal error" occurs. The touch-screen is disabled until the error is confirmed. I guess it's because the controller detects a short-circuit on the screen. Is it possible to change the detection time so that the error doesn't occur?

    Couldn't find anything in the system variables that looked like it would change that value. What I would recommend is since you're making the operator use the teach pendant, why not make the button on your HMI a toggle instead of momentary and monitor the deadman? (Rack 36, Slot 3, Point 5) If the deadman is released, use background logic to shut off the output.

    Scan time is still 8msec (12msec on mate controllers) but the amount of items processed per ITP greatly increased in v8 of HandlingTool. (540 vs. 300) An item is data, an operator or an instruction. So the following is a 3 item statement:


    Item 1: F[1]
    Item 2: =
    Item 3: (DI[1])

    My general rule of thumb is to use a PLC if I have more than 32 outputs to control. Obviously there's also considerations for what those outputs are doing. But if you think you might have pulsed inputs shorter than your scan time (x2), you should just use a PLC regardless.

    Am I crazy or is there really no way to set up SMTP with authentication credentials? I know sendmail used to do this in the old days, but thanks to spammers you can't have open SMTP servers anymore.

    How do you guys get around this if you use this option? I actually have a customer who wants to use the email features and I (foolishly) thought that this would be a piece of cake to set up.

    We've explored doing it before but in the end found that the nature of a six axis robot won't give us the accuracy we needed. But it depends on the application. If you are putting the hole in the same location every time, then the repeatability of the robot should get you there. If you're feeding the robot positional offsets that vary from part to part, you may not be happy with the results.

    As for feedrates when tapping, I'd use a tapping chuck with an adjustable clutch and auto reverse. Trying to rigid tap with a robot is going to be a headache.

    So is there any approximate relationship? The reason I want to know is in regard to quick mastering. How close to zero must I be for quick mastering. Fanuc documentation says you must be within 1/2 a motor revolution. Well I can not see the motor turning inside the robot, so I would like to have an idea what that 1/2 motor turn means in terms of a joint angle that I can see.

    Thanks again

    If your quick master position is at 0 degrees for all joints, then lining the robot up visually by the witness marks will get you more than close enough to do quick master. If it's not at 0 and no witness marks were made for the ref position but you are able to put the robot in a zero position, you can copy the data from $DMR_GRP[1].$MASTER_COUN into $DMR_GRP[1].$REF_COUNT and then do the quick master at 0. If your ref position is not at zero and you can't get the robot to zero, then I guess you just hope that the integrator put witness marks on the new position.

    Either way, you should always check that the elements in $DMR_GRP[1].$REF_COUNT have encoder counts in them and not 0 values BEFORE you run the quick master routine.

    As to finding the angle per motor revolution, I don't think that's necessary. The lowest I've seen has still been over a degree. As long as you stay in that window, you should be good.

    I don't know that any of these have even hit the used market so there's really no baseline. What was your cost? Right away I know I'll probably be out $10k-$20k just moving and mounting the thing between freight, equipment rental, rigger and contractor fees. It probably requires a concrete pad thicker than what 99% of industrial buildings currently have. FANUC also suggests (and insurance demands) that the mounting location be certified by a PE (which is $10k just to stamp a piece of paper.) Then there's the cost of license transfer with FANUC so that they'll support it.

    I wish I had a project for it though.

    I've run into this problem many times. Does anyone know of a way to modify the config through TP?

    Racermike's suggestion above is the best way to go about it with TP. It's worth noting that once you have your config taught in the PR, it should stay the same. If you know you're always going to be in NUT or NDB or whatever, you can just create one zero value PR with the proper config and create a routine to copy that into all of your other position registers. Unless you reteach in a different config, they're not going to change on you when you edit their elements one at a time.

    Otherwise, you'll need to fork over $500 for the KAREL option so you can pass string arguments to a .PC program that will change the config for you.

    Hi, we have a plasma torch attached to a Fanuc Robot by a magnet and we've installed a switch that detect if the torch hit something and detach from the robot and I would like to make the program come to a "HOLD" so the operator can go put it back on and press "CYCLE START" to restart where it was...

    If you are using UOP, then this is exactly what UI[2:Hold] is for. Whenever UI[2] is dropped, the robot will soft stop and pause the program. You can configure that input to the same I/O point that you have for DI[10]. Note that the program will not run at all unless that input is made. So automatic operation of the robot will be impossible without the torch on.

    Alternatively, you could configure UI[2] to a flag (Rack 34) and do something like this in bg logic:

    1: -- For this example, UI[2:Hold] is configured to Rack 34, Slot 1, Point 2, which is F[2:UI_Hold];
    2: -- DI[11:Override] is an input used to override the torch signal; 
    3: ;
    4: F[2:UI_Hold]=(DI[10:DETECT TORCH] OR DI[11:Override]);

    That way your hold input can be satisfied by either the torch or an override command coming from a cell controller PLC or key switch.

    Just for my own information... why can't he just do a zero master using the align mark on the robot joints instead?
    Thank you

    It's practically impossible to accurately master a robot from the witness marks if you want to get precision out of it. You'll get good repeatability out of it, but what h.esk60 wants is accuracy. For that, the robot's kinematics need to be perfectly matched with the mastering data.


    +/-8mm over 300mm is not normal... but it's not unusual for a robot to be off by a bit over a large distance. It will repeat to the same position within .04mm, but there's no guarantee that the position itself is accurate. This is because of things like gravity, link flex and slight variations in the link castings themselves. A good set of mastering data is important for accuracy, but it's only half the battle. You still need to calibrate to compensate for those variables I just mentioned. The easiest/best way to do this on a FANUC is with the iRVision Mastering and iRCalibration software options.

    The most simple way to generate one shot is using the PULSE instruction with no time specified.
    In BG Logic, this generates a single scan pulse.
    Note, that in normal (non background) execution this will generate a pulse of default $DEFPULSE duration.

    also note that the PULSE command does not work in FAST mode (guaranteed 8msec scan time) so if you need edge detection in a fast bg program, you gotta do it like this:

    F[1]=(DI[1] AND !F[2])

    There are a couple of ways to do it, and both involve setting up a digital output for AUTO in the system config screen. (Menu - System - Config - Usually option 31)

    I like to configure that particular digital output as a flag (Rack: 34, Slot: 1, Point: [flag #]) but you can use any valid digital output. From there, if you're using background logic already, the easiest way to do it would be to add the following line to that bg logic program:

    1: IF (DO[...:Auto]),$MCR.$GENOVERRIDE=(R[...]) ; (You can also use a constant here)

    I like to add a debug flag to that line so that I can run the program slower (or faster) if I need to without having to edit the BG program:

    1: IF (DO[51:Auto] AND !F[1024:Debug]),$MCR.$GENOVERRIDE=(R[50:GenOvrd]) ;

    The other way to do it (if you don't want to use BG logic) is to use the override select feature. If this is the way you want to go, then you need to be using a DO configured to a flag point. Then you need to configure a digital input to the same flag point, and then go to "Ovrd Select" from the setup menu and configure it thusly:

    1 Function Enable :ENABLE

    2 Signal 1 : DI[...][OFF]
    3 Signal 2 : DI[...][OFF] (same input # as above)

    7 ON ON (whatever override % you want)

    Recovery is probably the hardest part of the integration process, especially if your robot changes it's arm configuration during the cycle. Some people track the progress of the robot in the cycle using registers. The problem with that is if somebody jogs the robot or changes that register before restarting, you could easily crash. The most fool proof method involves completely forgetting everything you were doing and simply looking at the current position of the robot, and the status of the end-of-arm tool.

    If my workcell is simple enough, I just use the PR[...]=LPOS command and divide the work area up into sections. Each section has a safe position that the robot can recover to before moving directly back to the home position. Once at home, I'll look at my EOAT actuators and sensors to figure out if there's a part. If there is, I'll either get rid of it or fault, depending on the process. That's the "easy" method. I like it because it's usually robust enough to recover the robot even if it's not within the known work path. It's not fool proof though. It won't work too well if there are a lot of obstacles to dodge, or your wrist configuration changes a bunch.

    That's when I usually have to resort to a recovery method I learned in the FANUC Advanced TPP class, which I have modified slightly over the years. It's fairly similar to chipprogr's method. It basically compares the current position to a set of pre-recorded position registers of the work path, and determines which one is closest. It then moves to that position and then follows the rest of the sequence to get back home. If my EOAT is interfacing with a complicated fixture or machine, this is what I use.

    I've removed the irrelevant stuff from the following code, so ignore the big gaps in line numbers. Basically how this works is I've got position registers 20-59 recorded about 100mm apart from each other on the known workpath. I did this using a KAREL program that I wrote which unfortunately I don't have access to the source code right now. If you have the advanced constant path option, you can just run the robot at a slow speed and pause it every so often to record the waypoints. I recorded these positions with a zero value UTOOL because the normal cycle itself switches UTOOLs a couple times during operation. It's easier if the evaluations are all done with a common UTOOL. Once I've determined where the robot is in the path, then I just use a FOR loop to step it through position registers 60-99, which are basically PRs 20-59 recorded in Joint representation to avoid config change and singularity faults.

    Maintenance guys HATE this recovery method because invariably they feel the need to manually jog the robot out of the path to work on the EOAT, even though I've given them plenty of macros and manual functions to make that work easy for them. Then they have problems starting the thing up, which always seems to happen on a Friday afternoon. I've started to add a routine which increases R[82:MaxDistSQ] when it compares the LPOS to the home position (which is usually the last PR). That way I can tell them to jog the robot to the approximate home position and it usually recovers fine from there.

    The other big problem with this method is that it's a pain to modify it when the path changes. But sometimes this is the only way to do it safely.

Advertising from our partners