Posts by jay

    Use a pipe! I actually just wrote about this recently:…6/using-karel-pipe-files/

    Essentially you open the same FILE on the PIP: device for 'RW' in one task and 'RO' in the other. You can configure the descriptor to wait and (optionally) timeout on READs, but there are some caveats.

    If you need to pass data both ways, you will need two pipes.

    I guess you could also use sockets too, but it's probably better to use a pipe if the communication is local.

    I doubt it, but you can use KCL's (via terminal or KCL() built-in) LOAD PROGRAM (for karel) or LOAD TP (for tp programs) to first bring the program over before using CALL_PROG


    Also is there away to use blob with visual tracking?

    Yes, just add a blob tool to your visual tracking vision process and delete the standard GPM.


    how do we send origin and angle data to the robot?

    There is an option on the blob tool to calculate the angle. There are two methods to calculate the angle: axis of inertia or minimum rectangle. Traditionally, blobs always found the angle via the axis of inertia method, but the minimum rectangle method was added for "rectangular" or "square" blobs where axis of inertia would be off by 45 degrees.

    You may find that the blog tool gives some unusual rotation values... if so, you may want to use a conditional execution tool or two to clamp the angles between +/- 90 or something.

    Thanks for the link :winking_face:

    I had a project a couple of years ago where the robot had to unload parts from a stack of trays. While I was unable to witness this during the day shift, I had gotten reports from the night shift that the robot would do "crazy flips" when moving from slot to slot sometimes.

    It wasn't surprising at the time that some positions in a given tray layer may require a different turn counts. It was a surprise however, that if the whole stack was rotated just a tiny bit, those turn counts won't work right. You won't see the issue with a linear move, but you will if the motion statement is joint or wrist-joint. (i.e. normally WJNT move from point A to point B will work just fine, but depending on just a small rotation in the overall frame, it may require a full J4 or J6 rotation to maintain the same turn counts as originally programmed.)

    I don't have the source code right now, but I ended up writing a KAREL routine that made use of the POS2JOINT and JOINT2POS built-ins to calculate an appropriate destination given the robot's current posture.

    Yes, you just have to specify the %NOLOCKGROUP directive in your KAREL program. You may also want to include the %NOPAUSE directive (e.g. %NOPAUSE = ERROR + COMMAND + TPENABLE) to keep the task from pausing on errors, the pause command and/or the TP being enabled.

    It looks like the program you are attempting to translate is simply a collection of variables, almost like a C header file. This is a pretty common practice with KAREL, but the support could be better.

    If this is the case, this program will not translate and should instead be included in other programs via the %INCLUDE directive.


    PROGRAM test
    %INCLUDE vgr_var
    END test

    BG logic programs cannot lock any motion groups, so you can't throw any UALMs, PAUSE statements, etc. in there. I'd use either a condition monitor or a skip condition.

    Condition monitor method:




    UALM[1] ;
    ! restart monitor ;

    your program:

    ! pick up part ;
    ! start monitor ;
    ! move to wherever you're going ;
    ! stop monitor ;

    Skip condition method:

    LBL[1] ;
    ! pick up part ;
    ! set skip condition ;
    ! move somewhere ;
    L P[1:somewhere] max_speed FINE Skip,LBL[100] ;
    ! if we made it here, the vacuum went off ;
    UALM[1] ;
    ! try again?
    JMP LBL[1] ;
    LBL[100] ;
    ! vacuum stayed on ;

    Hope this helps.

    I think your initial assumption was actually correct, "i think that maybe the read-ahead function of robot is too slow to keep up with the real robot speed. (<6ms)"

    1. The robot's ITP is probably 8ms, so if you're modifying each point along a path every 6ms, the motion planner is going to have a hard time.
    2. The PTH motion option increases the acceleration between points on a path. This is generally used in applications like dispensing, arc welding, etc. where you may have a large # of points that are relatively close together. However, I don't think the PTH option will work real well in your case since you are dynamically adjusting the PRs on the fly. (In fact I would guess it would result in jerky motion)

    You may have better luck with a set of 5-10 that you offset e.g.:

    L PR[1] 300mm/sec CNT100 PTH
    L PR[2] 300mm/sec CNT100 PTH
    L PR[3] 300mm/sec CNT100 PTH
    L PR[4] 300mm/sec CNT100 PTH
    L PR[5] 300mm/sec CNT100 PTH
    JMP LBL[1]

    Theoretically this would give the motion planner a bit more time, but as someone posted earlier, "Why not simply increment of 300mm in one shot ?"

    You'll probably have better luck by allowing the robot to approach the start of your straight line from somewhere else, and then let the motion planner take care of moving along your 300mm segment at 300mm/s. Rather than using program timers, check out ROBOGUIDE's TCP trace tool where you can color the trace by acceleration and speed. It might provide you with more insight.

    As far as I know there is no way to define additional include directories. I've often wished for this myself.

    In the past I've generally just copied (or symlinked) files to the /support dir. Another option would be to write a tool to manage the dependencies outside of ktrans (e.g. copy/symlink the necessary files to the /support directory temporarily during translation).

    If you have the BG logic option (not sure if it's available on your platform), you could simply add a line like the one you've already written to a BG logic program. These programs are scanned continuously in the background and started automatically.

    If not, you may write a simple program that runs in a separate task:

    ! ;
    ! not sure if this is the correct sysvar ;
    WAIT .1(sec) ;
    JMP LBL[1] ;

    Then in your main program:

    RUN BG

    There are probably many other more clever ways to do it. Hope this helps.

    When you say "2 inches off the pallet", do you mean "2 inches above" the pallet? Or do you each drop is off by 2" in some direction?

    In either case, if this is an older robot (pre R-30iA), it will not have the Constant Path option which guarantees it will follow the same path regardless of override. If the termination type is high (e.g. CNT10 or above) on the drop position, you may find the robot rounding the corner quite differently at different overrides. Depending on how the gripper is opened at the drop position, it may be opening sooner/later, especially if you are using some sort of TB or DB function.

    You may try lowering the termination type (e.g. to CNT0) to fix the issue.

    Yes, you can use the Histogram tool paired with a Conditional Execution tool to pass/fail your vision process. The histogram allows you to set a range of interest of grayscale values (e.g. 0 to 100). You could then setup a Conditional Execution rule to say that if a certain % of pixels are within your range of interest, invalidate the result.

    If you have ROBOGUIDE, you can create a quick windows batch file to upload your LS files to a virtual and then download the translated TP binaries.

    This assumes 1) your LS files are in /src, 2) you want your TP binaries in /bin and 3) your virtual robot is at IP


    ftp -v -s:translate.txt


    mput src/*.ls
    lcd bin
    mget *.tp

    You could easily modify the batch file to upload the translate binaries to your physical controller using the same techniques.

    You can definitely host a web page on the robot controller that interacts with numeric registers, etc. You can either use the iPendant Customization Option for FANUC's integrated ActiveX HMI controls (buttons, select menus, inputs, labels, etc.) or use your own KAREL/JavaScript with standard HTML <form> tags.

    The entire iRVision and new iRPickTool interfaces are built with standard HTML/JavaScript, communicating with the robot via KAREL and maybe some closed APIs.

    Have you added your robot's IP to Internet Explorer's list of trusted sites? Popups should also be allowed for that IP. (You may need to restart IE after making these changes.)

    The FILE-055 error indicates that you don't have a memory card in the PCMCIA slot. As far as I know, vision logging will only log to the PCMCIA slot since USB is too slow.

    Make sure you're using Internet Explorer version 9 when using iRVision. Also, to expand on bidzej's answer, make sure the robot and PC are on the same subnet but are using different IP addresses (e.g. robot, PC Might want to also check that the robot is not setup for the same subnet on both ports (e.g. for a subnet mask: 192.168.1.X on both ports).

    Crossover cable is not necessary with R-30iA. You should be able to connect a standard ethernet cable directly from the PC to the robot.

    150mm should be plenty for calulating the Y/Z-directions of the tracking frame. (That's pretty much all that final step does). Assuming you followed the directions correctly, it sounds like your encoder setup is not correct. Check to make sure the encoder is counting when you move your conveyor, and that your line is setup to track the correct encoder.

    Refer to section 12.26 in the HandlingTool manual. The option provides an interface for creating these different prompts, yes/no boxes, etc. You can then call them like a macro by id or name in your TP program:

    ! show my custom prompt named ClickOk ;
    ! before continuing ;
    Prompt Box Msg('ClickOk') ;
    ! prompt box #2 and ;
    ! store result of Yes or No in R[5] ;
    Prompt Box YN (2, 5) ;

Advertising from our partners