I made this mistake once when I was a new tech. I'm pretty sure If you are teaching the middle point of a circle motion, the touchup function key moves from F5 to F3 and DELETE moves to the F5 function key. You might not notice it but rather than performing a touch up, you are deleting the line. This might not be the issue, but it's something to look out for, and pay attention to when doing a touchup. Make sure that the function key actually says "TOUCHUP" instead of going off of muscle memory as I did.
Posts by white_raven
-
-
This is a 20+ year old robot. Yaskawa quit supporting the MRC controller several years ago. Chances of finding to new motor is very slim.
90 Vdc on controllers older than NX100.
You are the man! That's good information to have in case I run into an ancient robot like this.
-
I believe the variable [$UI_CONFIG.$READONLY] is what enables and disables editing. If it is true, then you have read only privilege's so when trying to edit it will give you the "Edit Operation Not Allowed" alarm. I'm not sure if you can modify the value if it is in "read only" or not, or if it will just go back to being true. I would look in your background logic to see if this variable is being set by an external device. We utilize this variable in background logic for badge readers, to prevent unauthorized employees from modifying programs. Check that variable if you want to enable editing.
-
I'm assuming the battery inside the controller went dead and it lost some of its software. Have you tried performing a cold start, or loading a backup?
-
FANUC offers a product called Zero Downtime (ZDT) and I believe that is the only way to log that specific data if it even does that. The robot connects to a server via ethernet/ip and sends information to a third party to monitor axis data. This is used to schedule repairs, and diagnose issues before failure. It might not be exactly what you need but it is an option.
-
If you have checked all positional data, and the coordinates set by the application process are not to blame, then I would guess it is a software compatibility issue. Inserting a user alarm probably interrupts the software process allowing the robot to continue normally. Was this scansonic equipment recommended by FANUC or was it something your company decided to use. FANUC usually recommends the equipment that is most compatible with their software, and can provide tech assistance with diagnosing these kinds of issues. Have you tried recording P[8] as a position register and using that in place of the point? It might not help, but there is a possibility that using a position register could interrupt the end of the application process enough to prevent a crash because those applications do not typically modify register values. Jog the robot to P[8], go into your position registers and find one that is not used, record the position to that register, then in the program curser over to the 8 and use the function key for choice, select PR, then type the number of the PR that you used. Make sure it is still set to a linear motion, and that the speed of the motion is still the same, then try to run the program without the user alarm. I hope this helps. If nothing else, you could try to rewrite the program, and use that in its place if for some reason your data is being corrupted. I wish I could be more help, but without being able to put my hands on the pendant to check the application data, it's difficult to diagnose.
-
all instrument and laser adjustments were made correctly, the software shows that the robot is correctly plotting the coordinates.
but it is precisely after the weld end that it jerks randomly quickly when moving to another point. Sometimes it hits not the product, but vice versa from the product. those. there is some kind of collision area after scanning.
however, neither fanuc nor the representatives of the laser sensor could help solve this problemThat's very strange. So basically the robot scans and welds fine, but when leaving the last weld point and moving to a safe point away from the product the robot decides to go a different direction? It appears as though the next motion is a linear motion and should go directly to that point. Its hard to know what is going on without getting my hands on it, but I would still assume an issue with the scanning application because the problem doesn't arise unless it is implemented, correct? I would double and triple check the scansonic application to ensure it is not sending the robot faulty positional data at the end of its scan cycle. Also, is it possible to bypass the scansonic, and create old fashioned welding instructions to do the job, or is there too much variance from cycle to cycle? Also, if that is not an option, I would check the coordinate data for point 7 and point 8 after a crash before the robot is manually moved off of the product to see if the last coordinates are where they should be.
-
OK, have you calibrated the scanning head? It might be that the calibration is off. I have only set up 1 laser guided welding application and I know that on that system, if the calibration was off then it would cause the robot to weld in the wrong location. What might be happening is that the sensor was bumped, or has moved slightly since the last time it was calibrated. This would cause the robot to scan properly, but when the application sets the coordinates, it is off enough to cause a collision. Sorry, im not very familiar with the scansonic application, but I do have experience with irvision and other laser welding applications, so im not sure exactly how it sets its coordinates.
-
We have this problem all the time with our motorman robots. The brakes are weak and if the payload of the tool is too great, it will cause the brake to slip. Without servo power it cannot hold itself in the original position. Was the "new" motor a reworked motor? If it was I would replace it with an actual new motor because reworks will sometimes miss the brake if there was some other issue with the motor. Also, I would disconnect the brake cable from the motor and see if it still drops with servo power off. Check to see if you are getting voltage through the brake cable when servo power is off. I believe it is 24V to release the brake, but if there is a voltage leak into the brake, it might allow it to slightly disengage. If you are getting any voltage reading whatsoever, while the brake should be engaged, I would start tracking that voltage reading from the robot harness through the cables and back to the controller.
-
So you are saying that the robot will collide without an alarm, but if you insert a user alarm it doesn't? Have you tried jogging the robot from point 7 to point 8 to see if there is an obstruction between points? Also it appears that you have remarked out the weave circle but left the weave end in place. Have you tried remarking both out to see if that helps resolve the issue?
-
Hello Guys,
Does anyone know if yaskawa has a wireless pendant for motoman Dx200 controller. Operating the pendant in a very oily production setting is kinda frustrating. If so what's your experience using it and give your recommendations.
Thanks
Due to most regulations, pendants are required to have 2 paths of safety, ie, the deadman switch and E-Stop button, both of which usually have 2 channels of communication to the controller. In order for a wireless pendant to work it would have to have a very strong network connection, and a powerful enough battery as to not die and lose communication with the controller. This equipment is generally heavy and if you have had to hold onto and use a pendant most of your day, you will understand the value of having a light weight pendant. Also, because most plant networks are not geared towards wireless connectivity of equipment, they are not very reliable for keeping a secured and steady connection to the network which would result in a fault of the controller, and a stopping of the equipment because the controller has to see both channels of communication to the safety devices on the pendant. For this reason, I think only kuka and universal robots have a wireless pendant option, and even then I don't think it is used very often in industrial applications.
-
Sometimes when instructions misbehave, I delete them and then recreate them. Same with the PRs. It's fixed similar problems a few times.
If changing it back to 1500mm/sec done as a background edit, try in teach.
Move all backups on the network and replace with one where the instruction is correct.
Check the RAM disk (RD) and FROM (FR) and make sure there isn't a copy of the program there too.
Is it both robots?
I ended up rewriting the whole program and deleting the old one in case there was any more corrupted data. It was on both robots at about the same point in each of the programs. The only conclusion I could come up with was that the robots were in the process of an auto backup, when they were in motion to that point and something might have glitched and caused the motion instruction speed to default to the 100mm/sec. Either way, thanks for your help. It took some time to rewrite both programs, but its better to just eliminate the possibility of something else becoming corrupted.
-
I highly doubt a program changed itself. It just doesn't happen.
Could be someone has remote access to it and did a background edit on the program or uploaded a copy of the program.
I thought the same thing at first, but after reviewing the camera footage from the furnace, no one had touched the pendant, and our network is restricted to IT and controls techs only. I am the only robotics tech in the facility, and the only one who can edit programs. Remote access is also restricted, and you must be logged into my account on our plant network in order to access the robot program/backup file folder on the Z drive. Also, I am the only person in the plant with the FANUC software on PC to even be able to edit programs remotely. Everything is locked down for this reason, and I am the only one with access. My only thought is a possible software glitch when the robot was performing an auto backup, that caused the motion instruction the robot was currently on to switch to the default setting (which is 100mm/sec). I came to this conclusion because of two things, 1.) the robots auto backup around this time frame and 2.) I could see from the footage that the robot physically changed its speed in the middle of the motion. It's very odd and after 10+ years of programming FANUC robots, this is the first time I've seen or heard of this happening.
-
Ok, so I have two fanuc robots that pick out of and place into a furnace. I have it programmed to use a single MOVE point that is a position register set by a group input. That point is using a tool_offset to move into and out of the furnace. I set the speed of the motion instructions to 1500 mm/sec, but after running for 2 days, the motion instruction randomly changed from 1500 to 100 mm/sec and slowed our cycle time down considerably. I had to go back into the program and change it back to the previous speed. This was not the override speed which is always set at 70%. This was the movement speed of the motion instruction that suddenly changed. It is not possible for a production employee or anyone else to change it because we require a badge scan to edit the robots, and my badge is the only badge with the correct privileges' to edit. My question is, if I have a motion instruction like this, (L PR[1:Move Point] 1500mm/sec CNT50 Tool_Offset,PR[3:12 up Pos] ACC80) How could the 1500mm/sec change on its own to 100mm/sec? I went back and watched the camera footage of the time frame the change occurred, and you could see the change from one cycle to the next, but the pendant was never touched to be changed manually. Maybe a ghost did it because i have never heard of motion instructions changing on their own. I know that if override select is disabled, the robots will switch to their default speed after starting in auto, but i have never heard of the actual motion instruction changing.
-
If you have “decompressed” the software properly to a CF card. Put the CF in the pendant. Turn power off. Hold Interlock, 8, and Select. While hold all three, turn power on. Should take you to a screen where at the top will tell you current software loaded and to the right software on the CF in the pendant. Towards lower right will have a button that says Software Upgrade.”
I have tried holding INTERLOCK+8+SELECT and it still gets stuck on the bitmap image. I have tried every combination I know to get it to boot to maintenance mode, even turning the NIF rotary switch to 2,3,5, and 7 to see if it would boot into anything past the bitmap image .I still have nothing.
-
I am having this same issue. Everything is new (maintenance crew replaced everything trying to resolve) and I still cannot boot past the bitmap image. I have a backup of the system software as well as the CMOS, but the controller will not boot past the blue robot bitmap image. Is there some process to load system software that I'm unaware of to get the robot to finish booting so that I can load the CMOS?
HI guys,
I have a Motoman NX 100/ EA1900N robot for the welding application. The robot was working fine until we started again after 3 days of holiday. Then the startup screen of Yaskawa motoman came then the white screen, and then again the Blue startup screen. After this, the system is not booting and the Yaskawa Motoman screen stays forever.
During this time, JZNC-NIF status LED shows 8, SGDR-AXA01A shows 0, and in the power supply module the source, 5V, and P-ON LEDs are lit.
CPU NCP 01 – LED 0 lit, LED 1 OFF
We tried starting the controller in the maintenance mode, but still, it was not booting up. Can you please suggest us what could have gone wrong with this system. I tried removing NCP01 card and installed again, but no progress.
I unplugged the LAN cable from the NCP01 board and switched on the controller, the same startup screen of Yaskawa Motoman comes and stays forever and not booting. Is this normal? Is there any way to find out if it’s a problem of pendant/ cable or the NCP01 Board or the NCP01 CF card?
Thanks in advance. -
Just for clarification, I am not trying to install teach pendant software. I am trying to initialize the System Software so that I can boot to maintenance mode and then worry about the pendant software.
-
I am having an issue getting system software to install on a NX100 controller. Motoman sent me the correct version software for my controller and have have decompressed it onto a CF card, but I do not know the proper steps to take to get the controller to initialize the system software. As of right now, it will not boot into maintenance mode, and when i try to boot to Windows CE, it states "Start was canceled." Does anyone know how to get the controller to initialize the system software so that it will boot properly?
-
I have both lights on, on the NIF board. I also have a new CF card. I.T. must have done the pendant software rather than the system software, because holding INTERLOCK+8+SELECT does nothing. I will have to try to get the system software on a CF card myself and go from there. I cannot trust our I.T. guys to do anything correctly, and they will not allow me access on our company network to do it myself.
-
I would look at the mode selector switch on the controller. If the selector switch is mounted away from the controller, like at a junction box or something, I would look at the extension cable from the controller to the junction box, otherwise it is most likely the wires in the controller to the mode selector switch, or the switch itself