Posts by Erik Olsen

Same Issue. I'm guessing that (similar to importing large iges models) this tool is old and designed for models with very simple geometry. Hopefully, version 10 comes soon and improves on all of this.

Do you do anything specific for the end of run on the day prior? Im wondering if an end of run/perch position on your robot is 180 degree or more out from your desired pick/place orientation. PalletPro programs often use the MROT instruction which will intentionally ignore the wrist turn configuration, this is nice for avoiding "helicoptering" or spinning the tool uncessiarily, but it also means that depending on the starting position of the motion the robot tool can end up 180 or 360 degree away from whats expected.

This is the second time in 5 years that I have accidentally encountered this issue, and I wanted to add a forum post to document its solution. When using PalletPro, don't try to get cute with the name of PLONPAL.TP if you want the simulation to work. There have been times when the path from infeed to build stations in a 2-cycle cell has been so different that I have decided to just create two different PLONPAL (example: PLONPAL1.TP, PLONPAL2.TP) programs rather than turn things into a branching mess. Both times I have done this, it has screwed up the roboguide simulation. Even though both copies of the PLONPALx.TP program contain the normal calls to TLK2PP,PMADDQ,PMDSPSPD,PMCHGPLD and whatever other supporting Karel programs are responsible for updating variables behind the scenes, something about changing the name does not jive with palletPro. Everything works fine running on the real robot, but the simulation does not update properly.

The issues caused by changing the name include cases not advancing down the infeed after each pick, Unit pres inputs/Ok2pick signals remaining on even with no cases at the in feeds, and units disappearing from the pallet after the place.

I'm not sure if similar issues happen when changing the name of default pallet tool programs.

Hopefully this helps somebody else (or me in another 5 years).

Quote from edimmy

picked "previous profile" or something along those lines (the other option was SR-6iA [...] but I didn't know which one to pick), plugged in my USB with a backup, and tried to restore but got the message "directory is not processed".

Do not select the previous profile; select SR-6iA. Not sure if that's your whole problem but the software install quick start guide is pretty insistent that select the profile that matches your robot model.

That's definitely a head-scratcher.

What changes were being made with these new OLPs? You mentioned that the GP1 /POS data is the same between the new and old programs, so what was being changed? Which line of motion was going to collide?

It's hard not to be suspicious of something happening in MAKRO or P-SPS, but I'll take your word for it.

If you can, send the old (currently running) version of prog081.ls as well.

Providing the TP programs (if allowed) or even snippets of the logic and /POS data would be helpful. Additionally, a list of software options installed on the robot that could potentially cause some strange behavior (Coord Motion Package, Multi-Group Motion, Interference Check, etc) might give some clues. Lastly, are you running any custom Karel scripts on the robots?

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.