Posts by Robo_Eng_13

You should change the default folder naming scheme to descending order, YYYYMMDD instead of ascending order DDMMYYYY, so that an alphabetical sort will always be a chronological sort as well.

Its always a special feeling when you have a problem, search for it online, find someone with the EXACT same problem, find that it was 5 years ago and that there was never a solution, and find that you were the one with the problem five years ago.

So for the NEXT time I search for this exact same problem, i am documenting what we did this time.

We found that for some unknown reason, the main program on the robot was switching from the "Running" state to the "Paused" state. The way our line is set up, we only transmit the UOP "Running" signal to the PLC, not the "Paused" signal. Because of this, the PLC only saw that the program was NOT "Running", and attempted (repeatedly) to make it run.

However, because the program was "Paused" and not "Aborted", the robot could not accommodate the new run request, and gave the two errors. SYST-011 (Failed to run task) and SYST-208 (Feature not supported), the feature being the ability to run two instances of the same program at the same time on the same robot.

The real problem is whatever is causing the robot to enter the "Paused" state (still unknown). However one of our techs found a forum post somewhere that suggested entering a controlled start followed by a cold start to, supposedly, defragment the memory.

Whatever this ACTUALLY did, it seemed to work. The issue has not re-occurred for two days now.

I would still love to know, what can cause a robot running in auto to enter the "Paused" state, and is there a simple way to un-pause it?

We have 17 large Robot Traversal Units (RTUs) carrying R2000 and M900 Material Handling robots up and down 11 different 10 to 20 meter long rails, five with 1 RTU and 6 with 2 RTUs. We have had MANY instances in the last five years of the pinion gear driving the RTU has sheared off, with the failure pattern looking like fatigue leading to failure in about 3 cycles. The failure is severe, and has had expensive collateral. The RTU motor comes to a stop, believing it is in position, while the RTU continues to be carried down the rail by momentum. The robot on the RTU, believing it is in position, then reaches out to where it thinks the cell is waiting for it, in once instance driving the grippers into a PLC electrical cabinet.

We have started tracking a specific circumstance that we suspect is causing our issue. One RTU Robot is inside of a cell, breaking the rear light curtain. An operator reaches into the same cell, breaking the front light curtain. This causes an E Stop to the OTHER RTU, which is in motion along the rail, causing huge impact to the pinion gear. This happens on average once every day, and in cases with untrained operators, many times per shift.

I want us to look at adding some physical barrier to the front of the cell to prevent the operator from entering before the rear curtain is cleared, but this is an expensive option and with the pandemic, our company is reluctant to spend a penny without a 3 Month or Less payback.

An alternative we are considering is to add DCS zones, to prevent certain conditions from E-Stopping one robot when the other is the only concern. However, some of our engineers are (rightfully) concerned about us relying on the rail position of the RTU when we KNOW that that is a major problem that we know occurs, and DCS may say the RTU is in a safe location and is free to move while the RTU may in fact be sliding towards a human.

It is not so much an issue of CREATING an unsafe condition as it is allowing an unsafe condition to continue and not accounting for it in our corrective action.

I want to reach out and see if anyone has worked with a safety rated way of positively identifying a machine's position along a rail, that we could use as a redundancy to ensure this is not occurring.

This is a very odd problem that has only occurred on one of our robots to my knowledge, but has now occurred two different times.

The first incident, occurred many months ago, date unknown, but probably less than 3 years.

The robot in question has Passwords set up with 7 different users, and custom XML definitions. The same definitions are used on a few other robots.

One day, one of our technicians approached the robot, but was unable to log in, because the screen would not appear. He needed to log in so that he could touch up a weld position, and was unable to do so. The next morning, it was escalated to me, i walked up to the pendant, and everything worked fine. No one has mentioned this error again until yesterday.

The second incident occurred on the same robot as before. First indication of an issue came when one of the engineers was unable to change one parameter of a DCS setting. To be specific, they were trying to add a maximum permissible speed for a Cartesian Position Check, which presented no problem on identically set up robots. When they made the change, it immediately reverted back, and they called me. I verified that the issue was repeatable, occurred on Joint Speed Check as well. I tried to log in at the Install level, but the password screen did not exist. I toggled to Full Menu and the Setup tree showed Password, but when clicked it would not navigate to the screen. We cycled power, and the problem persisted.

