Posts by Robo_Eng_13

We just made the decision to update our DCS passwords. Until now, all of the robots in our facility (90-ish of them) had the same (more or less)_ password setup, some with only a master code, some with an additional base code. With this change, we went to a unique code for every robot, and the removal of all secondary passwords. This change requires the robot to have the teach pendant turned on, but does not prompt for any further action.

The following 72 hours, we had multiple requests for passwords, because of "power cycle".

I was able to recreate this issue!

If you have a secondary password assigned, and remove it, the next power cycle will require "Apply DCS Parameters". Those without the secondary password do not encounter this issue.

I need to do a little further testing:

1. I only tested the BASE secondary password, need to see if this happens with either of the other two.

2. I cleared the secondary password AFTER changing the master password, and removed the secondary password with the new master code. Need to test if the issue exists if the secondary password is removed with the old master code BEFORE changing the master code.

Just a heads up to anyone else who goes down this road, if you remove a secondary password, it will work find until the next power cycle, then require the DCS code to be entered and an additional power cycle.

Quote from Vendekkai20

Can you elaborate more on how to do this? Also is there a possibility to control what data is being filtered. In the sense, is there a risk of important traffic communicating to the robot that gets filtered with this command?

How: Navigate to the system variable and enter the new value.

Details: No clue, Fanuc was very stingy with details, i have no idea what the variable does or what the numbers mean, only that we had a weird problem and Fanuc said "try this".

Quote from JW_Basco

Hello,

Where are the appendices (A & B) that you reference in your PDF? Thanks

After doing some digging in old files, attached is what i had put together on Screen IDs (Appendix A), but i never assembled anything more complete than what is available in the manual (MAROBHT8304141E REV C Section 5 Table 5-39 "Features".

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.