Posts by SHIFT_Lock

Quote from daniel.piton

Ola meus amigos do forum eu trabalho com 3 robos fanuc 100ic e um 120ic ,nos aqui não consiguimos configurar coretamente a função TAST ,TRACK, alguen que saiba possa me ajudar ja tentei varias configuraçães mas sem susseço se alguem puder me ajudar com a configuração do TAST eu agradeço .

I did a rough translation from Portuguese to English to see if anyone can help him.

"Look my friends from the forum, I work with 3 fanuc robots 100ic and a 120ic. In here we cannot setup fanuc fancy TAST, TRACK, who knows can help me? Already tried various configurations but without success. If someone can help me with TAST configurations please."

https://www.robot-forum.com/ro…faults/msg95994/#msg95994

Check this thread out it may help you. Or search for "FSSB" in the forums and there are a coupld other threads as well that may be worth reading.

Quote from icontrol

this message comes up when the encoder position at which the robot stopped is different from the one it is trying to start from. it can the result of bad motor break or a very violent stop.it won't be wise to get rid of the message. also when ever the message pops up make sure to manually move the robot to a known position and then continue. as SHIFT_Lock pointed out crashes might be the result of waits being skipped or moving the robot manually and not putting it back into the program.

I agree, the entire point of this pop up screen is to ensure the operator knows that the robot is starting in a different position than it stopped at to avoid crashes.

Our newer fanucs have this on them but it will only come up if someone has stepped it through the program. If you open a gate or something and don't do anything with the robot it shouldn't come up. This alarm probably isn't the reason the robot is crashing though. The problem lies with the operators probably skipping I/O's or waits and then starting the robot up again in a new location without completeing it's task. I.E. if the robot is waiting for IN20 "Ok To Drop" but the jig clamps aren't opened yet and someone skips the Wait and then selects "Continue" it'll come crashing into the jig with the clamps closed. Or collide with another robot that did get its "OK To Pick". Some of our technicians are absolutely terrible about doing this.

Quote from ThatGuy007

I should have mentioned that there is no amp for a 7th axis anymore. I also went into controlled start and changed the app select from spot to material handling. could the issue be there because of the servo amp that was removed or from the main amp.

also where do i look for number 11 at???

11: Invalid axisorder setting. Non-existing axis number is specified.

Yes as pdl suggested that is probably your problem.

SRVO-223 DSP dry run (%d,%d)
Cause: A servo DSP initialization failure occurred due to hardware failure or wrong software setting. Then, the software
entered DSP dry run mode. The first number indicates the cause of the failure. The second number is extra
information.
Remedy: Perform an action according to the first number that is displayed in the alarm message.
1: This is a warning due to $SCR.$STARTUP_CND=12.
2,3,4,7: Replace a servo card.
5: Invalid ATR setting. Software axis config (FSSB line number, hardware start axis number, amplifier number, and
amplifier type) might be wrong.
6: SRVO-180 occurs simultaneously. Controllable axis does not exist on any group. Execute aux axis setting to add
axis at controlled start.
8,10: SRVO-058 (FSSB init error) occurs simultaneously. Follow the remedy of SRVO-058.
9: There is no amplifier that is connected to the servo card.
• Check the hardware connection.
• Check the optical fiber cable.
• Check whether the servo am plifier power is supplied.
• Check whether the fuse on the servo amplifier has blown.
• Replace the optical fiber cable.
• Replace the servo amplifier.
11: Invalid axisorder setting. Non-existing axis number is specified. Software axis config (FSSB line number) might be
wrong or auxiliary axis board is necessary.
12: SRVO-059 (Servo amp init error) occurs simultaneously. Follow the remedy of SRVO-059.
13,14,15: Document the events that led to the error, and contact your FANUC technical representative.

Your SRVO-223 was followed by 9,1. It would appear that the servo amp is a likely cause. Have you checked everything out as far the remedy in bold goes?

Quote from dofrey

Hi Ahmed

Just press the STEP button on your TP keyboard. It should change the yellow STEP status to green.

Step can be used to go slowly and controlled to your robot program for testing. If you are in STEP mode (yellow) you can press SHIFT+FWD and the program will execute one line of code and stops again. This can be quite useful sometimes!

I can't count the times i've left a robot in step while trying to get the line to auto run

I usually run through a program in STEP mode to ensure I don't fire any outputs when i'm teaching points.

I don't know if this is a system variable or what but a lot of our lines won't even go into auto run mode with STEP mode active on a robot. Some will allow us to go into auto but the robot won't run.

Lemster68 has a very valid point. Pulling a gate key will de-energize the line and things will often "shift" around a bit. Something else that sticks out to me is that you were dealing with "chain Faults" which are safety faults regarding the TP deadman, safety gates, e-stops ect. Did you do anything to fix that issue? It's possible that the two are related in some way though I don't exactly know how??

DTBR-014 STOP.L Bad variable or register index (%s)
Cause: Specified register or position register doesn’t exist on specified host.
Remedy: Please check parameter. Please check valid range of index of specified host.

Maybe when you remastered you lost your position register data?

Quote from Adinath Gurav

SRVO-069 CRCERR alarm
(GRP-:1 Ax-3)
Line 32 Aborted

