Posts by HawkME

    I recommend making a sharp pointer that you can attach (repeatably) to your tool. Teach a tool frame for that first.


    Then with that newly taught tool frame active you can teach your user frame. It isn't possible to teach an accurate user frame without the tool first because you are using the TCP to teach the user frame.


    The robot only knows itself, or rather an internal model if itself. When you teach a tool frame then it now will know where that pointer is relative to itself. Then when using the pointer to teach the user frame it will now know where the conveyor is relative to itself. It all builds together.


    The best place to put your origin (and x+ and y+ points) is where you can repeatably do it again in the future and it lines up straight with your conveyor. I prefer to attach or punch a physical point into the object such as a side wall of the conveyor.


    3 point Tool and 3 point user frame is the standard and is perfect for most applications.

    That translation logic doesn't look right to me. The problem with any direct modification of a user frame is that you are modifying relative to world. So if your world is not planar with the user frame then you will be rotating on a tilted axis.


    You have 3 options:


    1. I think there may be a program utility to shift/rotate/mirror programs you could try.


    2. Just teach 2 separate programs.


    3. Use Matrix math to correctly rotate the frame relative to the current UF position.


    UF[1] = your original user frame.

    PR[1] = your adjustment values


    PR[1,6] = 180 (degrees) which will rotate about your UF origin.

    PR[1,1] likely needs to have a value to translate back due rotation about your origin

    PR[1,2] likely needs to have a value to translate back due rotation about your origin


    UF[2] = UF[1] X PR[1]


    (the X above denotes matrix multiplication).



    The problem with #1 and #3 is that it probably cause your tool to rotate 180 degrees as well. I'm guessing you don't actually want that. So solution #2 is probably the simplest and easiest. It appears you only have 6 points per part. Sometimes simple is good.

    Most robots don't have the SkipJump function but instead have the more standard Skip function.


    Skip and SkipJump are really the same thing, just reverse logic of eachother. So there is no real need to have SKipJump.


    You can add a Skip command onto every motion and if the condition comes true then it will stop motion then skip to the next line of code. If the condition never comes true then it will finish the motion then jump to the label.


    If you prefer the system monitor then keep reading:

    There is a workaround to triggering motion with a system level condition monitor. Your action program must abort the current program then turn on a signal that starts a macro. You must use flags and UOP signals to make it work. In the example below F[1] is mapped to UI-Cstopi and F[2] is the trigger for the macro with your motion in it.


    Set these system variables:

    $TTP_MON.$LOCAL_MT = 2
    $TTP_MON.$GLOBAL_MT = 2


    Code

    Code
    :  WHEN DI[1]=ON, CALL ACTION_PROG ;


    ACTION_PROG.tp (Group Mask = *,*,*,*,*):


    Code

    Code
    :  F[1]=(ON) ;
    :  WAIT 2.00(sec) ;
    :  F[1]=(OFF) ;
    :  Wait 1.00(sec) ;
    :  F[2]=(ON) ;
    :  Wait 1.00(sec) ;
    :  F[2]=(OFF) ;
    :  Wait DI[1]=OFF ;
    :  Monitor SYSTEM_MONITOR ;

    You can multithread your VB code to do multiple robots at once with FTP. You have to use the dotnet FTP methods not the the ftp.exe script.


    It won't be any faster though. Even if multi-threaded, the FTP connection will only service 1 robot at a time, it will just bounce between the different connections. So for example if you have 3 robots to backup and they normally take 1 minute each. If you do 3 at a time asynchronously then they will all happen at the same time but still take 3 minutes to complete.

    I'm not sure if there is a way to prevent that systematically.


    Even if you prevent fwd/bwd they can still press the up down arrows to put the cursor on a different line.


    I say either lock the TP in a box, or monitor TP enabled in BG Logic or your PLC.

    How are you starting the robot? If you are using UOP, then simply don't provide the operators with a resume button. If they turn the teach pendant on and off then you can force them to start the program over from the beginning.

    You are on the right track


    Do everything you stated, then:


    Set Production start method = UOP


    Use UI 18 to start the main program.


    Setup a UI for cstopi and set abort all by cstopi to true in the system config menu.


    Setup a UI for reset.

    There is an option you can purchase for expanded storage. R798 DRAM file storage. I believe that would give you plenty of storage.


    Another option would be to setup an FTP server and interface to send files. That option would be much more complicated.

    You didn't mention your controller model.



    Usually when people run out of memory they are either using generated code from a CAM software or are not using correct programming techniques. I have done very complex and elaborate programs that were under 200kb.

    To anyone with the same problem,

    The input and outputs go through message blocks in the PLC.

    EMSSTC

    This is the case in your situation. That doesn't mean it's the same for everyone else. This communication could be done many different ways.


    1. PLC message

    2. PLC Ethernet digital IO

    3. PLC hardwire

    4. Robot to robot comm

    5. Robot to robot hardwire

    6. PC comm


    There are probably others I didn't mention. It is a custom program so others with the same problem must understand their system setup first.