We tried with Quick and Full Menus, and we tried HMI Menus, but nothing worked. We were able to log in from the Menu+i screen using the function key for Install, but still could not get to the Password screen to disable.

We cycled power and entered a controlled start, and were finally able to enter the password setup screen and disable passwords.

After cold starting from there, we were still unable to make the DCS change we had originally wanted to. Since both items have to do with permissions, and both are occurring on only one robot, i am suspicious that the two are connected.

My primary question is, has anyone else encountered this, and if so, was there a reliable fix? Just waiting for it to work again isn't going to work out.

The USB Devices had some intermittent issues when i tried them, but that was primarily caused in the setup and a minor revision that Fanuc says is fixed. Otherwise they were effective, but a hassle to plug in and unplug.

It isn't the best thing, but as far as i know, as long as you do not use a non safe input to control a safety device, you CAN use a safety PLC as an intermediary between a non safe input and a non safety output.

Not sure if it will be relevant, but an issue i ran into on R-30iB in the past.

The robot had been backed up to UT1 before, but when that was done, it was in a deep directory, 4 or so folders deep on the flash drive. This was successful, but when i inserted a clean USB, it had saved the path from the previous, rather than automatically putting back at the root of the USB. When trying to create a directory there, it would give the same error of directory not found, because it is trying to create the new location inside of a location that does not exist.

The solution was to use the Up One Level option until i reached the root. An additional issue i encountered here was that too many Up One Level actions seemed to crash the controller. This occurred multiple times, but not verified enough to say if it is a certain number of levels, or if i was issuing the commands too quickly.

We have not tried that, but i will keep it in mind if we end up re-visiting that issue.

Quote from TitusLepic

If you have access to roboguide, you could do a cad-to-path feature to accomplish this pretty easily.

I guess i was thinking of a function which given Radius 1, Radius 2, and a touch point, could calculate and adaptively generate the path for ANY circle/cylinder combination on the fly in a TP program. If it is just a one-off thing, RoboGuide seems like overkill, you could just teach the point sindividually.

Quote from m3pisnik

Guys, I want to cut a circle on a cylinder.

I have make circle and path its perfect, but plasma is not always perpendicular to the surface.

