I'm confused why we're talking about the controller "battery". The SRVO-062 BZAL is a battery zero alarm for the (4) batteries in the base of the robot. These could be either "C" or "D" size 1.5V alkaline depending on the variation of M-10iA you have. They are arranged in series to provide 6V to back up the memory in each of the 6 motor pulsecoders. You must change the batteries before resetting the pulsecoders. The pulsecoders are reset by a short pulse, many times you can not see the reset pulse when turning the variable from False-True-False but it does work.
After cycling power and if the BZAL alarm on all axes is still there, then the new batteries could be installed wrong, the box could be damaged (corroded contacts) or you could have a bad cable harness. If the BZAL alarm is consistently only on one axis, then it could be the wire harness or the pulsecoder.
Search "BZAL" on this forum and you'll find this topic has been covered many, many times with great advice given from some really smart folks.
Posts by Skooter
-
-
Determine the motor speed you want to measure current at and then use an oscilloscope to measure the actual frequency while it's moving at that speed. Takes the guesswork out-of-it. For a probe, I would recommend an inductive pick-up or 100:1.
-
It's not loading disks 2 and 3? My guess is you are using the wrong disk pack, wrong key disk, or disk 1 is corrupted. Check the text file on the key disk and look to see if it's for RobotWare 3.0 or 3.1 and if it's the correct one for your robot. Contact ABB and ask for a link to download RobotWare disk pack for whatever version you have if you think disk 1 is corrupt. They should provide for free. If you need a new key disk, you will have to purchase that.
-
The plug size is 1/2" NPS (National Pipe Straight), 1/2" NPT (National Pipe Taper) male will thread in.
For IRB6600 axis 6 oil quantity and type, it depends on which IRB6600 you have. Post a picture of the robot ID tag.
Just a reminder - DO NOT mix different types of oils. -
Is it always the same file? Are other files saving? In the past I had a problem saving a TP file on an R-J2. I copied the file with a different name and was able to save it. I deleted the problem file and renamed the copy to match the original and everything worked after that. Not sure why.
-
The ICs are socketed so they can be changed, it's a shame that they did not offer this advice to you. I keep a few with me just in case.
For reference, just the control board by itself can be replaced if the circuit is too burnt, instead of the entire amp.
The 3.2A fuse covers all RDO plus other uses, that is why it's 3.2A.
Although the datasheet on the IC states a max of 0.75A, that's only one of the outputs when it's mounted directly to an ideal circuit board. EE outputs should maintain no more than the 0.2A as stated in the manual if you want to keep the IC from getting too hot and melting the socket or worse. -
Most of the time this fault occurs because an axis is moving too far when the brakes come on. The cause is usually a weak or faulty brake in the motor.
Besides increasing the time till servo off, as listed above by Bencor21, you can also open up the error limit for the offending axis at $PARAM_GROUP[1].$STOPERLIM
The value is in pulse counts, doubling the number will double the distance it can move before a fault is given. I do not recommend exceeding 2x the original value.
Make the change and then cold start for it to take effect.
Make note of the change and remember to change it back once the problem is fixed! -
Input power source capacity needed for R-30iB R-2000iC = 12kVA
-
To force the robot to loose the counters, you can disconnect the SMB cable while the robot is powered on (I'm sure someone will advice against it since you can cause damage when plugging the connector back in if you're clumsy), this will make the robot loose all counters and set it in sys fail state, you can plug the cable back in and restart the robot and you'll have to update all axis. If it's only one axis then IOWAN's method is a bit more "refined"I am that "someone". If you want to "dump" all the rev counters and it's inconvenient to unplug the SMB battery while it is powered off, then I suggest turning off the robot, unplugging the SMB cable from the controller, turn on the robot and allow it to boot up with the communication error. Power it down and then reconnect the SMB cable. Although faster, disconnecting and reconnecting with power on is an invitation for voltage spikes on the communication bus and may lead to failure. Why chance it.
Another option would be to go to the Motor Calibration parameter for that axis (IRB), change it to False and then reboot.
Like Iowan, I'm not sure why you would want to uncalibrate. You don't have to Uncalibrate to reset (change) a rev. counter. -
Great to hear it is working.
-
Just to clarify - are you getting the alarm on both robots?
If only one robot, swap the servo amps and see if the problem follows.
If on both robots, is it the same axis every time?
Can the alarms be reset right away or does it require a few minutes.The IPM (Intelligent Power Module) monitors many things internally which can give an alarm output. Unfortunately, the IPM only has one alarm output and you don't know which internal monitor causes the alarm. It internally monitors overcurrent, short-circuit, Vcc undervoltage, and overheating.
When we see units with IPM alarms, we usually replace the IPM just as a precaution, but if you're getting occasional alarms on robots, I would check:
>Incoming voltage - there could be a slight drop in one of the phases that may cause an undervoltage. The amplifiers are rated 200-240V input voltage. These alarms reset right away.
>Temperature - the cooling fans are working, the airways are not obstructed, cooling fins on the amplifier heatsink clean, and there is good air flow.
If the servo amp has been improperly repaired, there may not be the correct type and/or amount (too little or too much) of heatsink compound and/or the IPM screws not properly torqued. Heat must be effectively transferred away from the IPM or it will accumulate heat and cause an IPM alarm. Temperature related alarms usually take a while to reset. -
The R-J3 controller and software was a big leap ahead compared to the R-J2. The earlier ones came as single run-chain and a dual run-chain (RIA) version was introduced to make it compatible with new safety standards. You can easily tell the difference as the RIA version has a mode switch.
The R-J3 servo amps have the same control board for all sizes of servo amps, connectors instead of the wires & screws on the R-J2, direct connection for the RP cable going to the robot and a fiber optic cable instead of the ribbon cable.
The R-J3 panel boards offer more connectivity for interfacing safety and the addition of the PCMCIA slot for backups was a big time convenience compared to the standard R-J2 and its slow RS232 port.
The Main board was advanced with new architecture and much greater power & speed compared to the R-J2. More I/O options for the additional slots in the Main board & power supply.
The V5.xx software was another big advancement over the V4.xx software. -
You could also turn off the robot, disconnect the cables at the track motor, power the controller back on. When it powers up and can't read the resolver on the track motor, it will unsync the track axis. Power it off, wait 20 seconds and then power it back on. With the track axis unsynced, it will move the entire length of the track - be careful to not run it against a hard stop. Move it to the track sync mark and set the rev. counter.
-
Some speed errors happen when the motor reaches its max speed when trying to maintain TCP speed. An example would be a move with a short fast TCP distance but a lot of axis 5 movement. If this is the case, find the move where this is occurring and try rotating the nozzle (tool coord, reorient z assuming you have a good TCP) at the start and finish points of the offending move to lessen the amount of travel of axis 5.
Setting the proper load values will allow the robot to better calculate collisions and give proper accel/decel values that will save wear-n-tear on the robot.
-
The ABB response is correct, you got a great tech support person to dig up this old information. Did you get a price from ABB on the SBV/SDG EPROM set? If you can find the older RND/RNE or RRY/RRZ sets, they will also work with the 2.0 software. You could also try the Market Place here on the forum.
The full part # for the D62/D63 EPROMs all start with 4911014-, for example: 4911014-SBV & 4911014-SDG
The M94A software was taken off the market over 20 years ago and was subject to a recall at the time. You had to return the old disks & EPROMs or they charged you for the software. It was buggy and they wanted it out of circulation.
-
What software version, 3.1 or 3.2?
-
I've been snatching up the floppy's from recycled computers - they're getting a li'l hard to find.
The PC compatibles aren't too hard to find, it's the jumper configurable ones for the S2/S3, old Adept, old Kawasaki, etc. Teac FD235HF series were my faves. Used to buy them by the case.I've still got a few 5¼" discs from the early S2's
Got a whole box myself & the cleaning disk too. I used to convert those to 3.5" back in the day. Was actually visiting some old IRB60 friends today, this is their last year before retirement. 30+ years in a harsh environment, that's some good ROI. -
This post does not make a lot of sense. The DSQC504 is a connection board.
My best guess is that you are trying to setup DeviceNet on your S4C+ controller. You will need the I/O Plus software option to do this.
ABB Tech Support will usually make BaseWare 4.0 software available for download if you contact them.
Attached is an EDS that may help. -
To ID the controller if it's an S2, can you list the model # of the Main CPU at address 125?
Regarding the DSAI130 and assuming you have an S2 controller:
It looks like the S1 address jumpers are set to 2E which would be invalid in an S2. The address is in BCD meaning it should not be higher that 1001 (9). In what slot are you trying to use it? If the firmware can recognize it, I would guess that it should be at slot address 165 (S1 = 01100101) or 169 (S1 = 01101001). Since the DSAI130 is not listed, not sure what the 'I/O Type' number would be in the parameters. -
Seen this many times, one of the first 3 disks is bad. When the software begins to load, it says that it will load a MC1 file that is a specific size. The large MC1 file is divided up on the first 3 disks and if part of the MC1 file is missing on one of them, then the file size is now smaller than specified in the beginning so it assumes there must be 4th disk with the rest of the MC1 file. When it does not see it on disk 4, then it keeps asking for the disk.
The remedy is to find which of the 3 disks is bad and make a new copy from a known good disk pack.
What version and revision level are you using?