Posts by JMF

    double click on the weave data in your instruction or highlight then debug view value or go to program data, weavedata find your weavedata and edit it there. If its not there it might be removed or even might've been declared as LOCAL data inside a module.

    What do you mean by welding size? Have you tried adjusting your weld speed? Have you tried increasing your wirefeed speed and your voltage? Have you perhaps used VelSet instruction somewhere as I found that after this is instruction is executed, it will influence some movements. I would also verify the current system against the old system to check for any irregularities in system procedure parameters.

    What I've done is to declare Global items inside System Modules and they are always active on the system. I do add "NOVIEW' declaration to the ones that I do not wish the operators should be able to modify. Then my Part modules is separately loaded as required from the HDD and inside them is all data required for the use in that Module. At the end of the day if you can keep your modules and routines nice and tidy and know what is going on, it should be good.

    Yes, you can run multiple tools in the bullseye. Each will be required to be set up at start. When running, you will have to manually change the tool in the quickset menu. After selection you can create a procedure that will check the current data of the current tool, evaluate then run the correct bullseye routine.

    Something like this sample.

    Add your commands for when the sensor is 1, between the IF DInput(sensor1) and the ELSE instructions and the commands for when the sensor is 0, between ELSE and the ENDIF instructions.

    Try to add "CornerPathWarning FALSE;" before line 499 and "CornerPathWarning TRUE;" after line 503. This suppress the corner path warning and error.

    Add this in your Main Routine. The Manuals give examples of WHILE & FOR loops and IF statements. Can read up on it.

    WHILE DInput(sensor1)=0 OR DInput(sensor1)=1 DO
         IF DInput(sensor1)=1 THEN
             TPPrint "Robot Running";
             TPPrint "Robot Not Running";

    VAR num nClock;

    VAR clock cClock;

    PROC BlahBlah()

    ClkReset cClock;

    ClkStart cClock;

    ! Procedure instructions

    ClkStop cClock;


    TPPrint "BlahBlah Procedure took: "+NumToStr((nClock/60),3)+"minutes";



    Yes your idea is correct. See example below

    P1 - 12 o clock

    P2 - 3 o clock

    P3 - 6 o clock

    P4 - 9 o clock

    ArcLStart P1,v100,Seam1,Weld1,fine,tWG_Straight\WObj:=wobjShapes;
    ArcC P2,P3,v100,Seam1,Weld1,fine,tWG_Straight\WObj:=wobjShapes;
    ArcCEnd P4,P1,v100,Seam1,Weld1,fine,tWG_Straight\WObj:=wobjShapes;

    Ok then, let's try another. Did you know this one? | makes the argument exclusive. For example,

    PROC one(\num nON | num nOFF)

    I have never tried this way before but it seems to be something that I can use. :/

    It just shows that the overall usages of Rapid capabilities is almost never ending.

    Lemster68 - He specifically wants to remove the routines from the available list when PPtoRoutine but when I try to add a parameter to the Routines, the Routines is still available in PPtoRoutine list but they will not do anything cause the parameter have not been set yet. This is why I have suggested the Load/Unload function because it removes the Routines completely and they are not available at all unless his rTeach Procedure has been executed.

    Have I missed something that the Routines is still showing in my testing procedures?