Posts by Erik Olsen

I would say it's still worth reaching out to Fanuc, but I have had issues with grease pooling in the bottom of j2 reduces on M410s and particularly M900s in the past. It didn't necessarily manifest in controller noises or OVCs, but I've gotten some horrible growling and popping from the reducer and plenty of false collisions detect alarms that become more frequent as speed increases. Usually, I spend a couple of minutes exercising the J2 reducer in T1 mode, followed by an hour or two or running a J2 exercise routine at auto speeds and it clears up.

Again, reach out to fanuc first, but don't be supprised if their answer is "J2 just does that, run it for a bit and it will clear up"

As long as no hardware has changed, Reload SYSMAST.SV and avoid the zero position mastering.

Zero position mastering by eye using the witness marks is a sad way to master a precision machine.

Quote from NortheyTech

Robot Controller R-30iB Plus. Trying to open the Comment Tool from browser.

Anyone know what the default username and password is.

Thanks.

Does your robot have the password option installed?

I think when the password option is added, the HTTP access settings default to AUTH access for all resources. If not, then someone could have gone into to [MENU] -> 6 "Setup" -> "HOST COMM" -> 7 "HTTP" and manually set resources to lock/auth, but I find that to be pretty unlikely.

If you do have the password option installed, then the password prompt you see in the web browser should use the same passwords as the robot. You will just need to log in as setup/install levels or whichever level is configured with privileges to make changes.

Quote from Rodrigo Martinez

Eric, did you find out how to generate TP programs for multiple features simultaneously?

Unfortunately No, I did find a setting under roboguide option->CAD To Path->Tp Program Generation that generates a new TP Program anytime a change is made to a feature segment. But I often found that the delay this caused after every change made it more annoying than useful.

I think the best bet is lots of clicking, unfortunately.

Quote from massula

If I recall correctly, I saw a FANUC brochure telling their OS is Unix based.

They used this as a selling point, since "if it is not Windows, it can't get viruses", or something like this.

Enviado de meu SM-N910C usando Tapatalk

Unix-based seems likely. Fanuc ls and Karel source files use "LF" line ending rather than "CRLF" which would be expected from something DOS based.

Quote from Nation

On newer controllers, I've started using the multi-lang remark (--) instead of the orignal remark (!). You can practically write a novel in those.

I think that's the only reason why anyone would ever use them. I've never tried it myselft, but I've heard truly horrible things about how the "multi-language" feature actually translates things. Most people I've worked with eventually just call them multi-line remarks instead of lang.

Quote from Racermike123

The EE cable ends up terminating through the Pulse cable connection at the Servo Amplifier.
Unless you have an LR mate.

Or a Scara, and I think the Delta robots?

Quote from HawkME

Shouldn't you be writing to DIs, not DOs? The robot should be the only thing that can turn on a DO not an external source.

I think HawkME is correct here. The status of your robot DO's arent changing on the teach pendant because they probably aren't changing at all. I'm not 100% sure that something like SNPX or PCDK cant change robot outputs externally but I wouldn't be surprised if they couldn't.

If you wanted, you could map to some robot DI's and then use the IO-> INTERCONNECT feature on the robot to map those DI's directly to some Digital Outputs. A little bit of extra work on the robot side but this should pass your HMI signals through.

Quote from JohnnyBoy2569

Sorry for the late reply unfortunately i cannot use this code as I'm not allowed to enter the Karel program, is it possible to use a background program to disable the DI option ?

You could also map/assign a digital input to the robots always on rack (Rack 35, slot 1) but I think the system variable suggestion here is a bit more elegant.

Putting this simply for anybody just skimming this thread:

DO NOT RUN THE ROBOT IN AUTO WITHOUT THE FENCE CIRCUIT ENABLED!!!!

Not even macros and especially not as a long-term solution. Running the robot in Auto with the fence open or an incomplete fence is something we integrators/programmers try really hard to avoid even when commissioning a new piece of equipment. Trying to do it as a permanent solution for production is completely insane and I'm refraining from cussing you out merely because I assume you just didn't know/haven't learned this yet.

If this window is actually out of reach of the robot and is properly interlocked with the laser itself, then you just need to make the physical wiring change to remove it (and only the window) from your robot fence circuit. You should also do a proper safety/risk assessment of the cell prior to and after making any changes like this.

Unless I'm reading it wrong, I think it's because you are getting the register value using the "RegLong Property". Long data type is for integers only.

The Fanuc PCDK documentation has a description for the property stating this:

Quote

FRCRegNumeric.RegLong Property

Description:

Returns/sets the long value for the numeric register.

Syntax:

[lngRegInt = ] objNumReg.RegLong

Parts:

objNumReg as FRCRegNumeric lngRegInt as Long

Remarks:

This property will raise an error if it is read when the type is not INTEGER (Type property is not frIntegerType). When this property is set the register type is automatically converted to INTEGER (Type property is set to frIntegerType).

Display More

To get the floating-point value of a numeric register, you will want to use the standard RegNumerics Property here:

Quote

FRCRobot.RegNumerics Property

Description:

Returns the robot numeric registers.

Syntax:

[objNumRegs = ]objRobot.RegNumerics

Parts:

objRobot as FRCRobot objNumRegs as FRCVars

Remarks:

This property provides access to the numeric registers of the controller. These registers are typically accessed from TP programs.

See Also:

FRCRobot Object Overview FRCVars Object Overview FRCVar Object Overview FRCRegNumeric Object Overview

Code

Example of getting the numeric registers 

Dim objRobot as FRCRobot 
Dim objNumRegs as FRCVars 
Dim objNumReg as FRCVar 
Dim objRegValue as FRCRegNumeric 
Dim lngValue as Long 

