can anyone tell me what this fault means?
CPMO-046 ChnI != Ch0 + CIF (G;1)
can anyone tell me what this fault means?
CPMO-046 ChnI != Ch0 + CIF (G;1)
thanks for the responses.
Some software versions DO NOT support Image file back ups to USB. We were able to do this successfully in the past, so am thinking software wasn't the issue.
You say you were able to do it 18 months ago did you use USB or Memory card.-we used usb, as we didnt have access to PCMCIA cards. The trend on this site is to use USB onlyI don't recommend using USB because they are too slow and you may have a software version that doesn't support USB Image Backup. Once we installed the new cpu and restored images, I backed up the images both to the usb stick on the controller door and to the PCMCIA card just to be sure of our situation. There wasn't a noticeable difference in image backup speed between these 2 approaches. I was advised by Fanuc tech not to use the teach pendant usb to backup as that port is communicating differently to the cpu than the door mounted usb port.
You should be doing an ALL FILES BACK UP regularly like every three months to make sure you are covered.- We have been doing the all files backup every time we have anyone modifying programs (we have been in launch for 2 years so this has happened frequently but it has not been scheduled...it is nowhttp://https://www.robot-forum.com/robotforum/Smi…forum/dance.gif)
Reloading an Image back up because one file is corrupted is like reloading windows on your PC because Word won't open. Reload only the file you need. In the heat of the moment identifying exactly which file is corrupted can take time, expertise and clear thought: all of which may be lacking during a breakdown. Although it may be overkill, reloading everything gets the line going. Identifying which file was corrupted can then be done while the money-line is running.
quick update:
We obtained PCMCIA cards and attempted to backup but were not successful. same problem.
We then considered using the ethernet ports, but discovered that they were disabled in the Robot setup, but are being used by the vision system software. At this point Fanuc was involved and they were reluctant to use the ethernet ports as they were not sure what impact it would have on the vision system software....which made backing up to an external PC impossible.
We believe that the FROM is being corrupted. We can run the robot from the current cpu card, but are unable to backup the images, with any attempt to backup giving us the FROM 0 file as empty. We swapped out the cpu and FROM and re-installed Images and files and the problem went away. (we kept the old cpu with FROM for emergencies). Once this was done the usb ports worked correctly.
While doing this we performed backups on the other robots in the cell, only to discover that another material handling robot had developed exactly the same issues, which we solved by swapping cpu and FROM.
The common element is that both these material handling robots are used for decking glass, and both are running pc programs in the background for modifying deck position based on vision system information. We have also learned that this problem exists in body shop where the vision system is operating in a similar way. The thinking is that the vision system is eating up all available memory with offset data that is being stored for each job. We do not have a clear answer at this point. If that is the case then we may have fixed a symptom not the disease.
We have resolved our issue for now, but are waiting to see if it comes back.
thanks for responses;
Fabian, I am afraid to try loading a program in case I corrupt what we have already.
Andreic thanks for link, I will try that.
I have been away from forums, and robot issues for almost a year, sorry for not following up.
I was wondering, how you made out with this "robot take over".. Were you able to predict accurately?
I apologize for the length of this, but I have attempted to include everything....
I am attempting to do image backups on a material handling robot used for decking windshields. It is a R-2000ib with a R-30ib controller.
It is equipped with usb port on the controller and one on the TP. There is also the PCMCIA port on the cpu.
I have had to do backups on these robots about 18 months ago and was successful. I had no issue. The robots are almost 2 years old.
The robot I am having issues with has faulted a number of times recently but only when I was not on shift. The technician dealing with the issue was not able to get out of the fault. He believed that the robot had corrupted a single file (same file each time) and felt the only way out was to re-install the image files. To do this he has used my year old backups to restore the robot via a usb stick. These backups were ok and although we had to install more recent TP programs afterwards we have been running production on them since. (Note: I don't think he diagnosed the fault correctly and feeding off the absolute insanity in this place let a small thing spiral into a big thing, but I wasn't there so cannot be certain.)
When I attempt to do image backups when using the controller usb port the TP screen would sit at the grey "image backup please wait" screen. I waited 14 minutes before giving up. Cycling power produced no difference. removing the usb stick gave no difference. Removing the usb stick during power down would allow the robot to start backup.
When I use the TP usb port I get the same result except that I cannot get the robot to start backup once the image backup is in progress. I have to do a BMON start and then config, cold start. I cannot do a config start, it will not work. I can do a config start at other times without issue.
I started doing this backup using Transcend 4 gb sticks (which they use on over a thousand similar body shop robots without issue). The thinking was that the problem may be with the sticks, so I tried new sticks fresh out of the box, I tried formatting them on a pc, then tried formatting them on the robot, then tried an older stick that was 2gb formatted to FAT, Then tried Formatting the old stick to FAT32. Then we thought the version of windows was corrupting the drives making them incompatible, so we tried new virgin drives again.
Many of the sticks that failed on this robot have since been used on other robots without issue. It is safe to say that the issue is not with the sticks.
The robot is seeing the stick, which I proved by attempting to set the drive without the stick inserted. In both the Controller mounted usb and the TP usb it recognized the absence of the drive, and allowed the device to be set once the drive was inserted. When the backup was attempted when the stick was inserted into the controller the drive was found afterwards to have the FROM0 file on it with 0 size.
There is a concern that someone may have used the robot to charge their phone damaging the usb port. It would be hard for an uninformed person to locate the usb port on the TP but not impossible.
(As my backup image files from 18 months ago are also installed on a pc terminal near the cell, I cannot help but wonder if someone attempted to use their phone to download files from this terminal to the robot...is that even possible?).
I am now worried that we cannot restore using these ports, and am afraid to attempt it unless absolutely necessary as I may corrupt the existing memory with the attempt.
I am working on creating a test cable to test the power supply at the usb port...(unless someone knows of professionally made device that is out there for this purpose). Aside from testing power I am not sure how to test anything else on a usb port?
This robot communicates with INOS vision system for positioning, and there is some thinking that there is constant polling between the robot and INOS...I don't know what that means exactly or how to check for it...???
I thought that during an image backup all robot activities would be suspended so any outside device sending to the robot would be ignored...?
I have ordered a 128mb PCMCIA card but will not have it for a couple of weeks so cannot check if this problem is only with the usb ports.
Is their something I am missing?
I have asked for input from a number of sources, and so far no-one has seen or heard of anything like this.
This is a big deal for the plant, as the windshield cell is a bottleneck, and at this stage we have a robot that has a possible history of corrupting files, and potentially no way to backup or restore images. any help would be appreciated.
Could I get that too?
I wish I could bypass the deadman, my hand is in a permanent claw
if i do this, it will not reduce the number of programs, since a program taught in one user frame will not run in another user frame.
or am I misunderstanding?
I have a dispense robot dispensing onto a part held on a 2 position rotating table. The operator loads/unloads on one side while the robot dispenses urethane onto the part held on the other side. The parts are identical each time, however the position of the tooling on a-side of the table is not the same as the position of the tooling on the b-side. This means that we have a different seal program for each side. when you allow for different models etc it translates into 68 seal programs.
What I want to do is program a-side and then off-set my user frame for b-side. If I can accomplish this it will reduce my seal programs to 32.
How do I achieve this?
Part 2 of this question:
The backup robot for this job is positioned as the mirror image....so how do I use the same program in the backup robot as for the primary robot?
This has become an essay…sorry if it is long winded. You asked…
A lot of problems we have revolve around material viscosity, which impacts flow rate, bead shape, adhesion etc.
Viscosity can change due to manufacturer inconsistencies which are beyond your control. It can also change due to temperature. Material brought to the site on a cold truck will flow differently than material at room temperature, which will also be different than material kept in the sun on a loading dock. I cannot get a clear answer from the supplier regarding the impact of temperature change on the materials. Is there any kind of separation or breakdown of material if it is moved through a range of temperatures in the time between manufacture and application. There is an expiry date on the product (I am currently working with urethane for gluing glass into vehicles) which would suggest that there can be some degradation.
We have had some success by controlling the material temperature at the robot through the use of temperature control units in other applications but we didn’t go that route with the urethane which is affecting performance.
Unfortunately the temperature control units, which are miniature air cooled chillers with electric resistance heating coils, do not come equipped with oversized condensing coils to handle the high temperatures found in a paint shop. Most air cooled refrigeration systems are designed around 95 degree F condensing temperatures. (Temperatures in paint regularly exceed that level) which means that when you need cooling the most they don't work very well.
The issue for us is
: How do you setup to dispense a fluid in a consistent and repeatable way when it can vary in flow rate.
Getting this material to stick to a surface depends on the material that the surface is made of. It also depends on the stability of the surface. It is easier to spray sealer on the floor pan seams of the car which remains horizontal as it heads into the oven, than it is to spray onto a thin edge of a part that is moved over a pedestal mounted sealer gun where the position of the part can be impacted by loose grippers and robot movement. Low viscosity sealer will remain in place on the floor pan but will be whipped all over the place if the part is being rotated into position.
Surface friction can also be an issue. Put a bead of thick material on a smooth surface and it will not adhere, but instead it will be dragged around as the robot works through the path. Warm up the plant by 10 degrees and the problem goes away as the viscosity decreases. Warm it up by 20 degrees and the bead is losing its shape and falling over.
Bead thickness, also impacted by viscosity is an issue, too thick and you get expulsion, too thin and not enough coverage. It means that as temperature changes you need to make changes to compensate
Depending on the dispense controller that you choose robot speed will have different impacts. It is my understanding that Dispense Tool will vary the dispense rate proportional to robot speed. I don’t see how this will work with high viscosity materials but I can see it working well with runnier materials like paints and solvents.
The system that I am currently working with doesn’t do this successfully if at all.
I think it is based on reaction time of attempting to control flow rates. We work off the sealer schedule and send a signal to the controller which then controls the gear pump speed to vary flow rate of material being discharged at the gear pump outlet at 2500 psi which then arrives at the dispense tool at 1000 psi. Varying the signal from the robot results in inconsistent reactions from the dispense tool, which we believe is due to the flow rate, viscosity and mechanical reaction of the equipment. The response time is slow and unreliable. We have better response by maintaining a consistent sealer schedule signal and varying robot speed to increase or decrease bead size. There is some thought that we may have maxed out our dispense rate and need to slow down the robot.
When you pump a thick material it requires very high pressures to move it. Although the pumps that we use are not true positive displacement pumps, the possibility of extreme pressures is very real when you get into the theory of hydraulics and compressing fluids. When you shut off the outlet but are still pumping at the inlet the pressure will spike, even if the delay in pump shutoff is only momentary. On more than one occasion we have installed fittings rated for 2500 psi on a system operating at less than 1500 psi (to replace 5000 psi fittings) only to discover that the higher pressure rating was in fact required. Luckily no-one was hurt when the fittings burst, loudly, and sealer sprayed 50 feet across the plant.
Thick material does not move with high turbulence when it is pumped. A turbulent fluid will "scrape" the inside of the pipe and prevent buildup to some degree. Thick materials will smear the inside of the pipe with a very real difference in flow rate between the center of the pipe and the outer edges. This coating will gradually dry and will gradually increase in thickness, until it impedes the flow of material at which time it will either block flow completely or break free due to the force of the flow. You will get dried particles coming out at your dispense tool. No amount of chemical flushing will prevent this from happening or eliminate the problem once it has occurred. Every piping system has nooks and crannies inside that will allow this to occur. All you can do is wait for it to happen and do damage control by flushing and filtering as close as possible to the tooling.
The actual dispensing can have some unusual quirks. Reaction to commands is never instantaneous. There can be time delays due to mechanics....how long it takes for pressure to buildup, how long it takes for a valve to open, material flow rate etc. There can be time delays due to electrical issues, waiting on signals, communication lags etc.
For instance when you arrive at the point where you want material to dispense you need to have already sent the signal to open the valve and start to turn the pump. If you wait for confirmation that the dispense controller has received the signal the robot will be stationary momentarily while dispensing...which cause a pool of material to be dropped on location. If you dont wait at all you will have inconsistent starting points for your dispense pattern.
There can be instances where the stop dispense can result in a "tail" hanging off the tool which is dragged across the part. Twirling the tool at the end of the path can help but can also cause a buildup swirl of material at the dispense end point.
During the off time between cycles the pressure from the tank pumps can be high enough to push through the gear pump pre-charging the tubing between the gear pump and the dispense solenoid. When the start command is issued for the next cycle the initial spurt of material can be substantial ruining the job.
Measurement of dispense volume cannot be done directly. For example: If you wanted to measure water flow you can use the water to turn an impellor and count the rate that the impellor turns… which would be a fairly fail safe measurement of water flow. If you tried that with sealer material it wouldn’t take long before the impellor was clogged up and didn’t move anymore.
The method that I have seen is to measure gear pump rotation, with the theory being that if the pump is turning you must be dispensing material. As there isn’t any true feedback tracking actual material flow, it is possible to run cycles without a fault and not apply any material at all…This can happen when the inside set screw of the double stacked set screws are not properly installed.
We use a pneumatic drum pump to push material from the drums, and a gear pump to meter flow to the tool, Dispense on and off is controlled at the tool by a pneumatic solenoid. The distance in one case from the drum to the robot head is about 50 feet. When the drum is changed, there is always a layer of air at the top of the drum trapped in the system. Purging the air becomes a problem as it is carried 50 feet through the tube before it is released. A great deal of material is wasted if you attempt to completely purge, but a number of jobs can be wasted if you don’t purge.
When path teaching to dispense it is necessary to teach linear points with cnt100. I have spent the last few months teaching thousands of paths (sink or swim) and this is the only approach that has been successful for me. I have found through experimentation that a corner should only have 3 points, the approach, the centre of the corner and the exit. It works best to maintain constant speed through the corner. Our dispense tool discharges out of the side of the tool at the tip through a bead shaped cutout. Obviously this cutout is on the trailing edge and I have found that it is best to keep the discharge straight on the approach and on the exit points and at 45 degrees on the corner point. Due to the reaction time of our dispense system I drop the dispense value from our sealer schedule very low on the point prior to the approach point (about 1 second before the approach point) and bump it back up on the exit point. If the corner is 90 degrees or less it will be necessary to teach the corner point off the edge of the surface to pull the corner swoop into the corner when the robot is running in automatic.
The current challenge we are facing is the rigidity of the 1.1/2” hose from the column mounted gear pump to the robot head. This flexible hose contains urethane at 2500 psi which makes it very rigid. As the robot moves around the glass it is working against this hose causing inconsistent deflection of the dispense tool resulting in unreliable performance. It has also broken the dispense tooling from the robot head on 2 occasions. The equipment was originally installed with an aluminum plate sandwiched between the tool mounting plate and the dispense tooling with 3/8 bolts/threaded rod to attempt to stabilize the head. These have broken. Our current plan is to replace these floating aluminum plates with a thick metal plate bolted to the faceplate. This plate will protrude out one side and will have a hole in the protrusion to connect/brace the urethane hose. The idea is that the plate will absorb the force exerted by the hose and prevent it from impacting the dispense tool. I cant help wondering if this will cause an overcurrent fault on the robot, but we will see.
I have worked with a different dispense method in the past, which used a small holding tank (doser) mounted on the robot with a pneumatic piston to dispense a metered dose to the dispense tool. This approach also utilized a pneumatic drum pump delivering material to the doser. The sequence would be fill and dispense with dispense rate controlled by controlling the rate of air applied to the piston. I have also seen a gear pump in place of the air piston. Gear pump is an electric motor driving the dispense rate and due to short distance from the motor outlet to the dispense tool there can be quicker response in flow control changes. I was not as intimately involved with these installations as I am with the urethane system so only have second hand information for this approach. They are almost universally hated, due to recurring and endless faults. I am thinking that if you fill a tank with a thick congealing material that is designed to harden, it will harden where you least want it to.
If you are interested in Paint it will be a longer essay…
I have seen many paint robots and all of them are grey. Colour wont be important since they will have to covered to operate....If you dont cover them they will work for a little while and then seize up with every nook and cranny filled with overspray.
this is an art form. it depends on material viscosity, pressure, temperature, robot speed, surface friction, humidity, etc.
This is a trial and error thing.
We have many different systems and all are a nightmare of endless problems and adjustments.
Does anyone have the default username and password for Fanuc pc file services system.
can you achieve your robot path by using less points? I have had to modify paths on dispensing robots this way. The original programmers must have been paid by the point. Robot could never achieve speed or smooth dispense.