Posts by TitusLepic

    wjnt (wrist joint) is a modifier for a linear move. It maintains a linear TCP track but doesn't maintain TCP orientation.

    Aside from visually confirming that J4 and J6 are lined up, you can usually hear when it's close because both of those joints are moving fast in opposite directions.

    This is how I do it - my first program loops to call the weld program 14 times with a 31.75mm offset between each weld

       1:  R[1:Loop Counter]=0    ;
       2:  PR[2:Tab Weld]=LPOS    ;
       3:  LBL[1] ;
       4:  R[1:Loop Counter]=R[1:Loop Counter]+1    ;
       5:L PR[2:Tab Weld] 100mm/sec FINE    ;
       6:  CALL W_TAB    ;
       7:  PR[2,1:Tab Weld]=PR[2,1:Tab Weld]+31.75    ;
       8:  IF R[1:Loop Counter]<14,JMP LBL[1] ;

    The weld program (W_TAB) stores LPOS to a PR, adds a 20mm offset, then welds to that PR.

    I'm running v6.31 in roboguide 8 on windows 10. I've never been able to translate karel programs in roboguide (the option is grayed out), but I have a copy of WINOLPC+ that handles compiling just fine (in xp compatability mode)

    Two questions:

    1) What does $TPP_MON.$LOCAL_MT = 3 mean? I know 1 and 2, the manual doesn't say anything about 3.

    2) After restarting a condition monitor (program, type 2), will it trigger immediately if the condition is still true or does it only trigger on a rising edge of the true condition?

    What I'm trying to do:

    Monitor a robot for collision. If collision occurs, grab the JPOS where it happened and send that to a PLC. From the PLC, add a timestamp and log it to a SQL database.

    I'm planning on running a condition monitor in my main motion program to watch for a collision fault. When the program execution pauses when the fault occurs, I still want the condition handling program to execute. Per the manual, I need to set $TPP_MON.$LOCAL_MT to 2. Right now, $TPP_MON.$LOCAL_MT is set to 3 and I don't like changing things if I don't understand why they are the way they are. I was expecting it to be set to 1. Once the handling program fires, I'm going to restart the condition monitor. Do I need to add logic to inhibit it from immediately triggering again?

    Or, it there a better way to accomplish what I want to do?

    Share the UI Config screen. My guess is that UOP auto-assign is overwriting your assignment to the flags, but should be able to give a better answer once I see how it's actually configured.

    Can you share your UI Config screen? It should look something like the image below:

    I just set up a robot earlier this month that uses flags tied to the UI; I found out during that project that UI behavior in roboguide is slightly different from UI behavior in the real robot (Mapping UOP to flags).

    UI 14, 10, and 11 will select PNS0038. For PNS0138, you'll need UIs 10, 12, and 16. To select you'll need to pulse UI 17 - turn it on then back off again. To start the selected program, you'll need to pulse UI18.

    What is UOP auto assignment set to (should be near the bottom of the config screen)?

    Hot start retains I/O and program state. It's set from the System>Config menu. I don't know of any reason not to turn of the controller, I've been doing that for 8 years with no ill effects.

    This isn't a robot question per se, so I understand if mods want to take it down, but -

    Huge thank you to all of the contributors on this forum. I just completed my second robot integration and it wouldn't have been remotely possible without all of the information I've gleaned from this forum over the years. I just wanted to make sure that all yall know that the time you spend sharing your knowledge and experience is greatly appreciated.

    How is your PNS mapped? Menu>I/O UOP>Config and share a picture of the UI mapping. Decimal 51 is binary 110011, which is a very odd input to get from a single wire.


    I realize it's been a few months, but figured I'd post the final result here:

    The issue went away for several months, then popped back up earlier this week. (Turns out ignoring problems doesn't actually make them go away). Ended up swapping out the J6 servo and the fault went away. Tried blocking the EOAT as best as possible to keep it from moving, but ended up with a little bit of movement. Here's what I don't understand:

    Recorded the J6 position before powering off. Changed the servo, powered back on. Got a BZAL alarm as expected; the J6 angle reading was about .4° different from when I powered it off. I set master_done to true and calibrated it, then ran the robot to the zero position and put an angle indicator on it to see how far off the mastering was. It was dead on.

    How? I thought for sure that changing the motor/encoder would result in it losing mastering, but it even realized that it moved .4° while I was changing servos. Is this lucky coincidence or is there some sort of electrical wizardry involved?

    In what ways? I'm new to the world of DCS and this R30iA is the newest thing I've ever worked with (both the robots at my plant are Rj3iB).

Advertising from our partners