What’s app-: +918600075877

Display More

Are you looking to just clear the alarm or is this a repeat issue after clearing? To clear the alarm turn the pendant on and hit FCTN>0>8 and a prompt will come up asking if you want to cycle power then hit yes. If this is a repeat issue i'd say start with the pulsecoder cap/cable. We deal a lot with SRVO-068 alarms and when the SRVO-069 alarm shows itself it's almost always the cap/cable. What we do first is swap the cable or simply disconect it and reconnect it then recalibrate and it's usually good for a while. You can search the forums for a lot more info on this. Just search SRVO-068.

I'm sorry I can't help with that part but I do believe there is something you do with the CSTOPI as far as tying the collision to an output but i've never messed with that. I believe that topic has been covered before and should be easily found by searching. I was more focused on the part of your problem regaurding the chuck closing signaling a collision and thought maybe lowering your sensitivity could help you with that. Hopefully someone else will chime in with some more knowledge!

Menu>Setup>Coll Gaurd will give you controll on the sensitivity settings. The range is 0 - 200% 0 being off and 200 being much more sensitive. Just be careful with this. I'd start with small increments.

You can change the axis limits in Menu>Next>System>Axis limits then cycle power after a change is made.

Stroke limit i've never messed with but it looks like you go into system variables $MRR_GRP[2] then $SLMT_J1_NUM and it'll tell you your current limit. Maybe you can change it there. I found this under Menu>Setup>Stroke Limit. Hope this helps.

Quote from Senthil84

Racermike , thank you for the inputs. I did not disconnected the cable. When I move the cable itself , the fuse was blown. After replacing with new cable , the problem is solved. Strange, but this is the situation

Not all that strange in my workplace. Cables don't get hung up properly a lot of the time and the line operators run them over with heavy carts and hard rubber casters ending with the same fuse blown. You'd think people would have more common sense.

You can start by checking the power cable from the servo amplifier to the motor.

1. Remove the power plug from the amplifier for that servo.

2. Check resistance between W and V, W and U, U and V. It should be very close to 0 ohms if it is not then disconnect the power cable from the servo motor and check again. If it is ok after disconnecting from the motor then your motor is bad. If it remains a high resistance reading the cable is bad.

3. Do you have a spare encoder cap or encoder cable from another robot that you could swap it with to see if either one or the other will fix it?

4. Check the ground straps inside the robot cabinet to ensure they are tight.

5. I would think if the servo motor was bad then you'd get more than just communications error on the encoder. Things like SRVO-045 HCAL. This is just my personal experience though.

Quote from Robo_Eng_13

First, I only have access to R-30iB controllers and manuals, so I apologize if this does not work for you.

I used the Error Severity Table (Under Menu -> Setup). In it, you can choose any error code, then you can change its severity (upward only) and you can change what is done with the error code. All the details are in the HandlingTool Manual in Section 5.10, with the facility codes details in Section A.2.2 (Error Codes and Recovery).

When you say "details" is this where I can find the Fcodes for which alarms I would like to modify?

Quote from tacheson

Great Idea Robo_Eng_13! I do this on all new systems. Set the alarm as No Display or No Log and it won't muddy up your logs.

You can also change the system variable $EXTLOG_SIZ=1000 instead of 100. This will keep 1000 errors in your ERREXT.LS file in yoru backup. Also, check out the LOGBOOK.DG file, you can open it with a text editor. This shows the screens and what keys were pressed if you really want to do some investigating. I caught a customer messing with the robot after I left one night with the LOGBOOK.

Hope this helps.

Tyler
http://www.acieta.com

Display More

Do you need to cycle power on the controller for the change to $EXTLOG_SIZ? When you say check out the LOGBOOK.DG file in text editor i'm assuming you mean take a backup off the robot onto a USB drive and open it on a computer? Or will this change allow you to look up more alarms in the history section of the controller?

Per Fanuc:

INTP-206 (%s^4, %d^5) Digital port access error

Cause: Digital I/O is not functioning properly.

Remedy: Refer to the error cause code. Use MENU to display the Alarm Log screen.

I've never personally experienced this issue but are there any other active alarms? What was the original problem? Sounds like maybe when you downloaded the program it didn't like something about the I/O's. Hopefully you can provide some more info and maybe someone will chime in with some more "know how" about this.

While you're running through the base of the robot and all mounting hardware I would also check the fixtures that the robot picks from and places onto to ensure they aren't moving as well. I've seen a few guys on this forum that have had that happen to them.

I don't know much about the RJ3 but I would assume if your robot only has two brakes and you're getting two SRVO-018 alarms it would be for each axis with a brake. I would also assume that it isn't a mechanical issue but something to do with the brake amp (if you have one) or cables for those axis having a short. Our R30iA cabinets have a small circuit board for the brake controller with a fuse on it. But it's likely that if it was a fuse the alarm may not reset at all. This is just a guess but I would say it's a short in the cables somewhere or a bad servo amplifier maybe?

*EDIT* I know you mentioned reading through the forum a bit but I found this thread that may be of some use if you haven't seen it already.

https://www.robot-forum.com/ro…018-brake-abnormal-fault/