Posts by TitusLepic

    I think that with the RJ3iB, if you save a UF to a PR it always saves in matrix representation. To be sure, see if you have the system variable $PR_CARTREP and if you do, set it to true and ignore the rest of this post.


    The way I do it (I have 50+ programs that have 2 UFrames each) is to put this code at the beginning of my programs:

    Lines 1-5 store 2 UFrame values (we have an asymmetric rotating wall)

    Lines 8-16 selects the correct frame value into a buffer based on a sensor reading which side of the wall is active

    Lines 17-21 further adjusts the frame value based on an argument from the calling program (some of our products are identical, but 2 inches taller) and also adds an adjustment that the operators can manually enter.

    Line 22 loads the modified buffered value into an actual UFrame

    There is a way to check in roboguide; select your program, hit cycle start, and let it generate a profile. When it's done, open the TCP trace you just made, select "color by near axis limit," then select the joint you're interested in and set a tolerance. It will show you potential problem points as shown in the picture below (I set the tolerance to +/-30° just so it would display something for this trace, a more reasonable value would be be +/-5° or so)

    I would look into tying a laser distance sensor (I use a Keyence GV-H45) into an RI and using that as the skip condition, then use ps0p0r's logic for modifying your toolpath.

    Here are two threads with instructions that might help you out with reserializing to the correct software revision:



    It's out of reach. I'm assuming you ctrl+shift clicked there to tell the robot to move, that only moves the XYZ of the TCP to the new point while leaving the WPR as it currently is. Click on the red sphere, the triad should appear. Shift+click and drag on the triad axes to change rotation and you should be able to find a way to make the robot reach.

    Why not just use this method that was mentioned a few posts above?

    Numbers are expressed as the sum of the base raised to a power. For example, using "x" as the base, 375 is 3*x2+7*x1+5*x0. In base 10, i.e. what we use in every day life, you know what 375 means. But if that was hexadecimal (base 16), it would be 3*162+7*161+5*160, equivalent to 855 in base 10. So 25 in hex is 2*161+5*160, or 37 in base 10. So base 10 has 10 numerals; 0,1,2,3,4,5,6,7,8,9, and 10. Base 16 has 16 numerals; 0,1,2,3,4.5,6,7,8,9,A,B,C,D,E, and F. A-F in base 10 are the numbers 10-15.


    So to go the other way, 60/16=3.75. So your first numeral is 3. .75*16 = 12, which in hex is C. So 3C hex is the same as 60 decimal - 3*161+C*160 = 6*101+0*100


    Hope that makes sense.

    Alternately, you could use P[x] points, stay in a single tool frame, and programmatically change the value of your tool frame. (Bad pseudocode example follows)