Posts by skalactik

    Have you looked on what is displayed on the virtual pendant when this happen. Usually it is good informations to know where the problem come from.

    Memory
    There are three kinds of controller memory:


      • Dynamic Random Access Memory (DRAM)

      • A limited amount of battery-backed static/random access memory (SRAM)

      • Flash Programmable Read Only Memory (FROM)

      • SHADOW


    In addition, the controller is capable of storing information externally.
    DRAM
    DRAM memory is volatile. Memory contents do not retain their stored values when power is removed. DRAM memory is also referred to as temporary memory (TEMP). The system software is executed in DRAM memory. KAREL programs and most KAREL variables are loaded into DRAM and executed from here also.



    SRAM
    SRAM memory is nonvolatile. Memory contents retain their stored values when power is removed. SRAM memory is also referred to as CMOS or as permanent memory (PERM).
    The TPP memory pool (used for teach pendant programs) is allocated from PERM. KAREL programs can designate variables to be stored in CMOS. A portion of SRAM memory can be defined as a user storage device called RAM Disk (RD:).



    Flash memory (FROM)
    FROM memory is nonvolatile. Memory contents retain their stored values when power is removed. FROM is used for permanent storage of the system software. FROM is also available for user storage as the FROM device (FR:).


    SHADOW
    Shadow memory provides the same capabilities as SRAM. Any values set in shadow are non-volatile and will maintain their state through power cycle. Shadow memory is intended for data which tends to be static. Storing dynamic variables in shadow memory, such as FOR loop indexes or other rapidly changing data, is not efficient.

    If you have access to KAREL, you can do pretty much what you want.
    1. Monitor for the occurence of the collision detect alarm with CONDITION ... ENDCONDITION structures
    2. Enable/Disable the collision guard detection with $HSCD_GROUP[1].$COL_DET_OFF system variable
    3. Display a prompt box with the DISCTRL_DIAG built in and a simple XML file


    Sure perhaps there might be an easiest way, but this one will work just as well

    More commands found in various .CM files :


    # PCVLOAD namefile - to load namefile.SV
    # TXPLOAD namefile - to load namefile.TX
    # ASLOAD namefile - to load namefile.AS (assembly files - used internally)



    #PCCLEAR namefile - to clear namefile.PC
    #DELFR FR:namefile.filetype - to delete namefile.filetype from FROM
    #DEL filepath:\filename.filetype\ - to delete filename.filetype located in filepath

    Quote

    * If the singularity comes, is it sometimes faster?
    Are there any more cases where the actual speed is faster than the input speed?


    Yes. It may temporary increase joint speed when robot cross a singularity configuration.

    I took the document from the Karel reference manual in Roboguide and it says that TPIN[153] is the Reset key. TPIN[145] should be the EDIT key. I double check with 2 other manual i got and they all agrees on that.


    Wich manual do you got and what version ?

    Just some added info here :
    You might also need to map ENBL (UI[8]) to be able to move the robot. Because i dont use any of this signals, i usually map UI[1], UI[2], UI[3] and UI[8] on the same DI that i shunt with one of the 24F pin
    It is better to use HOLD in place of IMSTP if you only need to stop the robot.
    IMSTP and HOLD are not safety signals, if you need this kind of signals, you need to use the connector on the emergency stop card

    IMSTP (UI[1]), HOLD(UI[2]) and SFSPD(UI[3]) must be supplied to use the robot with the UOP signals.
    Either you can wire them directly to the 24V or assign them to another DI.
    Also i am unsure if you can use UOP with simulated I/O, maybe you want to give it a shot

    Depends of wich kind of program we are talking to :
    TP program may communicate with each other via Register values, I/O or Semaphore
    Karel program are more advanced thus they can also communicate via shared variables, pipes, queue ...


    Also, you are right, usually only one program at the time can control motion.

    Quote

    Not sure, but it seems Fanuc likes to make it as hard as possible for (potential) customers to use their robots and software. Making things expensive is one of the easiest ways to do that.


    I don't know where you live but my company is based in France and FANUC been kinda nice to us. We were given 2 Roboguide license for free (including vision plug-in) after we purchased our first robot.
    I think it has more to do with which FANUC office you are dealing with than what type of customer you are.

    I wonder what would happen if you disable the T2 mode via System variables and then use the pendant with Roboguide. Does roboguide will assume the new mode would be T1 and start acting like it is ? Maybe you wanna try that

    Yes.


    Use the SET_VAR built-in with the $MNUTOOL[1,*] and $MNUFRAME[1,*] variables where * is the tool or frame number.


    e.g. SET_VAR(ENTRY,'*SYSTEM*','$MNUFRAME[1,*]',frame_value,STATUS)
    Where ENTRY and STATUS are integer data type and frame_value is a POSITION or XYZWPR data type with the value of the new frame