Posts by TomTom

    Certain Antivirus might be interfering. Once my antivirus prevented me from saving any workcells and break my workcells so bad I couldn't open them anymore afterwards.


    Also when opening a cell with multiple robots I had problems with occupied ports.

    I just took a closer look at your example.


    If you don't want to let the robot to return to certain position then don't save them to the register. In this case I think you don't want the robot to return to P3 so R[1]=300 should never be set. Like this the robot will never try to return to P3 during homing. Your homing prog doesn't need a case for R[1]=300 if you do it like this.


    If your homing contains special instructions(for example opening and closing of the gripper) when the robot is on P3 then this solution gets more complicated though.


    Edit: You can also only do this with "end points" where you only go backwards from. If your P3 for example went to a P4 then you HAVE to save P3 to the register.

    Hi, is there any function, to set register at begging of the motion? Same as TRIGGER WHEN DISTANCE=0 on Kuka.


    I could use TIME BEFORE with function call (L PR[1] 100mm/sec CNT100 TB 30.00sec, CALL setreg(1)), but upper limit is 30 seconds, which could cause issues for slower movements.

    "begging of the motion" is the important right? You are only using TIME BEFORE because there is no DISTANCE AFTER, correct?


    For clarification do you want to use two registers to keep track of your movement? One that gets set when a motion is started and one that gets set when a motion is finished?


    Something like this(doesn't actually work right but I hope it gets the point across):

    Code
    R[10:nextPos]=1;
    L PR[1] 100mm/sec FINE;
    R[11:reachedPos]=1;
    R[10:nextPos]=0;
    
    R[10:nextPos]=2;
    L PR[2] 100mm/sec FINE;
    R[11:reachedPos]=2;
    R[10:nextPos]=0;

    Or do you only want what I called "nextPos"?


    Apparently there is a TIME AFTER function maybe this helps?

    There are no variables on TP programs, but data registers are permanent.

    You have to be careful with setting registers in between movements, in respect of the lookahead pointer. The robot will do the logic statements before he reached the position physically.

    So you have to use the DB statements to set the position flags/data.

    Bad news: you will break your fingers while punching those programs into the TP:);(.

    Holy moly I think using the DB statement for this is what I've been missing :guru:




    From the top of my head my code looks something like this for example:

    Code
    L P[1] 100mm/s FINE;
    R[10]=1;
    
    
    L P[2] 100mm/s FINE;
    R[10]=2;

    R[10] is supposed to remember the last point that has been reached by your program. This is used by the homing program. The homing program now needs to traverse the position sequence backwards. So during the work process I go Home -> P[1] -> P[2] now in homing I go P[2] -> P[1] -> Home. The problem is R[10]=1 for example gets executed slightly before the movement one line above has actually finished(this is the lookahead). If a sudden stop happens right then the robot remembers having reached a position it actually hasn't. Normaly your homing program returns to the last reached position first which now creates problems.


    DB stands for "Distance before". It allows you to do this:

    Code
    L P[1] 100mm/s FINE DB 0.1mm, R[10]=1;
    
    L P[2] 100mm/s FINE DB 0.1mm, R[10]=2;

    Same principle as before but R[10] is written 0.1mm before the target of the specific movement instruction has been reached. While lookahead is pretty wonky this gives you actual tolerances. You can even set it to 0.0.


    Correction:

    For some reason you can't directly set R[] values in the DB instruction :rolleyes:. Only outputs can be set directly there. Use one of these instead:

    Code
    DB 0.1mm, POINT_LOGIC;
    
    DB 0.1mm, CALL SETPOSREG(2); // SETPOSREG is just a simple helper program that you'll have to make

    Interesting program, I havent seen motion done with Karel yet.


    Are you sure it has something to do with a missing .vr file? Seems like you are using other variables like lbl_num just fine. Are you using RoboGuide or are you compiling and uploading directly to the robot? On my robots the teachPendant doesn't show .vr files when I have a .pc file with the same name. Only when I delete the .pc file the .vr file suddenly "appears".

    *.VA are the readable counterparts to the *.VR files. There's also a lot of *.DG files on the robot that contain some readable stuff. I recommend using the HTTP Server that comes with most newer robots. In RoboGuide that's accessible under the "Robot" dropdown menu and then under "Internet Explorer". Alternatively you could also connect with any FTP tool to localhost while RoboGuide is running. There are lots of files that you don't normally see.


    The PR are in POSREG.VA for example. For DIO it depends if you mean the IO configuration or the current IO signals.

    Hm normally when my PC files have problems the robot shows something in the alarm history. Maybe the transfer itself was aborted before the robot tried to load the file? You could try connecting with an FTP tool to 127.0.0.1 while RoboGuide is running and try to upload it like that. Maybe you'll at least get an error message.

    Hello everybody,


    So I have two robots(LR Mate 200iD/7L) that directly exchange a part between them. Robot A moves into an exchange position that is also a Ref Position, starts Softfloat once its there and begins waiting for the completion signal from robot B. The Ref Position signal is sent to robot B who now moves in under the part, moves up via touchskip, suctions the part and releases the grip of Robot A. Once Robot B has moved away again a pulsed DI wakes up robot A which signals that it's safe to leave the position now. The touchskip and softfloat are there to prevent wear and accommodate different part sizes.


    Could someone explain the difference between the Soft Rat and Soft Tol settings? Z+ is the direction in which robot A gets moved in by robot B. I want the gripper to remain as vertical as possible while being pushed upwards. Also robot A has to properly reach the exchange position since it's a Ref Position or else robot B will not start moving in to grab the part. Here's what I currently have:


    After each command always check the status variable. It tells you if the command actually worked or not. For example:

    Code
          OPEN_TPE (to_prog, TPE_RWACC, TPE_RDREJ, open_id, status)
          IF (status<>0)  THEN
            FORCE_SPMENU (TP_PANEL, SPI_TPUSER, 1)
            WRITE('Error while opening tp prog',CR)
            POST_ERR(status, '', 0, 2) --2 indicates ABORT; see Karel Manual
            ABORT
          ENDIF

    On every Fanuc teachpendant I've ever seen the teach pendant buttons have two labels each. For example the button for the X-Axis also has a smaller J1 in parentheses. X,Y,Z are axes that take more than one joint to execute so they dont help here. J1-J6 are the names for the actual individual motors/joints.


    If you press the "COORD" button multiple times until "JOINT" appears then you have control over each individual joint, in this case the J1-J6 labels are what counts. I don't know how the delta robot axes are set up but if you can move at all with the robot you should be able to see which joint is what.


    Lastly I believe when you get something like (G:1 A:1) you just have to look at the A-Value. A:1 means J1 and so on.

    First do a reset on the robot. Press the deadman switch + shift + reset at the same time.


    Then look if you got any active alarms under MENU->ALARM->ALARM LOG. Sometimes you land in the alarm history when you navigate there, press F3 to switch to active alarms if that's the case. Changes are some data got lost because of the dead batteries but that will show up in the alarm list.

    Fanuc wants you to edit your progs directly on the TeachPendant. Otherwise you need a paid software option. Here are the different ways you can upload a .ls prog to a robot or compile it to .tp first and then upload it. You only need to get one of these to work:

    1. You need the ASCII UPLOAD option to send .ls files back to the robot. Then you can just use a mem stick or a tool like WinSCP.
    2. All robots in RoboGuide have ASCII upload, so you can upload the .ls to a robot in RoboGuide, download the .tp file(which now contains your changes), upload the .tp to the real robot.
    3. (Compile it via MakeTP.exe. I believe I got mine from RoboGuide which also installed WinOLPC. If you already have RoboGuide option 2 is easier but I thought I'd mention it for completeness sake)

    Btw "MENU->STATUS->VERSION ID->ORDER FILE" on the TeachPendant should show all installed options.

    The easiest solution would be to use the Comment Tool that the robot already has. You can already set Registers with it. Then you write a BG_Logic program that maps certain registers to DO's. It's a bit of a messy solution though imo.


    You could also use the 4 panels that your robot should have (MENU->BROWSER->PANEL SETUP). For me they work on an external HMI with internet explorer but there are problems. They are meant to be viewed on the TeachPendant primarily it seems. You can also improve the generated panelX.stm files manually. The panel wizard Option from Fanuc does basically the same but has better control elements and layouts for the panels. Maybe check the option out in RoboGuide if you have that.

    I don't think you need that option. There's a way to do it with just Karel.

    I don't think you can change the DO directly but you can start a Karel program through HTTP that will change the DOs for you. You need to unlock Karel in Menu->Setup->HostComm->HTTP for this. Also you'll have to write the specific program yourself. I am quite sure there is a way to set a DO in Karel though.


    Take A look at this project https://github.com/ABC-iRobotics/fanuc-webcontrol.

    It's a WebInterface with which you can Jog a Fanuc Robot. The WebInterface works by starting Karel progs that change Flags on the Robot. Then they have a TP program that needs to be running at the same time that waits for those Flags. Once they are set the TP prog begins to move the Robot.

    Here's the JavaScript code that invokes their Karel program that then sets their Flags. You just need to send your HTTP GET request to the right URL.


    You can get something like this to work on Internet Explorer but I am not sure if it will work on the TeachPendant. As far as I know the TeachPendant itself can only run ancient JavaScript versions. In theory it should be possible as well as long as you are extra carefull with your JS code. Maybe the best way is to start by programming it for the TeachPendant and then exchange stuff with HTTP Get requests. Worst case you need two HTMLs, one for InternetExplorer and one for the TeachPendant.