Posts by Erik Olsen

    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.

    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.

    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.

    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.

    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:

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


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

    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.

    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.

    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.

    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:


    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

    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.

    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.

    User ps0f0r made a few comments regarding the $MOR_GRP system variables and their questionable usefulness in this thread here:



    It seems like most people get around the issue by using variables for motor current rather than torque, these current variables can be found in the same thread.