Posts by USURP_RUR

Use Ethernet

Example for your inputs

[1-20] 89 1 1

Not knowing your exact circumstances, you would generally configure your 20 UOP Inputs with the exact same configuration as your first 20 DI

And... except for the 3rd UOP Input, UI[3], ... they should probably never be always on.

What controller version of the Fanuc robot are you using?
R-30iA or B?? Or earlier than that?

What kind of PLC?

Is the use of Ethernet a likely option for you?

What program did you use to open the SYSPASS.SV file?

I tried NotePad and Word, but it was not laid out like that

First, check or set the scale in MENU-System-Config window: Max. of ACC Instruction and Min. of ACC Instruction.
Let us say you have chosen a scale (a range) of 50 to 150

12: L P[4] 2000 mm/sec CNT 100 ACC 150
reach speed with strongest acceleration/deceleration ramp

Or

17: L P[6] 1500 mm/sec CNT 100 ACC 50
reach speed with weakest acceleration ramp

Thank you for following up with your solution.

Search fields

Do a search on
Saving and Backing up programs

(original poster: sbecker) There's a good thread there with many responses.

The ACC expression, along with the number that goes with it... affects both the acceleration and deceleration ramps in the Fanuc robot, as it may pertain to a particular position instruction.
Don't forget to check or set the unitless scale for your ACC expression in MENU- SYSTEM- Config window, Max of ACC instruction and MIN of ACC instruction.

I agree with Cobenson. I am not aware of any way to specify deceleration ramp only using normal TP Programming language.

Changes to any used Payload schedule will make already existing taught paths interpolate differently, so always test slow in T1 mode after Payload changes.

Yes. I think your system has this capability. In MENU- SYSTEM- Motion, look to see if you have a soft function
F-key that says IDENT

If so, you can do an automatic Payload estimation. It is especially helpful that you already know the total mass of the End Effector.

It would also be helpful to know the masses of any other devices bolted on to the lower link arm and/or the upper link arm (aside from the end-effector mounted at the faceplate.) This would be set up with the soft F-key ARMLOAD

To make it work properly, you will need to do an "Empty Arm Calibration," which basically means to do the procedure first without anything attached to the faceplate or the Upper Link Arm. Check in the window to see if the Empty Arm Calibration is already done.

The Empty Arm Cal (no tool), and the Automatic Payload Estimation (tool installed) should both be done at
full 100% speed. In the Automatic Payload Estimation part, limits may need to be set on axes J5 and J6 to keep the Tool from crashing into the robot body. Don't forget to enter in the total mass of the Tool, since you know that information.

If you "ain't stealin', you ain't trying"

Your CRR 63B needs to have a thermal plugged into it also, the thermal coming from the 2nd bank of Discharge Resistors.

If, indeed there is 2nd bank. If not, then a jumper needs to be there.

From the recent history you gave for your robot, maybe someone needed a jumper for some other robot and came and grabbed yours.

I hope you got your answer from bidzej and aishpd

I think you should normally be able to solve this problem by specifying/limiting your desired Cartesian speed within each position instruction, as bidzej explained.

There is a way, however, to limit the speed of a particular axis. I offer this for your consideration, but I would not make any changes without first taking a complete "All of the Above" backup of your robot memory, to some external media such as a Mem Card.

In the System Variables,
$PARAM_GROUP[1].$jntvellim[7]
could be used to limit the velocity of Joint 7 only in millimeters per second. This should not be used to attempt to increase velocity of a particular joint (axis), but it looks like you are trying to lower the speed of axis 7 only.

This System Variable would need to be set within a Controlled Start (PREV & NEXT keys start), followed by a FCTN key, Start(Cold), after you change the System Variable as desired.

If this doesn't give you the results you were looking for, then you have your backup.

It would be great to hear back from you about how you solved your problem.

I looked for a System Variable that might affect this, but I could not find one. Opening the fence (a gate) wired to the EAS terminals of your Panel Board's TBOP4 connector should, indeed, cause a Controlled Stop and not a Power-off Stop.

Is your R-30iA controller receiving signals from a PLC ?
Maybe the PLC logic is analyzing signals from the robot and the cell, and dropping out the UOP signal
UI[1: IMSTP], the IMediate SToP

I think this is one possibility to explain what you are seeing happen. The Fanuc R-30iA robot system is calling for a Controlled Stop when the Fence is opened, but the PLC monitors the Fences also and drops a signal causing the equivalent of an E-stop, which takes precedence over the Control Stop.

I think your robot is being commanded, externally, to do a "brakes-on" stop.

Have you made any recent changes to your system?
Have you added any new hardware, like vision??

A bad Teach Pendant cable can make some really strange things happen, even codes on the 7-segment display of the Main Board.

I do not think that losing a phase will make the problem that you had.

Try this, if only to exclude it as a possible cause: replace the Teach Pendant cable.
You don't necessarily have to get a new T.P. cable. Just try one from another robot.

I would think there would be other attendant fault or faults present in the alarm window (MENU - 4 Alarms).
Can you send a picture of the active alarm window the next time it happens, and before pressing the reset key.

Somebody on the forum will recognize your alarm or alarms.

PMC address F1000.5 is the same signal as UO[6] (UOP Output 6), which means 1 or more faults are present.
I don't believe F1000.5 is causing the fault. It is only reporting to the plc that the robot has active fault(s)