Posts by TitusLepic

Unfortunately I'm only running V7.70, from the manual "Please note that Position Register object is only applicable to software version v810 or above.

Quote from Sbeve2020

kluk-kluk what do you guys use to format it I think I've used Notepad and Notepad + and it still didn't work

Menu > File > File

[UTIL] > Set Device (make sure you select the USB)

[UTIL] > Format > Yes

Quote from Nation

Are you using ethernet/ip and allen bradly? You could just pull the joint position directly if so. No robot code needed.

Yes. How? From the ethernet i/p manual, I didn't see a way to do it without R822 Enhanced Data Access.

Thanks. I was massively overcomplicating that.

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?

Sadly, this project fell off the radar about 2 years ago and I haven't thought about it since. Sorry.

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).

This ended up having Fanuc tech support scratching their heads too. We think we have it partially figured out; my company bought this robot (and later, the J567 option) from an integrator who apparently mated a M710iC arm (originally with an R30iB controller) to a R30iA controller (originally with an R2000iA arm). Somewhere in there, the integrator messed something up - the Fanuc rep said that R30iA requires a reburn for DCS so he doesn't even know how they generated a PAC code for it. Of course since we went through an integrator Fanuc can't help me directly, they have to deal with the integrator who isn't returning calls or emails right now.

So in short, the PAC code didn't work because you can't install DCS options on an R30iA controller with a PAC code.

My company bought a refurbished robot (M710iC/50 R30iA V7.70). We need DCS pos./speed check, so ordered option J567 through them. Got the PAC code, installed the option, got the following errors:

SRVO-365 DCS FB_CMP alarm(G1,A6) 1,1

SRVO-365 DCS FB_CMP alarm(G1,A4) 0,1

SRVO-365 DCS FB_CMP alarm(G1,A3) 1,1

SRVO-365 DCS FB_CMP alarm(G1,A2) 1,1

SRVO-364 DCS PRMCRC alarm(G1) 1,1

SYST-218 DCS Unavailable robot model G:1 Hex

The one I'm concerned about is the Syst-2018 -

SYST-218 DCS Unavailable robot model G:%x Hex

Cause: "DCS Position/Speed Check Function" option is loaded, but this robot model is not supported. "i" is a hexadecimalvalue and each bit corresponds to a motion group.

Remedy: Delete DCS Position/Speed Check option.This alarm can be cleared by setting $DCS_CFG.$SYS_PARAM to 1, but in this case, Position/Speed Check functioncannot be used.

So if I'm understanding this right, Fanuc sold us an option that isn't supported by this robot? Has anybody ever dealt with this before? I'm waiting to hear back from them, but in the meantime if anybody else has any advice I'd be happy to hear it. I'm only on site for another day so I'm hoping to get a quick resolution to the issue.

Both of you are correct, as usual. Roboguide fast_clock increments every 1ms, but the real robot (R30iA) increments every 2 ms. I did end up cutting out the registers, so my final code on the robot is F[30] = ($FAST_CLOCK MOD 1500 DIV 500)

Thanks for helping me understand this.

Thanks for the insights both of you. I ended up going with the following:

   1:  R[10]=$FAST_CLOCK ;
   2:  R[11]=R[10] MOD 3000 DIV 1000    ;
   3:  F[30:2s ON 1s OFF]=(R[11]) ;

Thanks. I knew it didn't update every millisecond but I had assumed it added 4 to the count every 4 ms. That explains the behavior on the RJ3iB, but I'm still baffled by why it's affecting the pulse output on the R30iA.

I'm trying to create a 2s ON 1s OFF signal that I can use for blinking some lights. I wrote the following code and am running in BGLogic.

   1:  IF ($FAST_CLOCK MOD (3000)<2900),F[30:2s ON 1s OFF]=PULSE,2.0sec ;
   2:  R[10]=$FAST_CLOCK ;
   3:  R[11]=R[10] MOD 3000    ;

F[30] is only pulsing for about half of the time commanded. I.e, a 2.0sec pulse goes high for 1 second, but if I set it to 4.0sec, I get a 2 second pulse. Why? This is in roboguide, on a R30iA (v7.7).

I added lines 2 and 3 to help debug and to make sure that $FAST_CLOCK works how I thought it did, and it does... in the virtual world.

To check and see if the issue is just in Roboguide, I put the exact same program on an RJ3iB I have out in the plant. On that robot, the pulse is 2 seconds as expected, but R[11] takes 12 seconds to count to 3000.

I have a working solution (changing the pulse to 4seconds), but I'd really like to understand what's going on with this code and why $FAST_CLOCK on the real robot is running so slow.