Posts by TitusLepic

    This is only working for controllers with software version older than V9.40. Since software version V9.40 there is a new DCS parameter called "TP Enabling Dev Reset" which secures the $DMAURST variable.


    When changing TP Enabling Dev Reset to ENABLE then $DMAURST automatically also changes to TRUE.


    If the parameter is set to TRUE it is only possible to automatically reset the "Deadman released" alarm. Other alarms reuire to push the reset button.

    Thanks, good to know. All of my experience has been on older controllers.

    That's normal. Set $DMAURST (deadman auto-reset) to true if you want the fault to reset when you pull in the deadman instead of requiring a push of the "reset" button.

    Here's how I do it using bglogic and a macro in one of my robots - replace F[24] with your DI (I have a bit of logic requiring the button to be held for 3 seconds before triggering the robot to go home, which is why it's a F instead of DI in this code snippet).


    Code
      12:  !Auto-Homing ;
      13:  IF (F[24:Go Home]),F[14:Cycle stop]=PULSE,0.2sec ;
      14:  IF (UO[6:Fault] AND F[24:Go Home]),F[33:GoHome FaultClear]=PULSE,0.2sec ;
      15:  IF (F[33:GoHome FaultClear] OR F[40:FaultClear Delay]),F[40:FaultClear Delay]=PULSE,5.0sec ;
      16:  IF (F[24:Go Home] AND !F[14:Cycle stop] AND !F[40:FaultClear Delay] OR F[41:GoHome Trigger]),F[41:GoHome Trigger]=PULSE,1.0sec ;
      17:  IF (F[41:GoHome Trigger]),F[42:GoHome Delay]=PULSE,0.2sec ;
      18:  F[25:Call GoHome Macro]=(F[41:GoHome Trigger] AND !F[42:GoHome Delay]) ;

    Here are a couple of articles that explain what is causing your robot to behave the way that it is.


    How is Orientation in Space Represented with Euler Angles? | Mecademic Robotics
    Learn how orientation in space is represented with Euler angles and understand their importance in defining tool reference frames.
    www.mecademic.com

    Understanding Gimbal Lock and how to prevent it


    As you noticed, creating the UFrame at a 45° offset to world gives you the behavior you want. I have no idea what your process or part geometry is, but if it's possible to define your UFrame that way that would be the easiest solution.

    You could also set up a condition monitor to look for this condition.


    in your main program, MONITOR condition_monitor_program


    your condition_monitor_program should look like this:


    WHEN ERR_NUM = 15370, CALL alarm_reset_program


    at the end of your alarm_reset_program, MONITOR condition_monitor_program

    I'm not in front of a robot right now, but here's some pseudocode that will do what you want by looping and offsetting the UFrame each iteration. I know newer controllers support FOR loops, but I'm used to being forced to work with jumps and labels so that's what you get.

    Code
    PR[x] = P[1]
    R[x] = 0
    LBL[1]
    UFRAME[1] = PR[x]
    call weld_program
    R[x] = R[x] + 1
    PR[x,1] = PR[x,1] + offset_value
    IF R[x] < number_of_fences JMP LBL[1]
    END
    P[1]


    Alternatively, you could use PR offsets in your weld_program after each point - P[x] motion instructions OFFSET PR[x] and just increment as shown above. That would look something like this:

    Code
    PR[x] = LPOS
    PR[x] = PR[x] - PR[x]
    R[x] = 0
    LBL[1]
    call weld_program
    R[x] = R[x] + 1
    PR[x,1] = PR[x,1] + offset_value
    IF R[x] < number_of_fences JMP LBL[1]
    END
    P[1]

    If I'm understanding right, you want the exact same program to run relative to whichever user frame is active? This is how I do it - keeping the values for the two frames in P[1] and P[2] then copying the appropriate value into UFrame[1]. This way you only have to maintain one program.

    DOUT is a predefined port array. You can address it as if it were an array because it is one.


    UseZone is not a declared array. Therefore you can't use array addressing.


    To do what you want, you could do the following:


    1) declare UseZone as an array.

    UseZone: BOOLEAN[2]


    2) Use a select statement

    SELECT n OF

    CASE(1):

    UseZone1 = True

    CASE(2):

    UseZone2 = True

    ELSE:

    ENDSELECT


    3) Do the same thing with if statements



    Without any further information about what you're trying to do, I would recommend declaring UseZone as an array and going that route.

    Looking through my FRAMEVAR.VA, I found this. The highlighted positions are the three points defining my origin, x, and y (positions are world 0). I don't know how to make use of this information, but it's definitely there.


    edit: posting this removed the highlighting. COMP_POS1.NODEDATA[13].NODE_POS, COMP_POS1.NODEDATA[14].NODE_POS, and COMP_POS1.NODEDATA[15].NODE_POS are origin, x, and y, respectively.


    edit #2: I looked at another robot and on that one, it's 7, 8, and 9 instead of 13, 14 and 15.

    Weird that it isn't even showing analog in the menus... do you have quick menus enabled instead of full menus (Fctn > next > quick/full menus)?


    What interface card are you using? Are you sure that the interface card is getting 24V? Have you made sure that your K1X cable is connected to JD1A on the controller and JD1B on the interface card?