A circle or radius R1 projected onto the side of a cylinder of radius R2, determining points which are in line with the projected circumference of the circle and in direct contact with the surface of cylinder, with the angle of the tool modified to be perpendicular to the surface at each point would most likely require the math option (or a homemade function using newton's approximation, which sucks but works), and a larger number of arc moves rather than a single circular move.

It is a really cool math problem, and on paper seems pretty straight forward, but i can see a lot of little challenges with automating it on a FANUC robot.

The angle of the torch will be a function of the radius of the cylinder and the current location around the circumference of the circle, and with a little trig could be easily calculated, but again, FANUC does not supply trig function by default, and i am not sure how those calculations might impact operation of the program.

General explanation, more generalized in programming context.

RUN and CALL are two different ways of executing programs.

RUN is Non-Blocking, CALL is Blocking.

RUN will, so long as there is no reason not to, create a new "thread", order it to execute the specified program, then move on and never look back.

CALL will also run the specified program, but instead it will run it in the same "thread", waiting until the child program is completed to jump back to the line after the CALL command.

As was said before, a motion group cannot ever be controlled by two programs at once, so whatever program you run must have a non-overlapping group mask to all other running programs, including the one in which the RUN command is executed.

Also mentioned, CALLs within CALLs and RUNs within RUNs are always a hazard and likely to result in Stack Overflow or Memory Overflow, especially when loops are involved.

Has anyone ever encountered a way to restrict choices on specific screen circumstances that do not have individual screen ID's? Specifically, when a point is touched up and that point's number is used elsewhere in the program, you are prompted to set new ID, which we want to only allow NO, and when touching up a point with an offset, you are prompted if you want to subtract offsets, which we always want to be YES. However, neither prompt changes the screen ID or SP ID fro m the generic of the EDIT screen. Is there a system variable or configurable point somewhere to restrict this?

Not addressing how to remember, but a note to anyone who stumbles upon this wondering about the right hand rule, there is a secondary layer for rotations. If you point your thumb in the positive axis direction, your fingers curl in the positive rotation direction about that axis. Many people do not know this, and it is a helpful additional tool to teach.

Payload calibration will affect the path and speed of the robot, but should not impact the robot's ability to repeatably move to a set point.

If you establish a reference point that is solidly mounted to the same base as the robot, and attach a secure touch point to the end of the robot, it should be able to go to a taught point (within about 0.5mm) over and over indefinitely.

1. If you are just finding more points from before remastering that have not been touched up, that is normal.

2. Ensure that whatever end effector you are using is not bent or damaged. Especially critical on weld torches.

3. Consider the possiblity of someone making unauthorized position touchups that you are then re-re-teaching.

4. If your robot is truly unable to return to the same location multiple times, then there is likely a major mechanical or electrical failure. Ideally, you would have another twin robot, and you can do swaps between components at different levels until the problem switches to the other robot, but sometimes that is not an option. An alternative might be to identify which axis is unable to achieve the correct repeatability, potentially by measuring the angles of the joints with a miracle point or a digital protractor.

With the password system, you cannot export a password xml until you have imported one. Once you have imported one, you can export to a USB drive (or presumably to any other location). Best to put an empty xml file names password_export.xml on the flash drive before you plug it in, as i believe it can only overwrite an existing file with the export.

We have the same sort of thing. I have had no issue with DCS passwords being passed back and forth between robots, only the password protection passwords.

I have had absolutely no success whatsoever in transferring passwords setup on one device to another. The best bet is to have the install user disable the passwords and take the backup, then re-enable the passwords. You should then be able to load it into RoboGuide without the passwords. I would be hesitant to put a modified version back onto the robot, as i have found transfering between robots seems to scramble the syspass file and change the passwords from what they were set at. I have not revisited this issue in 6 months.

Here is generally how i would go about teaching a new TCP with the 6 point method.

Point 1 - Square up your tool to your reference point so that you are as square as possible to the world frame, or have a printed grid handy to align to. This point will be used to position the Cartesian space around the TCP itself.

Point 2 - Move directly along the first cardinal direction of the tool. For welding, we typically do X as along the path of a weld, and Y perpendicular to a weld, so that Z is distance from the surface. Once this point is set, your Cartesian space is fixed along that axis, but able to rotate around it.

Point 3 - This will be the last point to minimally define your TCP, and would be the last point with a three point method. This will fix the direction of the secondary cardinal direction and the rotation about the axis defined by points 1 and 2. The exact positioning of point 3 in the direction of the axis defined by points 1 and 2 is irrelevant and not used in calculation, but there is no value in needlessly deviating.

Point 4 - This should be the same as point 1, and i usually teach both at the same time.

Point 5 - Rotate the tool a significant amount (30-90 degrees) and then jog until your TCP is back at your reference position but the joint angles are all different. The larger the difference of the joint angles, the better the calculation will be.

Point 6 - Return to Point 1/4 and then rotate differently than you did for Point 5. The exact direction does not matter, just providing a larger spread of angles for the system to use to triangulate where your TCP is.

As an additional note, i would get a printed grid and tape it firmly to a metal table with no chance of moving, and station it where the robot can easily reach and articulate. Mark three points on the grid, at least 6 inches apart in the shape of an L to define points 1-4, with 1 and 4 at the apex, 2 directly forward, and 3 to the left (we do it to the right so that Z- is away from the part, but to the left will most resemble the world coordinates. The robot will always follow the right hand rule). Orient the robot so that the weld tip is straight up and down perpendicular to the grid, and positioned at the center point. Define Point 1 and Point 4. Jog away from the grid, then move to the second point (forward, away from you and the base of the robot) and bring the TCP back to the grid and perpendicular to the surface to define Point 2. Again, move away from the grid and move to Point 3. You should always move away before trying to move sideways when teaching weld TCP because bending the weld wire while teaching messes up your TCP. Once you have taught 1-4 and returned to Point 1/4, then do your rotations. I try to rotate away from me as far as i can for Point 5, and to the side as far as i can for Point 6. Both of these will touch the same grid point as 1/4, but not perpendicular to the surface.

Last note, there are three different 6 Point Methods available, X-Y, X-Z, and Y-Z. This specifies what axes of the Cartesian space you are defining with points 2 and 3.

You may be able to enter a controlled start and de-select the welder in the ArcTool Setup menu. I can't find anything that mentions if it is possible to undo the setup of a welding system.

You can always teach User and Tool frames in whatever orientation you want (as long as you follow the right hand rule). Jog Frame i believe is relative to the current User and Tool frames, and the World Frame is pretty immutable, although if the robot is properly set up as upside down, it may change orientation. I am not sure, we have never had a flipped robot.