Set objRobot = New FRCRobot objRobot.Connect "robot1" 
Set objNumRegs = objRobot.RegNumerics 
Set objNumReg = objNumRegs(1) 
Set objRegValue = objNumReg.Value 
lngValue = objRegValue.RegLong

Display More

`Example of getting the numeric registers Dim objRobot as FRCRobot Dim objNumRegs as FRCVars Dim objNumReg as FRCVar Dim objRegValue as FRCRegNumeric Dim lngValue as Long Set objRobot = New FRCRobot objRobot.Connect "robot1" Set objNumRegs = objRobot.RegNumerics Set objNumReg = objNumRegs(1) Set objRegValue = objNumReg.Value lngValue = objRegValue.RegLong

Display More

All of this and more is available in the PCDK documentation that came with the dev kit download btw .

Quote from png

Thanks for replying, you guys but I am aware of modifying the configuration string. I was in search of overall conversion, system-wide so that I don't have to do this for every point.

If you have the ASCII upload Option or Roboguide you could save your programs as.LS and edit all the point configurations in the program footer in a text editor. This would probably save you some time versus editing everything on the pendant.

Quote from Jesus

The teach positions change after some hours by them self. Every position moves up about 2 inches out of nowhere. We mastered the robot, replaced the motor of axis 3 (which is the one that moves the arm up and down), replaced path cpu, axis and shared ram board. Is this a mechanical issue or electronic? Thank you in advance

First, let's establish what you mean by "teach positions change". Have you looked at the actual values of a taught point position and confirmed that the numbers changed? Have you checked the values of your user and tool frames and confirmed that they are staying constant? Or are you just observing the robot path is moving in an undesired direction?

I would say that most of the work you have done so far is overkill or a complete waste if you don't under if this motion is resulting from physical (very unlikely especially moving more than 2 inches) or a program/frame change.

Quote from JohnEP1992

I have a problem with a fanuc paint robot Where axis 5 6 and 7 all have limit error faults when I try to jog in the negative direction in joint. Even though they are all within the axis limits. Motion 017 is the fault. The fault that started all of this was a SPHAL. Any ideas?

This thread: SRVO-068 DTERR /069- CRCERR /071-SPHAL (Group:01 Axis:06) ALARM dives into recovery from a SPHAL fault, and I have seen robots with incorrect/no mastering throw limit errors when jogging well within limit values. It may be an issue with an encoder/cable.

Quote from shriraj lonkar

NO

I WANT TO AVOID COLLISIONS ONLY DURING THE MANUAL JOGGING TO PREVENT THE GRIPPER FROM DAMAGE

As user pdl pointed out, DCS would be the easiest way to do this. It looks like you have a CR-15 collaborative robot, and unless I'm mistaken that should require the DCS option?

Here is a quick example Joint Position Check (Joint Limit) I set up in DCS that should be what you are looking for:

Ignore the "Invalid Axis is selected" message. I whipped this up in a roboguide cell with a SCARA in it. Also, note that I am using the AUTO mode SSI to disable this joint position check, meaning it will only limit the robot in T1/T2 mode.

If you somehow don't have DCS, or really want this to run in a BG program, you could use the SOP Teach pendant enabled output status, along with constantly checking the robot JPOS against a range of limit values. If the robot joint 5/6 pos is outside your limit, through a UALM. This would be quick, dirty, and not very fast but it would probably also work for you.

I think Fanucs DPM/Dynamic Path Modification option is one way to achieve what you are looking for.

Quick and dirty would be just looping a short <1mm Incremental motion option move until your robot position matches your desired offset.

Crappy psudo code:

LBL 1

IF Pushcorp Sensor is positive of center THEN 
//Move  +1mm 
L P[1] 100mm/s FINE INC 
}
ENDIF

IF Pushcorp Sensor is negative of center THEN 
//Move  -1mm
L P[1] 100mm/s FINE INC
ENDIF

JMP LBL 1

but keep in mind that short arc and repetitive motions can cause wear issues in the robot SV/Harmonic reducers. I'm not sure exactly what your application looks like, but you will typically want to allow the pushcorp/compliant device to take up most of the small variations

Quote from mekeale

Is 4 points training more accurate than 6? Tomorrow I will re-master the payload and calibrate according to the above instructions, followed by 4-point training.

My understanding was that the 6-point tool teaching is only as accurate as a 3-point tool teaching, but provides the added benefit of teaching orientations, not just an offset. 4 point teach method is technically just a 3 point teach that picks the closest 3 points to generate an offset and informs you how far out the worst, unused 4th point was from the others.

Somebody chime in if I am incorrect.

Quote from mekeale

may affect incorrect PAYLOAD?

Having very accurate payload and inertia values should help your robot's accuracy and repeatability. Would you try teaching a 4-point TCP and tell us what mean and max errors you are getting?

Quote from 4wheeled

Well, we thought the problem is solved, but it isn't. It just had an improvement, but when we taking longer data, the system still shows instability. So with %delay=0, the instability which occurs every 100ms or so is gone. But the problem shows up at a much less frequency, see the plots attached. It must be the system wonders around doing some extra stuffs. （The X axis is count and the Y scale is usec)

I assume the controller is still occasionally performing some lower-level functions that result in this instability. If consistency in your application is more important than raw polling rate, then it may be worth trying to add your own short wait that occurs every cycle, while still keeping the %delay at 0. This might give the system time to perform other operations without causing an unpredictable, longer cycle. Try increasing the length of this wait until the instability is gone or you are no longer cycling fast enough for your application.

It might also be worth exploring running something like FreeDOS instead of DOSBox. Might be a little more stable running continuously vs a VM.