Posts by Hahonine

If access to winC5G isn't available, using the Filer screen, under Util, Translate you can move a program from binary(.COD) to ASCII (.PDL) allowing you to edit it with any text edit software (notepad etc.). When returning the file to the robot, you can use the same Translate command to turn it back to binary. You must then load the program for it to be used by the robot. This does not afford the same syntax monitoring that winC5G or the IDE do, but it should be sufficient in a pinch for an experienced programmer.

In the same way that you declare VAR, you also use CONST, but with a small change.

VAR

myReal : REAL

mySTR : STRING[63]

CONST

mathPI:=3.141529

companyName:='Comau'

You must assign value to the constant immediately upon declaring, and the constant cannot be edited by the program after declaration.

When you go to the IDE panel on the C4G controller, try giving it time to load all the interface on the pendant before selecting a program. I had a similar issue on a C4G piston stuffer robot a few years ago. The more programs loaded the longer it will take, so I suggest open the Program pane and wait 10 minutes or more.

I hope this code snippet helps with what you're trying to do:

    VAR signalgi groupSet{10};
    VAR num index;
    VAR num signalInput;
    
    PROC initSigGIArray()
        CONNECT groupSet{1} WITH gi_1;
        CONNECT groupSet{2} WITH gi_2;
        CONNECT groupSet{3} WITH gi_3;
        CONNECT groupSet{4} WITH gi_4;
        CONNECT groupSet{5} WITH gi_5;
        CONNECT groupSet{6} WITH gi_6;
        CONNECT groupSet{7} WITH gi_7;
        CONNECT groupSet{8} WITH gi_8;
        CONNECT groupSet{9} WITH gi_9;
        CONNECT groupSet{10} WITH gi_10;
    ENDPROC

    PROC useIndex()
        initSigGIArray;
        index := 0;
        signalInput:=0;
        FOR index FROM 1 TO 10 DO
            signalInput:=groupSet{index};
            !Do what you need to with the group input here
        ENDFOR   
    ENDPROC

The routine links IO variables in the program to the actual IO configured ion the EIO.SYS file. This allows you to reference the signal via array index using the index variable.

Quaternions are described by a set of 4 values between 0 and 1 (Q1,Q2,Q3,Q4)

(Q1*Q1)+(Q2*Q2)+(Q3*Q3)+(Q4*Q4)=1, or the angle doesn't exist (or doesn't make mathematical sense).

When I generate this error, it's because I input the Q values manually to try to force a specific angle. Either the 4 squared Q values don't sum to 1, or the angle isn't achievable WRT the robot base (the Q values show an angle reflected over the origin).

Try re-running the calculation, or using a different Quaternion calculator.

Skooter, Doctor_C, thanks for the help.
I used the information about error codes to hack out this KAREL snippet:

  WRITE TPDISPLAY(CR, 'Insert USB device into UD1: to begin transfer.') --CR is a special Carriage Return character
  --Start condition (USB inserted into UD1:)
  WAIT FOR ERROR[USB_INSERTED]
  WRITE TPDISPLAY(CHR(128),CHR(137)) --Clears the TP display buffer
  Start_Copy
  WRITE TPDISPLAY(CR, 'Transfer complete, remove USB device from UD1: to continue.')
  --Stop condition (USB removed from UD1:)
  WAIT FOR ERROR[USB_REMOVED]
  WRITE TPDISPLAY(CHR(128),CHR(137)) --Clears the TP display buffer

The constants USB_INSERTED/USB_REMOVED correspond to 2066 and 2067 respectively. Start_Copy runs the transfer scenario. I made it a KAREL Routine to allow different activites to be changed out as needed (copy to, copy from, copy and delete, etc.).

Hello,
I am seeking information on a system variable in a Fanuc robot that changes state when a USB device is plugged in or unplugged. I'm aiming to use these events to trigger BG logic when a device is plugged in.

Edit: Going by other robots I have used that are done in PDL, I believe the system variable I need would tie into the EVENT command (in Comau Robots, plugging a USB into the cabinet USB port triggers Event 155, where unplugging it triggers event 156).

~Luke S.

What I'm getting from this is that there is no known way to couple the mode selector with internal logic to prevent the robot from instantly dropping to manual mode when the selector is turned. Thanks for the help anyway.

@Lemster While that was my first thought too, my assumption is that the local operators will have a copy of the key on hand. I'm basing this assumption on years of experience

We have an IRB 6700 robotware V6.XX.XX, and we wish to restrict the ability for anyone with a selector key to switch the robot into Manual mode mid-cycle. Our goal is to change the mode selector to require both the switch and an internal signal (or an output from the I/O board). My gut tells me this isn't possible as the mode selector is a safety feature, but I thought I would ask here just in case.

Comau PDL2 (PASCAL derivative language 2) and Fanuc KAREL are both PASCAL derived, and very similar. Write the program either in the pendant, or in a txt ASCII file on a computer (save as ext .pdl), and use filer>utility>translate on the *.pdl to compile from the robot pendant.

If you are concerned with the speed% displayed on the pendant, use $GEN_OVR := 50 (for 50%) instead of ARM_OVR. ARM_OVR will modify the program speed, but will not display at the top of the pendant.