Posts by flatcurve

    One of the features on the new R-30iB iPendant is the ability to plug in a USB keyboard or mouse. Initially I thought this was great, but after the first time I tried it it just seemed awkward to me to have a keyboard plugged in. Then I remembered the wireless keyboard I had at home for my media computer, and decided to give that a shot. Happy to report that it works like a charm and is much less cumbersome than a regular keyboard and mouse.

    Here's the link if anybody is interested:

    It makes program commenting a lot easier and using a mouse is actually great for jumping around in a program.

    Also, a heads up: KAREL program execution is not allowed for free anymore on the new R-30iB platform. If you compile something offline and load it onto the robot, it won't run unless you purchase the RTL. They've dropped the price for KAREL to below $500 at least. I know a lot of you use the IO Comment tool available on this forum, and I've got a handful of other useful KAREL programs that I liked to use, so this is a bit of a disappointment. I haven't been able to convince anybody to tack it onto the bill yet, so that kind of sucks.

    How well it performs depends on the parts it is picking. It can be rather slow (maybe 4-6 parts per minute) but if it is loading a machining process, then it is usually fast enough. What did you want to use it for?

    I know this is a late response, but I have done this with BG Logic, and it's very simple:

    R[120:Xpos]=$SCR_GRP[1].$MCH_POS_X ;
    R[121:Ypos]=$SCR_GRP[1].$MCH_POS_Y ;
    R[122:Zpos]=$SCR_GRP[1].$MCH_POS_Z ;
    !At Machine ;
    F[2:AtMach]=(R[121:Ypos]<R[124:AtMachYBnd]) ;
    !Inside Machine ;
    F[1:InMach]=(R[121:Ypos]<R[123:InMachYBnd]) ;

    R[123] & R[124] are set to the Y value of the boundary you want to define. F[1] & F[2] will turn on when the TCP crosses that boundary. You can be as complex or simple as you like. Such as:

    F[1]=(R[120:Xpos]<R[100:XHigh] AND R[120:Xpos]>R[101:XLow] AND R[121:Ypos]<R[102:YHigh] AND R[121:Ypos]>R[103:YLow] AND R[122:Zpos]<R[104:ZHigh] AND R[122:Zpos]>R[105:ZLow])

    ... which will set a flag if the TCP is within a defined box in space. However I try to keep each line down to only one or two boundaries if possible.

    As others have stated, it only works during program execution and not jogging. It is very helpful with recovery though. One word of advice: If you plan to use this for recovery, also include this as one of the first lines in your recovery routine:

    PR[?]=LPOS ;
    J PR[?] 10% FINE ;

    This will just move the robot to it's current position. That way if somebody has jogged the robot since the last time it was run, the MCH_POS variables will update.

    The reason this isn't working is because you're trying to do it as a mixed logic statement. ...=(...) instead of just ...=...

    However, you can't dump a parameter into a PR element directly, so you need to put it into a register first and then put that register into the PR element, like so:

    R[98]=$LNSCH[1].$TRK_FRAME.X ;
    PR[98,1]=R[98] ;

    AR[1] is the argument used when calling the sub program. It's a way to pass data to another program without having to use another line to put it into a register.

    When you use the CALL statement, if you move the cursor over to the right of the program name, you can press F4 [CHOICE] to bring up a list of different types of data you can pass into an argument. It can be a constant, register, string, a string register, an argument register (if the program was called by another program itself) or a combination of up to 10 of any of those data types.

    Section 6.18 of the Handling Tool documentation covers it pretty well.

    You could store them in position registers:


    And then to restore it, use the command "UFRAME[ ]=..." in the "Offset/Frames" submenu:


    I've had to do this before, and one of the most efficient ways to switch frames is to write a separate program and call it with an argument, instead of using the UFRAME_NUM=... command. Like so:


    1: CALL FRAMESET(1);


    1: UFRAME[9]=PR[AR[1]]; This will put PR[1] into User Frame 9
    2: UFRAME_NUM=9;

    You can do the same thing with tool frames. I've had to do that before on a robot that had to run a bunch of different parts. Each part needed a different end effector, and each end effector had three to four different tool points.

    FANUC's policy I find is, unless your a large automotive or similar large manufacturing entity, 'screw' you - pay thru the nose and lump it. Their big customers get all the service and discount and the rest of us can go to hell. I have a lot of contact with various system integrators who are increasingly frustrated with FANUCs getting 'blood from a stone' mentality - only thing you can do is to lobby all who use FANUC to consider switching to other robot suppliers

    This hasn't really been my experience. I think it comes down to who your rep is over at FANUC. I think my company got lucky in that regard. We're not a large integrator in any sense of the word (JR or Ellison probably do as much business in a week as we do all year) but FANUC does a pretty good job of meeting our needs in terms of pricing and support. I sometimes worry that we're too demanding for a company that is this small, but I'm not complaining about the results. It may also be that we just know how to work the system over there.

    We've only been a FANUC integrator for the last two years, but I have to say that in those two years I've seen them personally address most of the issues that I've had with them. For such a large company to pay attention to the little guys like us is impressive.

    Ah, yes... FANUC charges full price to the end users for the software. If you bought and integrated the robots yourself you may have been able to negotiate that a little better. But if you purchased it through your integrator, it's unlikely that they would pass their discount on to you. I certainly wouldn't if we already received the PO. Have to keep the lights on somehow.

    You can use roboguide to edit and compile KAREL .KL files. There is no software that can decompile a .PC binary. That's pretty standard for all forms of compiled programming though. Also, it sounds like you're getting ripped off on the license. If you're a signed integrator, you can get a universal license for $2k a year, which entitles you to all of the PRO applications (WeldPRO, DispensePRO, HandlingPRO, PickPRO, etc...), virtual controllers from v5.3 up to v7.7 (current) and constant updates. And if you buy robots often, you can usually avoid paying that license fee altogether. It has to be negotiated with the purchase of the robot though. They like to let you think that you got away with something they don't normally do, but it happens all the time.

    Totally agree with you about the eDocs though. I can't stand those things. The one for iRVision is the worst. It reads like it was translated from Japanese by Google Language Tools or something.

    Background Logic programs are scan routine programs that constantly run in the background. They are executed one line at a time, from start to finish, repeatedly. If you know anything about PLC programming, they are very similar to the way those programs are structured and run. You can only use assignment statements in background logic programs. This means that you can not use motion instructions, branching statements (jump, label, call, run, etc...), timers, WAIT instructions or macros.

    So basically you are limited to setting registers, I/O and system variables. And the only conditional statement you can use is the mixed logic IF statement: IF (...)

    All of this is to keep the program simple so that it can be executed quickly. In my experience, if you're dealing with less than 16 inputs and 16 outputs, background logic is a good way to avoid using a PLC in the workcell if you don't have to. Anything more than that would probably be better suited to either the PMC option or a PLC. For me, the primary way I use it is to set up run conditions that must be met before the robot can be operated in automatic.

    A "one shot" is probably the most valuable tool you can use when doing this sort of programming. Remember that this program is repeatedly scanning (looping) in the background. We use a one shot to make something happen for only one scan. For example, let's say we have a button connected to an input (DI[1]). Every time we push the button, we want to add 1 to the value of a register (R[1]).

    IF (DI[1), R[1]=R[1]+1

    The problem with this code though is that the program is repeating every 8ms. Unless you have very quick hands, it's likely that the button will be held down for more than one scan of the program, resulting in more than 1 being added the the register. So to fix it, we have to use a one shot:

    IF (DI[1] AND !F[2]),F[1]=(ON)
    IF (F[1]), R[1]=R[1]+1

    And here's how it works scan by scan:

    First scan with DI[1] on:
    F[1]=(OFF) ;We always turn this flag off at the start of the cycle
    IF (DI[1] AND !F[2]),F[1]=(ON) ;If DI[1] is on, and F[2] is off, we want to turn F[1] on
    F[2]=(DI[1]) ;Now we want to set F[2] to the same state as DI[1]. This means that on the next "scan", the condition in the previous line will not be met.
    IF (F[1]), R[1]=R[1]+1 ;If we've gotten this far, and we see that F[1] is on, that means we know it's the first scan where we've seen DI[1] on

    Second scan with DI[1] on:
    F[1]=(OFF) ;Again, this flag gets turned off to avoid repeating any of those assignments again
    IF (DI[1] AND !F[2]),F[1]=(ON) ;This time around F[2] is on, so this condition is not met, and F[1] stays off
    F[2]=(DI[1]) ;This holds F[2] on until we see DI[1] turn off.
    IF (F[1]), R[1]=R[1]+1 ;This line will not execute

    First scan with DI[1] off:
    IF (DI[1] AND !F[2]),F[1]=(ON) ;DI[1] is off, and F[2] is still on from the last cycle. Condition still not met.
    F[2]=(DI[1]) ;Now F[2] is turned off. The next time DI[1] comes on, the above condition will be met again.
    IF (F[1]), R[1]=R[1]+1

    Basically it all comes down to order of execution. If you put things in the right order, you can do practically anything. Earlier I said that I prefer to use BG Logic with less than 16 inputs and outputs, but I have used it as a cell controller on a system that had 32 inputs and 48 outputs. It controlled everything from the notification lights, an exit conveyor, a couple of pneumatic cylinders, a small printer and another robot. All with background logic. I would have preferred a PLC or even just the PMC option, but the customer beat us up on price and the budget didn't allow it.

    Here's a chunk of code from one of the four BG Logic programs running on that system that uses all sorts of one shots and cascading logic:

    This code basically triggers a printer to print a label, cut the label with a shear, move the cut label with a small slide so that the robot can pick it, and tells the robot that there's a label present. Once the robot picks it, it turns off the label present flag which starts the print cycle again automatically. All of this happens in under a second while the robot is off applying the label. It also has allowances for a manual push button trigger so that the printer can be set up and tested in a maintenance mode. This is the primary reason I used BG Logic instead of a macro. Because BG Logic runs all the time, whether the robot is paused, in automatic, or in teach mode. This means maintenance personnel don't need to mess with the teach pendant as much. From a support standpoint, I prefer that whenever possible.

    Like I said, you can do anything with it.

    So, I've only been using BGLOGIC for a couple months now. In my opinion, this is something that FANUC should teach in their advanced TPP class, because it's extremely useful. If it wasn't for the suggestion of somebody here, I never would have discovered this feature on my own. I guess they expect people to read their manual cover to cover, but there isn't enough coffee in the world to keep me awake if I tried that. I've managed to take a lot of heat off of our PLC programmer, and I've already developed a few routines that I've found almost universally useful.

    So as a way of saying thanks, here are a couple code snippets I thought I'd share.

    One shots are used when you only want something to happen for one scan of the program. This can be used to replace macros that are triggered by inputs. Why would you want to do that? Well, input macros don't work in T1 or T2.

    One Shot Method A
    IF (DI[1] AND !F[2]),F[1]=(ON)
    Now F[1] can be used at any point to test for a one shot condition before the end of the BG program

    One Shot Method B
    IF (DI[1] AND !F[1]),...
    (Repeat above IF instruction when needed before next line)

    One Shot Output Toggle
    This is handy for using a single input (like a push button or sensor) to toggle an output on and off
    IF (DI[1] AND !F[1]),DO[1]=(!DO[1])

    Output Strobe
    We put three color stack lights on our controllers, and I use this routine to make the yellow light flash when I turn on F[1]
    IF (F[1] AND !F[3]),F[2]=PULSE,0.2sec
    IF (F[1] AND !F[2]),F[3]=PULSE,0.2sec
    IF (!F[1]),F[2]=(OFF)
    IF (!F[1]),F[3]=(OFF)

    If anybody wants to add, feel free!

    Well, I can't imagine that you're drilling more than 200 holes per cycle. (And apologies in advance if you are.) I would suggest using a combination of local program positions and position registers.

    Without seeing the part or knowing how complex the process is, what I would do is simply set up one position register per hole, then use offsets for the approach and plunge depths. Just reserve one PR for each of the offsets and change the values on the fly (PR[x,3]=x, etc...) if those offsets are different for each hole. You can just use regular P[] points to position the robot in the vicinity of the hole to be drilled, and then the PR[] offsets should get you the rest of the way. This of course assumes that the parts are similar and the positions of the holes don't change much whenever you're using the Metris system to measure them.

    I usually toss an HMI display on the teach pendant under the HMI Quick Menu that just shows a basic status of the robot and covers a couple important functions. If you're patient, you can probably do whatever you need to with the MS Frontpage method. It's definitely the cheapest option. I don't know if I would add a PLC to a cell just to put in an HMI though.

    Here's something you might find handy: I occasionally found it necessary to call and run a TP program from the HMI. The easiest way I discovered to do that without having to mess with KAREL was to customize the user menus to run a TP program, and then put a direct HTML link into the HMI .STM file that called that specific menu item. For example:

    <a href="/SOFTPART/GENLINK?current=menupage,31,250"> (your link text or image goes here) </a>

    will call whatever program you've set up in the system variable $CUSTOMMENU[10], which gets displayed in the utilities menu when you're not using HMI menus. There are 26 different menu items you can customize to call a TP program. All you would need to change in that URL are the two numbers after "current=menupage,". The first number is the softpart ID, and the second is the screen ID. Section F.5.6 of the HandlingTool manual lists all the softpart ID and screen IDs of the customizable user menus.

    The other tip I have is to resize your frontpage window so that the size displayed on the lower right is 640x365. This seems to give me the best WYSIWYG results.

    where i can get the Karel reference Manual?? I need to ask to Fanuc? the enterprise who sells the riobot just leave the operator manual and the maintenance manual... just this... nothing for comunications and for robot programming language..
    best regards

    The KAREL reference should be included on the tool operations manual CD-ROM. If this is a new robot, you should have gotten at least three CD-ROMs with your purchase:

    1. Controller specific documentation (R-30iA)
    2. Mechanical unit specific documentation (R2000, M20iA, etc...)
    3. Tool specific operations manual (HandlingTool, PaintTool, ArcTool, etc...)

    And then maybe an extra CD or two if you got any big options like iRVision. If your integrator didn't give you these things, ask for them. They shouldn't be holding them from you. Although if this is a used robot, you will need to get the manuals from FANUC. Good luck with that. Have your F number, controller type, and software versions handy before you call.

    Also, unless you know specifically that what you want to do with the robot requires KAREL, I wouldn't recommend using it if you have no experience with the FANUC robots. There are two programming languages on these robots: Teach Pendant Programming (TPP) and KAREL. TPP is all you will need for 99% of what you can do with the robot. KAREL is a bit more intensive and less fool-proof. If you don't know what you're doing, KAREL is a good way to screw things up.

    And if your integrator already programmed the robot, talk to them before you make any major changes that might mess up the programming. They might have an easy solution for whatever you're trying to fix/improve.


    As for the original post in this year old thread, there's always the Comment Tool feature. Go to SETUP > HOST COMM. > HTTP on the robot and change the name and password on the KAREL:* entry (if it hasn't already been set). Then run an ethernet cable from the controller to a PC and type the IP address of the robot into the browser. go to the "Comment Tool" link on the bottom of the page. You will be prompted for that same username and password. From here you can set the comments on your PR, DI/DO, RI/RO, GI/GO, and AI/AO. You can also set the values on your Numeric Registers, String Registers and User Alarms. Easiest commenting ever.

Advertising from our partners