Trouble with Viper s650.

This will be an archive of the Yahoo Adept Software Group messages

Trouble with Viper s650.

Postby oberbakow@roboris.cl » Mon Dec 29, 2008 5:00 pm

Hello Everybody,

Robot: Viper s650
Controller: CX
Servo Drive Unit: MB-60R

I´m currently integrating a Viper s650 for a simple pick and place
machine tending operation, and the process has been something like a
nightmare. Maybe one month and a half ago, while comissioning the
system, we had a fatal failure in the system, all six encoders were bad,
and also had an RSC failure (initial message). The cause? Well, we left
the robot (only the mechanical unit) in the laboratory on Friday night,
in order to put it to work again on Monday morning, leaving the
controller and electrical cabinet on application site. When we had the
failure, we found that the firewire cables were plugged wrongly on the
CX (like somebody removed from port 1.1 and put it on 1.2), but also
finding the ports somehow damaged and deformed, almost like somebody
tried to plug it in the wrong way and then powered on the system. We
found also that one of the firewire ports on the MB-60R unit was
damaged. I really don´t know if this type of "sabotage" could produce
this type of damage, but the thing is that the system was working
perfectly when we left it. Judge by yourselves.

First we tried to fix the RSC problem by using the rsc_set, and RSC_RSTR
restore programs, with poor results, after that, we tried to use the
original RSC file to commit to the robot, without any results. After
that, Adept sent us a new RSC card to change the currently installed,
and the result was the same. On the RSC management programs, we had
always that the system could not verify the encoders, hardware status
code: 22. We could not commit any data into the RSC, and also we had
encoder failure -1025 on the Adept Desktop screen.

We checked the encoder power supply system, and everything was ok (using
also the Denso Manual). Just to make the story short, we tried every
possible way to troubleshoot the system, but the result were always E0
up to E6, RC on our MB-60R unit. On the other side, AS explained before,
this unit had also one of the firewire (1.1) ports damaged, since we
could not even find the network when we wrote SRV.N on the terminal. In
order to find the network we needed to plug the cable to the 1.2
connector. Anyway, finally, suspecting that maybe the MB60R unit was the
problem (since we had normal readings on the voltages of the encoder
power supply, and also the voltage supply to the RSC), Adept sent us a
new MB60R unit. When we installed, it immediatly recognized the RSC and
hardware settings, and proceed to perform full data commit into the
robot, by using our original RSC file. We finally made to load all the
configurations, and even if we received some strange messages warning
that some data could not still be committed to robot, the data finally
got into the system. We checked the current values and parameters, and
eveything seems to be correct. The system promptly responded with a OK
message, and then, after a calibration, we had our ON status. When we
power up the unit, in a very short burst, a message of E0 appears on the
MB-60R unit, and then disappears, leaving place to the OK message.

The robot is capable of moving without any problem, running programs and
all, but after a while we are experiencing a heavy vibration on the
servo motors, seeming almost like a tuning issue. We removed the gripper
in order to exclude overweight or the effect of inertia, but it didn´t
change much, after a while the system starts to vibrate heavily,
specially on axis N°3. If we issue a power down on the servos, and then
power on again, the systems behaves normally, and after a while
vibration starts again. Is there a way we can troubleshoot this
vibration and noise? While in this state, the system usually does not
issue an alarm (we had only once a D3 alarm, a duty cycle alarm for
joint3, on a very low speed, maybe due to heavy vibration), and we can
run programs, and also jog the robot with the vibration on. Is there a
way that maybe some servo parameters can be adjusted to eliminate this
problem?? Do we need to perform any more calibrations beside the one we
did on the system restore?? Could it be the surface in which we mounted
the system, maybe resonating at some point with the robot structure? If
anyone has experienced something like this before, please advice,

Regards


--
Ottavio Berbakow
ROBORIS LTDA.
oberbakow@roboris.cl
 
Posts: 1
Joined: Mon Dec 29, 2008 5:00 pm

Re: [adept_software] Trouble with Viper s650.

Postby juergen.bosse@robo-technology.de » Sat Jan 03, 2009 5:00 pm

Hi Ottavio,

well that sounds like a proper nightmare to me. I think the only thing
you could have done to make it worse would have been to crash the
gripper into a customer fixture while troubleshooting it. Repeatedly,
preferrably.

But let me tell you that you are one of very very few people on this
group who take the time to write up a very detailled description of the
system, the fault and incidental observations. Well done! Hopefully,
we'll be able to help you find the root cause quickly.


Ok, so let's look at the issues one by one.

1) fire-miswire

Basically, you can use ports 1.1 and 1.2 interchangeably. The system
doesn't even notice. That by itself would not have done it any harm.
Jamming the connector wrongly into the socket is not a valid operation,
though. In fact, what happens is that pins 1 and 2 (24V), connect to
pins 6 and 5 (data lines) and that will most certainly smoke the MB60R's
firewire circuitry. Any recovery you try after that will be doomed. The
RSC problems are caused by the inability to even access the MB60R correctly.

2) New MB60R reports encoder errors first, but then works ok

This behaviour is to be expected during the initialization, but no more
after that. Does it complain about E0-E6 every time you power up or was
it only the first time?

3) Vibration on Jt3

Well I have experienced some mild Jt2/Jt3 vibration on the Viper s850,
but it was definately less than 0.1-0.2mm and only occured in certain
positions, where the position of the joints together with the weight of
our endeffector caused the resonant frequency to be excited by small
vibrations from the drive train. But this is a purely mechanical issue
and doesn't develop over time. It's either there or not.

So the behavior you see must be either thermal, electrical, or maybe
mechanical in a way you have a loose coupling or bad gear. Since you can
still servo with the vibration, I think we can rule out a bad encoder
signal or data transmission, as it is all digital and would stop working
altogether if there were any issues with it. More likely, you have a bad
motor (maybe broken motor wire) or bad amplifier (you're keen on
changing the MB60R AGAIN?).

Now back in the old days of PA4, we could have swapped individual amps
to isolate the problem... but not on the MB60R afaik.

You can try to heat/cool the motor, the cables, the MB60R (within
reason, please!), shake cables, inspect the wiring inside the robot, and
you can use SPEC to diagnose motors individually. To be honest, if I
were on site to hunt down this bug, I would try various random things,
and learn from the observations. Try to move the joint by hand with the
brakes released manually. Try to move the joint against the brake. It
should not give way at all (until you exert too much force for the
brake) Try to measure the ohm resistance of the motor windings of each
motor. Between the three phases, you should have a very similar reading
for each pair (1-2, 2-3, 3-1) per motor. Try to move the joint from hard
stop to hard stop and read the encoder. It should reproduce within
0.01-0.02 degrees in the stops. Try this 5 times or so.

Well - let us know what you find. Hopefully we can fix it quickly.

Best regards and good luck - you'll need it.

Juergen



Ottavio Berbakow schrieb:
> Hello Everybody,
>
> Robot: Viper s650
> Controller: CX
> Servo Drive Unit: MB-60R
>
> I´m currently integrating a Viper s650 for a simple pick and place
> machine tending operation, and the process has been something like a
> nightmare. Maybe one month and a half ago, while comissioning the
> system, we had a fatal failure in the system, all six encoders were bad,
> and also had an RSC failure (initial message). The cause? Well, we left
> the robot (only the mechanical unit) in the laboratory on Friday night,
> in order to put it to work again on Monday morning, leaving the
> controller and electrical cabinet on application site. When we had the
> failure, we found that the firewire cables were plugged wrongly on the
> CX (like somebody removed from port 1.1 and put it on 1.2), but also
> finding the ports somehow damaged and deformed, almost like somebody
> tried to plug it in the wrong way and then powered on the system. We
> found also that one of the firewire ports on the MB-60R unit was
> damaged. I really don´t know if this type of "sabotage" could produce
> this type of damage, but the thing is that the system was working
> perfectly when we left it. Judge by yourselves.
>
> First we tried to fix the RSC problem by using the rsc_set, and RSC_RSTR
> restore programs, with poor results, after that, we tried to use the
> original RSC file to commit to the robot, without any results. After
> that, Adept sent us a new RSC card to change the currently installed,
> and the result was the same. On the RSC management programs, we had
> always that the system could not verify the encoders, hardware status
> code: 22. We could not commit any data into the RSC, and also we had
> encoder failure -1025 on the Adept Desktop screen.
>
> We checked the encoder power supply system, and everything was ok (using
> also the Denso Manual). Just to make the story short, we tried every
> possible way to troubleshoot the system, but the result were always E0
> up to E6, RC on our MB-60R unit. On the other side, AS explained before,
> this unit had also one of the firewire (1.1) ports damaged, since we
> could not even find the network when we wrote SRV.N on the terminal. In
> order to find the network we needed to plug the cable to the 1.2
> connector. Anyway, finally, suspecting that maybe the MB60R unit was the
> problem (since we had normal readings on the voltages of the encoder
> power supply, and also the voltage supply to the RSC), Adept sent us a
> new MB60R unit. When we installed, it immediatly recognized the RSC and
> hardware settings, and proceed to perform full data commit into the
> robot, by using our original RSC file. We finally made to load all the
> configurations, and even if we received some strange messages warning
> that some data could not still be committed to robot, the data finally
> got into the system. We checked the current values and parameters, and
> eveything seems to be correct. The system promptly responded with a OK
> message, and then, after a calibration, we had our ON status. When we
> power up the unit, in a very short burst, a message of E0 appears on the
> MB-60R unit, and then disappears, leaving place to the OK message.
>
> The robot is capable of moving without any problem, running programs and
> all, but after a while we are experiencing a heavy vibration on the
> servo motors, seeming almost like a tuning issue. We removed the gripper
> in order to exclude overweight or the effect of inertia, but it didn´t
> change much, after a while the system starts to vibrate heavily,
> specially on axis N°3. If we issue a power down on the servos, and then
> power on again, the systems behaves normally, and after a while
> vibration starts again. Is there a way we can troubleshoot this
> vibration and noise? While in this state, the system usually does not
> issue an alarm (we had only once a D3 alarm, a duty cycle alarm for
> joint3, on a very low speed, maybe due to heavy vibration), and we can
> run programs, and also jog the robot with the vibration on. Is there a
> way that maybe some servo parameters can be adjusted to eliminate this
> problem?? Do we need to perform any more calibrations beside the one we
> did on the system restore?? Could it be the surface in which we mounted
> the system, maybe resonating at some point with the robot structure? If
> anyone has experienced something like this before, please advice,
>
> Regards
>
>
>

--
_____________________________________________________________________

Juergen Bosse
Robo-Technology GmbH Sitz der Gesellschaft: Puchheim
Benzstrasse 12 Amtsgericht München HRB 140072
82178 Puchheim Geschäftsf.: Jürgen Bosse, Jörn Bosse
Germany

Tel: +49-89-8006390 http://www.robo-technology.de
Fax: +49-89-807917 juergen.bosse@robo-technology.de
Mob: +49-171-5178540
_____________________________________________________________________
juergen.bosse@robo-technology.de
 
Posts: 132
Joined: Tue Jul 09, 2002 5:00 pm

Re: [adept_software] Trouble with Viper s650.

Postby juergen.bosse@robo-technology.de » Sun Jan 04, 2009 5:00 pm

Hi Ottavio,

... and you say you are "only" a mechanical engineer with "good"
knowledge of robots.... you may safely call yourself an expert, if you
ask me!


Anyway - from all you told us about this system, I'd say, you have
either a mechanical problem in Jt3 (if there is something loose, you can
get this kind of vibrations. It may be just barely ok when the grease is
cold and sticky) or you have a bad amp / cable / motor. But we still
can't see how an electrical problem would develop over time, except,
maybe thermally.

Since you have already exchanged the MB60R, I would find it very
unlikely that this is still giving you troubles. Then again, the 24V
overvoltage that you have most certainly experienced, might have killed
more than the MB60R. An analysis of the faulty unit by Adept can tell us
more about this question. And you should definately have this done,
given those pending warranty/sabotage questions.

If you had another s650, you could of course check that robot using the
MB60R currently in use. But I suspect you don't.

Ok, on the other observations: 42°C is not uncommon for a AC brushless
motor. That it takes only 10 minutes to warm up is faster than I'd
expect, but I don't know your application's duty cycle. It may be
alright. How does J2 warm up?

The vibration going away under asymmetric load again points to a
mechanical problem. If it were noise in the amp, it would still vibrate
under load, though the dampening would be higher. It could be a problem
in the gear. For example, if you run a Cobra in 3 shifts for 8-10 years,
under full load, the Harmonic Drive gears for J1 and J2 wear away
(that's ok, it's twice their design life). What you get then, is a mix
of positioning errors and vibrations (although those are much lower
frequency, it's more of a wobble). I have seen one case where I was able
to pull the joint over a certain internal mechanical obstacle and offset
it by about 2 degrees without the encoder knowing of this. Reteach all
the points and it would be OK (because the motor position is correct,
it's only that the gear has slipped through). Then you could push it
back to where it was and it would be euqally stable there. Again - this
is a 10-year old robot, and that's a good age for such a machine. But
your robot is more or less brand-new and shouldn't have any of those
phenomena.

BTW: The controller will not report the vibration as a position error
because of the filtering. The MEAN value is where it wants it to be, so
there is no error, until the amplitude becomes too high or the duty
cycle check kicks in.


If it didn't have this trouble before, and it does have the trouble now,
something has happened to it. The apparent damage to the connector can
only be caused by completely inappropriate handling. How much of that
has to do with the Jt3 problem remains to be seen, but if you had the
customer pre-accept the system on your premises and there was no
apparent shipping accident, you can narrow down the time when it must
have happened, get a list of people with access to the site over the
weekend, etc, etc. It's all ugly from there on, but from what you say,
it looks like it's the route that you must take...


You haven't told us about the limit stop test. Since we suspect a
mechanical loose somewhere, I'd like you to try something more
sophisticated: Move the joint slowly to its stop and read the joint
position. Then, jerk the joint back quickly and return slowly to the
stop. Read position. Then move it out slow, jerk it forward, but without
hitting the stop yet. Then, move forward to the stop slowly and read the
position. Try this with J2 and J3 to see how it differs. Oh, since you
don't have a Brake Release Box, here is the pinout of the connector:
Pin 3: Release3_N
Pin 7: GND
Pin 9: 24V
So you just short pins 3 and 9, but with HIGH POWER off please!!


Let us know....

Juergen




Ottavio Berbakow schrieb:
> Jurgen,
>
> thanks for the extensive response (always so precise), I always try to
> read all your (and others) Adept posts on the newsgroup, to learn a
> little more, they are very interesting, and found out lots of common
> problems also, to feel that somehow i run into the same troubles in
> putting systems to work as everybody else, hahaha!! In this robot
> world, you can always find the new and exotic ways of getting crazy.
> As for your test suggestions on the vibration issues, we anticipate
> somehow your measures and proceeded to try some tests on the system
> ourselves, and this is what we found out:
>
> 1 - After initial power up, in manual mode, everything seems to be ok.
> The robot behaves normally. We can jog the robot around with no
> problem whatsoever. We also left the robot still, on "servo"
> condition, without any problems.
>
> 2 - In automatic mode, running a normal pick and place routine (back
> and forward and so on), the robot functions with no problems. After 2
> o 3 minutes, the vibration starts. It is strange, first the vibration
> doesn´t disturb the robot in terms of performance, it still does the
> job, the robot cycle is normal, even if it´s vibrating. After a while,
> the robot starts to get stuck on the "down" position (noticeably while
> using mostly J3) of the pick and place routine, not respecting any
> cycle time. On the other side, the most strange thing is that we don´t
> have any reports on the AdeptDesktop software, it continues to work
> with no alarms or warnings, even if the robot is standing still
> vibrating instead of keeping on moving (not even a position error or
> something similar!!).
>
> 3 - While in vibrating still condition, I applied some force to the
> robot flange, trying to dampen the vibrations on the system, and it
> did work, for some seconds the vibration goes away, and then resumes.
> I put something like a 8-10 Kg force on the J3-J4-J5-J6 assembly (on
> the robot flange), and the vibration decreases almost to disappear for
> a while. I don´t perceive any grainy or unfamiliar sound on the joint
> while the robot is in normal condition. I don´t have a brake release
> box, please indicate how to loose or free the axes in order to perform
> the tests you suggest.
>
> 5 - To isolate the problem, I wrote another simple program, cycling
> the first 3 different joints separately, and found out that is with no
> doubt J3 the axis which is causing the problem. Joint 3 got stuck
> after a couple of cycles. Please look at the videos attached.
>
> 4 - By saying that, and maybe you will agree with me, I feel that on
> one side maybe the vibrations are not caused by mechanical issues,
> since they would arise as soon as I turn on the servo condition. On
> the other side, if the joint is somehow stuck (but not strong enough)
> or the brakes are not working properly, that would lead soon into
> unstability condition, like the same effect on having a larger payload
> on the robot. I have some experience tuning and troubleshooting servos
> (yaskawa, parker, etc), and motion control systems (galil, yaskawa,
> parker), and when we have backlash, poor mechanics or tuning problems,
> the problem shows almost immediatly, and in a very similar way (maybe
> not so soon in tuning malfunctions, as they sometimes only require a
> disturbance to appear). The behavior of the system to me has something
> related to duty, or thermal issues to me, but of course this is
> something that is debatable, it is my perception. On the other side,
> as you mention, the servo condition is mantained even if it is
> vibrating, so the encoder seems to be working, it doesn´t have a
> runaway condition or similar. The robot system is grounded and
> customer demanded an UPS unit to protect the power supply (which we
> didn´t like at the beginning due to the inevitable presence of high
> frequency noise in this type of devices), since they have monstruous
> variations in tension in the plant.
>
> 5 - The servo unit starts with a surface temperature of 33 °C, and
> after a couple of minutes reaches 42 °C. By "hand" inspection, i feel
> that maybe the heat accumulated is excessive for the kind of duty we
> are applying, but could be anything, at this point i suspect of almost
> everything. On the other side, the sporadically message of D3 should
> say something regarding the heating and duty.
>
> 6 - Adept technician suggested me on the phone to exchange the J3
> servo drive unit on the new MB60R with the other damaged Mb60R axes(on
> the lower power axes they are stacked in 2, with J3 and J4 sharing the
> same card), I opened up the unit, and found where the cards where, but
> I really didn´t want to proceed, since the unit is still in warranty,
> and don´t want to mess around without any proper instruction on how to
> open the MB60R (they didn´t have the manual either). I´m a mechanical
> engineer with good knowledge of robots (Fanuc, Motoman and Adept) and
> servos, but power electronics is still tabu soil to me, even if i
> suspect where the problem is, sure you understand the situation. On
> the other side, I was not responsible to sell the unit, it was Adept
> distributor in Argentina, which reached us to integrate the system, so
> my labour has been so far beyond the strict line of duty.
>
> 7 - The question that now arises is: in your technical opinion could
> it be that the improper or hazardous attempts (which I told you about
> on the previous email) with the connectors and god knows what else,
> could lead into this mess? The answer question is fundamental for
> warranty issues.
>
> I´m sorry to bother you with this questions, hope you can help us out
> on this. Thanks for everything,
>
> Regards
>
> Ottavio
>
>
> Juergen Bosse escribió:
>> Hi Ottavio,
>>
>> well that sounds like a proper nightmare to me. I think the only
>> thing you could have done to make it worse would have been to crash
>> the gripper into a customer fixture while troubleshooting it.
>> Repeatedly, preferrably.
>>
>> But let me tell you that you are one of very very few people on this
>> group who take the time to write up a very detailled description of
>> the system, the fault and incidental observations. Well done!
>> Hopefully, we'll be able to help you find the root cause quickly.
>>
>>
>> Ok, so let's look at the issues one by one.
>>
>> 1) fire-miswire
>>
>> Basically, you can use ports 1.1 and 1.2 interchangeably. The system
>> doesn't even notice. That by itself would not have done it any harm.
>> Jamming the connector wrongly into the socket is not a valid
>> operation, though. In fact, what happens is that pins 1 and 2 (24V),
>> connect to pins 6 and 5 (data lines) and that will most certainly
>> smoke the MB60R's firewire circuitry. Any recovery you try after that
>> will be doomed. The RSC problems are caused by the inability to even
>> access the MB60R correctly.
>>
>> 2) New MB60R reports encoder errors first, but then works ok
>>
>> This behaviour is to be expected during the initialization, but no
>> more after that. Does it complain about E0-E6 every time you power up
>> or was it only the first time?
>>
>> 3) Vibration on Jt3
>>
>> Well I have experienced some mild Jt2/Jt3 vibration on the Viper
>> s850, but it was definately less than 0.1-0.2mm and only occured in
>> certain positions, where the position of the joints together with the
>> weight of our endeffector caused the resonant frequency to be excited
>> by small vibrations from the drive train. But this is a purely
>> mechanical issue and doesn't develop over time. It's either there or
>> not.
>>
>> So the behavior you see must be either thermal, electrical, or maybe
>> mechanical in a way you have a loose coupling or bad gear. Since you
>> can still servo with the vibration, I think we can rule out a bad
>> encoder signal or data transmission, as it is all digital and would
>> stop working altogether if there were any issues with it. More
>> likely, you have a bad motor (maybe broken motor wire) or bad
>> amplifier (you're keen on changing the MB60R AGAIN?).
>>
>> Now back in the old days of PA4, we could have swapped individual
>> amps to isolate the problem... but not on the MB60R afaik.
>>
>> You can try to heat/cool the motor, the cables, the MB60R (within
>> reason, please!), shake cables, inspect the wiring inside the robot,
>> and you can use SPEC to diagnose motors individually. To be honest,
>> if I were on site to hunt down this bug, I would try various random
>> things, and learn from the observations. Try to move the joint by
>> hand with the brakes released manually. Try to move the joint against
>> the brake. It should not give way at all (until you exert too much
>> force for the brake) Try to measure the ohm resistance of the motor
>> windings of each motor. Between the three phases, you should have a
>> very similar reading for each pair (1-2, 2-3, 3-1) per motor. Try to
>> move the joint from hard stop to hard stop and read the encoder. It
>> should reproduce within 0.01-0.02 degrees in the stops. Try this 5
>> times or so.
>>
>> Well - let us know what you find. Hopefully we can fix it quickly.
>>
>> Best regards and good luck - you'll need it.
>>
>> Juergen
>>
>>
>>
>> Ottavio Berbakow schrieb:
>>> Hello Everybody,
>>>
>>> Robot: Viper s650
>>> Controller: CX
>>> Servo Drive Unit: MB-60R
>>>
>>> I´m currently integrating a Viper s650 for a simple pick and place
>>> machine tending operation, and the process has been something like a
>>> nightmare. Maybe one month and a half ago, while comissioning the
>>> system, we had a fatal failure in the system, all six encoders were
>>> bad, and also had an RSC failure (initial message). The cause? Well,
>>> we left the robot (only the mechanical unit) in the laboratory on
>>> Friday night, in order to put it to work again on Monday morning,
>>> leaving the controller and electrical cabinet on application site.
>>> When we had the failure, we found that the firewire cables were
>>> plugged wrongly on the CX (like somebody removed from port 1.1 and
>>> put it on 1.2), but also finding the ports somehow damaged and
>>> deformed, almost like somebody tried to plug it in the wrong way and
>>> then powered on the system. We found also that one of the firewire
>>> ports on the MB-60R unit was damaged. I really don´t know if this
>>> type of "sabotage" could produce this type of damage, but the thing
>>> is that the system was working perfectly when we left it. Judge by
>>> yourselves.
>>>
>>> First we tried to fix the RSC problem by using the rsc_set, and
>>> RSC_RSTR restore programs, with poor results, after that, we tried
>>> to use the original RSC file to commit to the robot, without any
>>> results. After that, Adept sent us a new RSC card to change the
>>> currently installed, and the result was the same. On the RSC
>>> management programs, we had always that the system could not verify
>>> the encoders, hardware status code: 22. We could not commit any data
>>> into the RSC, and also we had encoder failure -1025 on the Adept
>>> Desktop screen.
>>>
>>> We checked the encoder power supply system, and everything was ok
>>> (using also the Denso Manual). Just to make the story short, we
>>> tried every possible way to troubleshoot the system, but the result
>>> were always E0 up to E6, RC on our MB-60R unit. On the other side,
>>> AS explained before, this unit had also one of the firewire (1.1)
>>> ports damaged, since we could not even find the network when we
>>> wrote SRV.N on the terminal. In order to find the network we needed
>>> to plug the cable to the 1.2 connector. Anyway, finally, suspecting
>>> that maybe the MB60R unit was the problem (since we had normal
>>> readings on the voltages of the encoder power supply, and also the
>>> voltage supply to the RSC), Adept sent us a new MB60R unit. When we
>>> installed, it immediatly recognized the RSC and hardware settings,
>>> and proceed to perform full data commit into the robot, by using our
>>> original RSC file. We finally made to load all the configurations,
>>> and even if we received some strange messages warning that some data
>>> could not still be committed to robot, the data finally got into the
>>> system. We checked the current values and parameters, and eveything
>>> seems to be correct. The system promptly responded with a OK
>>> message, and then, after a calibration, we had our ON status. When
>>> we power up the unit, in a very short burst, a message of E0 appears
>>> on the MB-60R unit, and then disappears, leaving place to the OK
>>> message.
>>>
>>> The robot is capable of moving without any problem, running programs
>>> and all, but after a while we are experiencing a heavy vibration on
>>> the servo motors, seeming almost like a tuning issue. We removed the
>>> gripper in order to exclude overweight or the effect of inertia, but
>>> it didn´t change much, after a while the system starts to vibrate
>>> heavily, specially on axis N°3. If we issue a power down on the
>>> servos, and then power on again, the systems behaves normally, and
>>> after a while vibration starts again. Is there a way we can
>>> troubleshoot this vibration and noise? While in this state, the
>>> system usually does not issue an alarm (we had only once a D3 alarm,
>>> a duty cycle alarm for joint3, on a very low speed, maybe due to
>>> heavy vibration), and we can run programs, and also jog the robot
>>> with the vibration on. Is there a way that maybe some servo
>>> parameters can be adjusted to eliminate this problem?? Do we need to
>>> perform any more calibrations beside the one we did on the system
>>> restore?? Could it be the surface in which we mounted the system,
>>> maybe resonating at some point with the robot structure? If anyone
>>> has experienced something like this before, please advice,
>>>
>>> Regards
>>>
>>>
>>>
>>
>

--
_____________________________________________________________________

Juergen Bosse
Robo-Technology GmbH Sitz der Gesellschaft: Puchheim
Benzstrasse 12 Amtsgericht München HRB 140072
82178 Puchheim Geschäftsf.: Jürgen Bosse, Jörn Bosse
Germany

Tel: +49-89-8006390 http://www.robo-technology.de
Fax: +49-89-807917 juergen.bosse@robo-technology.de
Mob: +49-171-5178540
_____________________________________________________________________
juergen.bosse@robo-technology.de
 
Posts: 132
Joined: Tue Jul 09, 2002 5:00 pm

Re: [adept_software] Trouble with Viper s650.

Postby juergen.bosse@robo-technology.de » Fri Jan 09, 2009 5:00 pm

Hi Ottavio,

from all this, my best guess is a thermal problem, either amp or motor,
with a tendency towards the amplifier.

The repeatability is very good, so the arm doesn't seem to be damaged.

That's about all I can say without seeing it myself (and I probably
wouldn't know more if I were on site).

Best regards,
Juergen


Ottavio Berbakow schrieb:
> Jurgen,
>
> I tried some of your testing methods, and these are some of the results:
>
> Test #1 (repeatibility on hard stops)
>
> After releasing the brake, we read the joint values in both hard
> stops, to verify possible backlash problems, and these are the
> results, after 3 tests of 5 moves each:
>
> Forward position 258.128°/258.129°/258.130°/258.127°/258.131°
> Backward position -30.960°/-30.958°/-30.960°/-30.960°/-30.962°
>
> Test #2 (repeatibility on hard stops after jerky motion)
>
> We performed this test around 4 times, with very similar results, none
> of them indicating backlash.
>
> 1st movement (slowly to forward hard stop): 258.131°
> 2nd movement (jerk backwards violently and then gentle to forward hard
> stop): 258.133°
> 3rd movement (slowly retracting, then violent jerky movement before
> hard stop and the hitting gently forward hardstop): 258.128°
>
> Test #3 (appearance of J3 vibration timing on Automatic operation)
>
> After 1:50 minutes of function on 65% speed, the first vibration appears.
> High power is then disabled and then enabled again, vibration starts
> after 40 segs in auto mode.
> General shutdown of all robot systems, and after enabling power again,
> vibration occurs at 1:25 minutes in auto mode.
>
> On a general point of view, vibration seems to appear as soon as the
> system start to build up some thermal condition.
>
> Test #4 (deflection of J6 flange with asimmetrical force applied)
>
> With brakes on, we verify a very small backlash on J3, and overall J6
> deflection when applying force to the J3 arm is around 0.8/1.0 mm. The
> feeling of the backlash on joint is very subtle, the joint have a null
> resistance point before engaging the hardware.
> This test is not conclusive for sure, we cannot say this is the cause
> of the problem, since vibration does not start immediatly. Any
> resonance/normal frequency test should be done at proper technical
> service facility.
>
> I didn´t perform the special spec mode test, since I didn´t have more
> time to do it.
> Let me know your thoughts on this,
>
> Regards
>
> Ottavio
>
>
>
> Juergen Bosse escribió:
>> Hi Ottavio,
>>
>> ... and you say you are "only" a mechanical engineer with "good"
>> knowledge of robots.... you may safely call yourself an expert, if
>> you ask me!
>>
>>
>> Anyway - from all you told us about this system, I'd say, you have
>> either a mechanical problem in Jt3 (if there is something loose, you
>> can get this kind of vibrations. It may be just barely ok when the
>> grease is cold and sticky) or you have a bad amp / cable / motor. But
>> we still can't see how an electrical problem would develop over time,
>> except, maybe thermally.
>>
>> Since you have already exchanged the MB60R, I would find it very
>> unlikely that this is still giving you troubles. Then again, the 24V
>> overvoltage that you have most certainly experienced, might have
>> killed more than the MB60R. An analysis of the faulty unit by Adept
>> can tell us more about this question. And you should definately have
>> this done, given those pending warranty/sabotage questions.
>>
>> If you had another s650, you could of course check that robot using
>> the MB60R currently in use. But I suspect you don't.
>>
>> Ok, on the other observations: 42°C is not uncommon for a AC
>> brushless motor. That it takes only 10 minutes to warm up is faster
>> than I'd expect, but I don't know your application's duty cycle. It
>> may be alright. How does J2 warm up?
>>
>> The vibration going away under asymmetric load again points to a
>> mechanical problem. If it were noise in the amp, it would still
>> vibrate under load, though the dampening would be higher. It could be
>> a problem in the gear. For example, if you run a Cobra in 3 shifts
>> for 8-10 years, under full load, the Harmonic Drive gears for J1 and
>> J2 wear away (that's ok, it's twice their design life). What you get
>> then, is a mix of positioning errors and vibrations (although those
>> are much lower frequency, it's more of a wobble). I have seen one
>> case where I was able to pull the joint over a certain internal
>> mechanical obstacle and offset it by about 2 degrees without the
>> encoder knowing of this. Reteach all the points and it would be OK
>> (because the motor position is correct, it's only that the gear has
>> slipped through). Then you could push it back to where it was and it
>> would be euqally stable there. Again - this is a 10-year old robot,
>> and that's a good age for such a machine. But your robot is more or
>> less brand-new and shouldn't have any of those phenomena.
>>
>> BTW: The controller will not report the vibration as a position error
>> because of the filtering. The MEAN value is where it wants it to be,
>> so there is no error, until the amplitude becomes too high or the
>> duty cycle check kicks in.
>>
>>
>> If it didn't have this trouble before, and it does have the trouble
>> now, something has happened to it. The apparent damage to the
>> connector can only be caused by completely inappropriate handling.
>> How much of that has to do with the Jt3 problem remains to be seen,
>> but if you had the customer pre-accept the system on your premises
>> and there was no apparent shipping accident, you can narrow down the
>> time when it must have happened, get a list of people with access to
>> the site over the weekend, etc, etc. It's all ugly from there on, but
>> from what you say, it looks like it's the route that you must take...
>>
>>
>> You haven't told us about the limit stop test. Since we suspect a
>> mechanical loose somewhere, I'd like you to try something more
>> sophisticated: Move the joint slowly to its stop and read the joint
>> position. Then, jerk the joint back quickly and return slowly to the
>> stop. Read position. Then move it out slow, jerk it forward, but
>> without hitting the stop yet. Then, move forward to the stop slowly
>> and read the position. Try this with J2 and J3 to see how it differs.
>> Oh, since you don't have a Brake Release Box, here is the pinout of
>> the connector:
>> Pin 3: Release3_N
>> Pin 7: GND
>> Pin 9: 24V
>> So you just short pins 3 and 9, but with HIGH POWER off please!!
>>
>>
>> Let us know....
>>
>> Juergen
>>
>>
>>
>>
>> Ottavio Berbakow schrieb:
>>> Jurgen,
>>>
>>> thanks for the extensive response (always so precise), I always try
>>> to read all your (and others) Adept posts on the newsgroup, to learn
>>> a little more, they are very interesting, and found out lots of
>>> common problems also, to feel that somehow i run into the same
>>> troubles in putting systems to work as everybody else, hahaha!! In
>>> this robot world, you can always find the new and exotic ways of
>>> getting crazy. As for your test suggestions on the vibration issues,
>>> we anticipate somehow your measures and proceeded to try some tests
>>> on the system ourselves, and this is what we found out:
>>>
>>> 1 - After initial power up, in manual mode, everything seems to be
>>> ok. The robot behaves normally. We can jog the robot around with no
>>> problem whatsoever. We also left the robot still, on "servo"
>>> condition, without any problems.
>>>
>>> 2 - In automatic mode, running a normal pick and place routine (back
>>> and forward and so on), the robot functions with no problems. After
>>> 2 o 3 minutes, the vibration starts. It is strange, first the
>>> vibration doesn´t disturb the robot in terms of performance, it
>>> still does the job, the robot cycle is normal, even if it´s
>>> vibrating. After a while, the robot starts to get stuck on the
>>> "down" position (noticeably while using mostly J3) of the pick and
>>> place routine, not respecting any cycle time. On the other side, the
>>> most strange thing is that we don´t have any reports on the
>>> AdeptDesktop software, it continues to work with no alarms or
>>> warnings, even if the robot is standing still vibrating instead of
>>> keeping on moving (not even a position error or something similar!!).
>>>
>>> 3 - While in vibrating still condition, I applied some force to the
>>> robot flange, trying to dampen the vibrations on the system, and it
>>> did work, for some seconds the vibration goes away, and then
>>> resumes. I put something like a 8-10 Kg force on the J3-J4-J5-J6
>>> assembly (on the robot flange), and the vibration decreases almost
>>> to disappear for a while. I don´t perceive any grainy or unfamiliar
>>> sound on the joint while the robot is in normal condition. I don´t
>>> have a brake release box, please indicate how to loose or free the
>>> axes in order to perform the tests you suggest.
>>>
>>> 5 - To isolate the problem, I wrote another simple program, cycling
>>> the first 3 different joints separately, and found out that is with
>>> no doubt J3 the axis which is causing the problem. Joint 3 got stuck
>>> after a couple of cycles. Please look at the videos attached.
>>>
>>> 4 - By saying that, and maybe you will agree with me, I feel that on
>>> one side maybe the vibrations are not caused by mechanical issues,
>>> since they would arise as soon as I turn on the servo condition. On
>>> the other side, if the joint is somehow stuck (but not strong
>>> enough) or the brakes are not working properly, that would lead soon
>>> into unstability condition, like the same effect on having a larger
>>> payload on the robot. I have some experience tuning and
>>> troubleshooting servos (yaskawa, parker, etc), and motion control
>>> systems (galil, yaskawa, parker), and when we have backlash, poor
>>> mechanics or tuning problems, the problem shows almost immediatly,
>>> and in a very similar way (maybe not so soon in tuning malfunctions,
>>> as they sometimes only require a disturbance to appear). The
>>> behavior of the system to me has something related to duty, or
>>> thermal issues to me, but of course this is something that is
>>> debatable, it is my perception. On the other side, as you mention,
>>> the servo condition is mantained even if it is vibrating, so the
>>> encoder seems to be working, it doesn´t have a runaway condition or
>>> similar. The robot system is grounded and customer demanded an UPS
>>> unit to protect the power supply (which we didn´t like at the
>>> beginning due to the inevitable presence of high frequency noise in
>>> this type of devices), since they have monstruous variations in
>>> tension in the plant.
>>>
>>> 5 - The servo unit starts with a surface temperature of 33 °C, and
>>> after a couple of minutes reaches 42 °C. By "hand" inspection, i
>>> feel that maybe the heat accumulated is excessive for the kind of
>>> duty we are applying, but could be anything, at this point i suspect
>>> of almost everything. On the other side, the sporadically message of
>>> D3 should say something regarding the heating and duty.
>>>
>>> 6 - Adept technician suggested me on the phone to exchange the J3
>>> servo drive unit on the new MB60R with the other damaged Mb60R
>>> axes(on the lower power axes they are stacked in 2, with J3 and J4
>>> sharing the same card), I opened up the unit, and found where the
>>> cards where, but I really didn´t want to proceed, since the unit is
>>> still in warranty, and don´t want to mess around without any proper
>>> instruction on how to open the MB60R (they didn´t have the manual
>>> either). I´m a mechanical engineer with good knowledge of robots
>>> (Fanuc, Motoman and Adept) and servos, but power electronics is
>>> still tabu soil to me, even if i suspect where the problem is, sure
>>> you understand the situation. On the other side, I was not
>>> responsible to sell the unit, it was Adept distributor in Argentina,
>>> which reached us to integrate the system, so my labour has been so
>>> far beyond the strict line of duty.
>>>
>>> 7 - The question that now arises is: in your technical opinion could
>>> it be that the improper or hazardous attempts (which I told you
>>> about on the previous email) with the connectors and god knows what
>>> else, could lead into this mess? The answer question is fundamental
>>> for warranty issues.
>>>
>>> I´m sorry to bother you with this questions, hope you can help us
>>> out on this. Thanks for everything,
>>>
>>> Regards
>>>
>>> Ottavio
>>>
>>>
>>> Juergen Bosse escribió:
>>>> Hi Ottavio,
>>>>
>>>> well that sounds like a proper nightmare to me. I think the only
>>>> thing you could have done to make it worse would have been to crash
>>>> the gripper into a customer fixture while troubleshooting it.
>>>> Repeatedly, preferrably.
>>>>
>>>> But let me tell you that you are one of very very few people on
>>>> this group who take the time to write up a very detailled
>>>> description of the system, the fault and incidental observations.
>>>> Well done! Hopefully, we'll be able to help you find the root cause
>>>> quickly.
>>>>
>>>>
>>>> Ok, so let's look at the issues one by one.
>>>>
>>>> 1) fire-miswire
>>>>
>>>> Basically, you can use ports 1.1 and 1.2 interchangeably. The
>>>> system doesn't even notice. That by itself would not have done it
>>>> any harm. Jamming the connector wrongly into the socket is not a
>>>> valid operation, though. In fact, what happens is that pins 1 and 2
>>>> (24V), connect to pins 6 and 5 (data lines) and that will most
>>>> certainly smoke the MB60R's firewire circuitry. Any recovery you
>>>> try after that will be doomed. The RSC problems are caused by the
>>>> inability to even access the MB60R correctly.
>>>>
>>>> 2) New MB60R reports encoder errors first, but then works ok
>>>>
>>>> This behaviour is to be expected during the initialization, but no
>>>> more after that. Does it complain about E0-E6 every time you power
>>>> up or was it only the first time?
>>>>
>>>> 3) Vibration on Jt3
>>>>
>>>> Well I have experienced some mild Jt2/Jt3 vibration on the Viper
>>>> s850, but it was definately less than 0.1-0.2mm and only occured in
>>>> certain positions, where the position of the joints together with
>>>> the weight of our endeffector caused the resonant frequency to be
>>>> excited by small vibrations from the drive train. But this is a
>>>> purely mechanical issue and doesn't develop over time. It's either
>>>> there or not.
>>>>
>>>> So the behavior you see must be either thermal, electrical, or
>>>> maybe mechanical in a way you have a loose coupling or bad gear.
>>>> Since you can still servo with the vibration, I think we can rule
>>>> out a bad encoder signal or data transmission, as it is all digital
>>>> and would stop working altogether if there were any issues with it.
>>>> More likely, you have a bad motor (maybe broken motor wire) or bad
>>>> amplifier (you're keen on changing the MB60R AGAIN?).
>>>>
>>>> Now back in the old days of PA4, we could have swapped individual
>>>> amps to isolate the problem... but not on the MB60R afaik.
>>>>
>>>> You can try to heat/cool the motor, the cables, the MB60R (within
>>>> reason, please!), shake cables, inspect the wiring inside the
>>>> robot, and you can use SPEC to diagnose motors individually. To be
>>>> honest, if I were on site to hunt down this bug, I would try
>>>> various random things, and learn from the observations. Try to move
>>>> the joint by hand with the brakes released manually. Try to move
>>>> the joint against the brake. It should not give way at all (until
>>>> you exert too much force for the brake) Try to measure the ohm
>>>> resistance of the motor windings of each motor. Between the three
>>>> phases, you should have a very similar reading for each pair (1-2,
>>>> 2-3, 3-1) per motor. Try to move the joint from hard stop to hard
>>>> stop and read the encoder. It should reproduce within 0.01-0.02
>>>> degrees in the stops. Try this 5 times or so.
>>>>
>>>> Well - let us know what you find. Hopefully we can fix it quickly.
>>>>
>>>> Best regards and good luck - you'll need it.
>>>>
>>>> Juergen
>>>>
>>>>
>>>>
>>>> Ottavio Berbakow schrieb:
>>>>> Hello Everybody,
>>>>>
>>>>> Robot: Viper s650
>>>>> Controller: CX
>>>>> Servo Drive Unit: MB-60R
>>>>>
>>>>> I´m currently integrating a Viper s650 for a simple pick and place
>>>>> machine tending operation, and the process has been something like
>>>>> a nightmare. Maybe one month and a half ago, while comissioning
>>>>> the system, we had a fatal failure in the system, all six encoders
>>>>> were bad, and also had an RSC failure (initial message). The
>>>>> cause? Well, we left the robot (only the mechanical unit) in the
>>>>> laboratory on Friday night, in order to put it to work again on
>>>>> Monday morning, leaving the controller and electrical cabinet on
>>>>> application site. When we had the failure, we found that the
>>>>> firewire cables were plugged wrongly on the CX (like somebody
>>>>> removed from port 1.1 and put it on 1.2), but also finding the
>>>>> ports somehow damaged and deformed, almost like somebody tried to
>>>>> plug it in the wrong way and then powered on the system. We found
>>>>> also that one of the firewire ports on the MB-60R unit was
>>>>> damaged. I really don´t know if this type of "sabotage" could
>>>>> produce this type of damage, but the thing is that the system was
>>>>> working perfectly when we left it. Judge by yourselves.
>>>>>
>>>>> First we tried to fix the RSC problem by using the rsc_set, and
>>>>> RSC_RSTR restore programs, with poor results, after that, we tried
>>>>> to use the original RSC file to commit to the robot, without any
>>>>> results. After that, Adept sent us a new RSC card to change the
>>>>> currently installed, and the result was the same. On the RSC
>>>>> management programs, we had always that the system could not
>>>>> verify the encoders, hardware status code: 22. We could not commit
>>>>> any data into the RSC, and also we had encoder failure -1025 on
>>>>> the Adept Desktop screen.
>>>>>
>>>>> We checked the encoder power supply system, and everything was ok
>>>>> (using also the Denso Manual). Just to make the story short, we
>>>>> tried every possible way to troubleshoot the system, but the
>>>>> result were always E0 up to E6, RC on our MB-60R unit. On the
>>>>> other side, AS explained before, this unit had also one of the
>>>>> firewire (1.1) ports damaged, since we could not even find the
>>>>> network when we wrote SRV.N on the terminal. In order to find the
>>>>> network we needed to plug the cable to the 1.2 connector. Anyway,
>>>>> finally, suspecting that maybe the MB60R unit was the problem
>>>>> (since we had normal readings on the voltages of the encoder power
>>>>> supply, and also the voltage supply to the RSC), Adept sent us a
>>>>> new MB60R unit. When we installed, it immediatly recognized the
>>>>> RSC and hardware settings, and proceed to perform full data commit
>>>>> into the robot, by using our original RSC file. We finally made to
>>>>> load all the configurations, and even if we received some strange
>>>>> messages warning that some data could not still be committed to
>>>>> robot, the data finally got into the system. We checked the
>>>>> current values and parameters, and eveything seems to be correct.
>>>>> The system promptly responded with a OK message, and then, after a
>>>>> calibration, we had our ON status. When we power up the unit, in a
>>>>> very short burst, a message of E0 appears on the MB-60R unit, and
>>>>> then disappears, leaving place to the OK message.
>>>>>
>>>>> The robot is capable of moving without any problem, running
>>>>> programs and all, but after a while we are experiencing a heavy
>>>>> vibration on the servo motors, seeming almost like a tuning issue.
>>>>> We removed the gripper in order to exclude overweight or the
>>>>> effect of inertia, but it didn´t change much, after a while the
>>>>> system starts to vibrate heavily, specially on axis N°3. If we
>>>>> issue a power down on the servos, and then power on again, the
>>>>> systems behaves normally, and after a while vibration starts
>>>>> again. Is there a way we can troubleshoot this vibration and
>>>>> noise? While in this state, the system usually does not issue an
>>>>> alarm (we had only once a D3 alarm, a duty cycle alarm for joint3,
>>>>> on a very low speed, maybe due to heavy vibration), and we can run
>>>>> programs, and also jog the robot with the vibration on. Is there a
>>>>> way that maybe some servo parameters can be adjusted to eliminate
>>>>> this problem?? Do we need to perform any more calibrations beside
>>>>> the one we did on the system restore?? Could it be the surface in
>>>>> which we mounted the system, maybe resonating at some point with
>>>>> the robot structure? If anyone has experienced something like this
>>>>> before, please advice,
>>>>>
>>>>> Regards
>>>>>
>>>>>
>>>>>
>>>>
>>>
>>
>

--
_____________________________________________________________________

Juergen Bosse
Robo-Technology GmbH Sitz der Gesellschaft: Puchheim
Benzstrasse 12 Amtsgericht München HRB 140072
82178 Puchheim Geschäftsf.: Jürgen Bosse, Jörn Bosse
Germany

Tel: +49-89-8006390 http://www.robo-technology.de
Fax: +49-89-807917 juergen.bosse@robo-technology.de
Mob: +49-171-5178540
_____________________________________________________________________
juergen.bosse@robo-technology.de
 
Posts: 132
Joined: Tue Jul 09, 2002 5:00 pm

Re: [adept_software] Trouble with Viper s650.

Postby juergen.bosse@robo-technology.de » Thu Jan 15, 2009 5:00 pm

You're welcome!
Glad it works again.
Thanks,
Juergen


Ottavio Berbakow schrieb:
> Dear Jurgen,
>
> finally, after several attempts, we trade the power stages of axes
> 3-4, and 5-6 on the new unit, with the ones from the previously
> damaged MB60R, and the system responded OK, had it running for about
> 1.5 hours, 100% duty, with no problems whatsoever. So finally what
> happened was that the replacement unit had weak servo drives.
> Thanks for all the excellent support,
>
> Regards
>
> Ottavio
>
> Juergen Bosse escribió:
>> Hi Ottavio,
>>
>> from all this, my best guess is a thermal problem, either amp or
>> motor, with a tendency towards the amplifier.
>>
>> The repeatability is very good, so the arm doesn't seem to be damaged.
>>
>> That's about all I can say without seeing it myself (and I probably
>> wouldn't know more if I were on site).
>>
>> Best regards,
>> Juergen
>>
>>
>> Ottavio Berbakow schrieb:
>>> Jurgen,
>>>
>>> I tried some of your testing methods, and these are some of the
>>> results:
>>>
>>> Test #1 (repeatibility on hard stops)
>>>
>>> After releasing the brake, we read the joint values in both hard
>>> stops, to verify possible backlash problems, and these are the
>>> results, after 3 tests of 5 moves each:
>>>
>>> Forward position 258.128°/258.129°/258.130°/258.127°/258.131°
>>> Backward position -30.960°/-30.958°/-30.960°/-30.960°/-30.962°
>>>
>>> Test #2 (repeatibility on hard stops after jerky motion)
>>>
>>> We performed this test around 4 times, with very similar results,
>>> none of them indicating backlash.
>>>
>>> 1st movement (slowly to forward hard stop): 258.131°
>>> 2nd movement (jerk backwards violently and then gentle to forward
>>> hard stop): 258.133°
>>> 3rd movement (slowly retracting, then violent jerky movement before
>>> hard stop and the hitting gently forward hardstop): 258.128°
>>>
>>> Test #3 (appearance of J3 vibration timing on Automatic operation)
>>>
>>> After 1:50 minutes of function on 65% speed, the first vibration
>>> appears.
>>> High power is then disabled and then enabled again, vibration starts
>>> after 40 segs in auto mode.
>>> General shutdown of all robot systems, and after enabling power
>>> again, vibration occurs at 1:25 minutes in auto mode.
>>>
>>> On a general point of view, vibration seems to appear as soon as the
>>> system start to build up some thermal condition.
>>>
>>> Test #4 (deflection of J6 flange with asimmetrical force applied)
>>>
>>> With brakes on, we verify a very small backlash on J3, and overall
>>> J6 deflection when applying force to the J3 arm is around 0.8/1.0
>>> mm. The feeling of the backlash on joint is very subtle, the joint
>>> have a null resistance point before engaging the hardware.
>>> This test is not conclusive for sure, we cannot say this is the
>>> cause of the problem, since vibration does not start immediatly. Any
>>> resonance/normal frequency test should be done at proper technical
>>> service facility.
>>>
>>> I didn´t perform the special spec mode test, since I didn´t have
>>> more time to do it.
>>> Let me know your thoughts on this,
>>>
>>> Regards
>>>
>>> Ottavio
>>>
>>>
>>>
>>> Juergen Bosse escribió:
>>>> Hi Ottavio,
>>>>
>>>> ... and you say you are "only" a mechanical engineer with "good"
>>>> knowledge of robots.... you may safely call yourself an expert,
>>>> if you ask me!
>>>>
>>>>
>>>> Anyway - from all you told us about this system, I'd say, you have
>>>> either a mechanical problem in Jt3 (if there is something loose,
>>>> you can get this kind of vibrations. It may be just barely ok when
>>>> the grease is cold and sticky) or you have a bad amp / cable /
>>>> motor. But we still can't see how an electrical problem would
>>>> develop over time, except, maybe thermally.
>>>>
>>>> Since you have already exchanged the MB60R, I would find it very
>>>> unlikely that this is still giving you troubles. Then again, the
>>>> 24V overvoltage that you have most certainly experienced, might
>>>> have killed more than the MB60R. An analysis of the faulty unit by
>>>> Adept can tell us more about this question. And you should
>>>> definately have this done, given those pending warranty/sabotage
>>>> questions.
>>>>
>>>> If you had another s650, you could of course check that robot using
>>>> the MB60R currently in use. But I suspect you don't.
>>>>
>>>> Ok, on the other observations: 42°C is not uncommon for a AC
>>>> brushless motor. That it takes only 10 minutes to warm up is faster
>>>> than I'd expect, but I don't know your application's duty cycle. It
>>>> may be alright. How does J2 warm up?
>>>>
>>>> The vibration going away under asymmetric load again points to a
>>>> mechanical problem. If it were noise in the amp, it would still
>>>> vibrate under load, though the dampening would be higher. It could
>>>> be a problem in the gear. For example, if you run a Cobra in 3
>>>> shifts for 8-10 years, under full load, the Harmonic Drive gears
>>>> for J1 and J2 wear away (that's ok, it's twice their design life).
>>>> What you get then, is a mix of positioning errors and vibrations
>>>> (although those are much lower frequency, it's more of a wobble). I
>>>> have seen one case where I was able to pull the joint over a
>>>> certain internal mechanical obstacle and offset it by about 2
>>>> degrees without the encoder knowing of this. Reteach all the points
>>>> and it would be OK (because the motor position is correct, it's
>>>> only that the gear has slipped through). Then you could push it
>>>> back to where it was and it would be euqally stable there. Again -
>>>> this is a 10-year old robot, and that's a good age for such a
>>>> machine. But your robot is more or less brand-new and shouldn't
>>>> have any of those phenomena.
>>>>
>>>> BTW: The controller will not report the vibration as a position
>>>> error because of the filtering. The MEAN value is where it wants it
>>>> to be, so there is no error, until the amplitude becomes too high
>>>> or the duty cycle check kicks in.
>>>>
>>>>
>>>> If it didn't have this trouble before, and it does have the trouble
>>>> now, something has happened to it. The apparent damage to the
>>>> connector can only be caused by completely inappropriate handling.
>>>> How much of that has to do with the Jt3 problem remains to be seen,
>>>> but if you had the customer pre-accept the system on your premises
>>>> and there was no apparent shipping accident, you can narrow down
>>>> the time when it must have happened, get a list of people with
>>>> access to the site over the weekend, etc, etc. It's all ugly from
>>>> there on, but from what you say, it looks like it's the route that
>>>> you must take...
>>>>
>>>>
>>>> You haven't told us about the limit stop test. Since we suspect a
>>>> mechanical loose somewhere, I'd like you to try something more
>>>> sophisticated: Move the joint slowly to its stop and read the joint
>>>> position. Then, jerk the joint back quickly and return slowly to
>>>> the stop. Read position. Then move it out slow, jerk it forward,
>>>> but without hitting the stop yet. Then, move forward to the stop
>>>> slowly and read the position. Try this with J2 and J3 to see how it
>>>> differs. Oh, since you don't have a Brake Release Box, here is the
>>>> pinout of the connector:
>>>> Pin 3: Release3_N
>>>> Pin 7: GND
>>>> Pin 9: 24V
>>>> So you just short pins 3 and 9, but with HIGH POWER off please!!
>>>>
>>>>
>>>> Let us know....
>>>>
>>>> Juergen
>>>>
>>>>
>>>>
>>>>
>>>> Ottavio Berbakow schrieb:
>>>>> Jurgen,
>>>>>
>>>>> thanks for the extensive response (always so precise), I always
>>>>> try to read all your (and others) Adept posts on the newsgroup, to
>>>>> learn a little more, they are very interesting, and found out lots
>>>>> of common problems also, to feel that somehow i run into the same
>>>>> troubles in putting systems to work as everybody else, hahaha!! In
>>>>> this robot world, you can always find the new and exotic ways of
>>>>> getting crazy. As for your test suggestions on the vibration
>>>>> issues, we anticipate somehow your measures and proceeded to try
>>>>> some tests on the system ourselves, and this is what we found out:
>>>>>
>>>>> 1 - After initial power up, in manual mode, everything seems to be
>>>>> ok. The robot behaves normally. We can jog the robot around with
>>>>> no problem whatsoever. We also left the robot still, on "servo"
>>>>> condition, without any problems.
>>>>>
>>>>> 2 - In automatic mode, running a normal pick and place routine
>>>>> (back and forward and so on), the robot functions with no
>>>>> problems. After 2 o 3 minutes, the vibration starts. It is
>>>>> strange, first the vibration doesn´t disturb the robot in terms of
>>>>> performance, it still does the job, the robot cycle is normal,
>>>>> even if it´s vibrating. After a while, the robot starts to get
>>>>> stuck on the "down" position (noticeably while using mostly J3) of
>>>>> the pick and place routine, not respecting any cycle time. On the
>>>>> other side, the most strange thing is that we don´t have any
>>>>> reports on the AdeptDesktop software, it continues to work with no
>>>>> alarms or warnings, even if the robot is standing still vibrating
>>>>> instead of keeping on moving (not even a position error or
>>>>> something similar!!).
>>>>>
>>>>> 3 - While in vibrating still condition, I applied some force to
>>>>> the robot flange, trying to dampen the vibrations on the system,
>>>>> and it did work, for some seconds the vibration goes away, and
>>>>> then resumes. I put something like a 8-10 Kg force on the
>>>>> J3-J4-J5-J6 assembly (on the robot flange), and the vibration
>>>>> decreases almost to disappear for a while. I don´t perceive any
>>>>> grainy or unfamiliar sound on the joint while the robot is in
>>>>> normal condition. I don´t have a brake release box, please
>>>>> indicate how to loose or free the axes in order to perform the
>>>>> tests you suggest.
>>>>>
>>>>> 5 - To isolate the problem, I wrote another simple program,
>>>>> cycling the first 3 different joints separately, and found out
>>>>> that is with no doubt J3 the axis which is causing the problem.
>>>>> Joint 3 got stuck after a couple of cycles. Please look at the
>>>>> videos attached.
>>>>>
>>>>> 4 - By saying that, and maybe you will agree with me, I feel that
>>>>> on one side maybe the vibrations are not caused by mechanical
>>>>> issues, since they would arise as soon as I turn on the servo
>>>>> condition. On the other side, if the joint is somehow stuck (but
>>>>> not strong enough) or the brakes are not working properly, that
>>>>> would lead soon into unstability condition, like the same effect
>>>>> on having a larger payload on the robot. I have some experience
>>>>> tuning and troubleshooting servos (yaskawa, parker, etc), and
>>>>> motion control systems (galil, yaskawa, parker), and when we have
>>>>> backlash, poor mechanics or tuning problems, the problem shows
>>>>> almost immediatly, and in a very similar way (maybe not so soon in
>>>>> tuning malfunctions, as they sometimes only require a disturbance
>>>>> to appear). The behavior of the system to me has something related
>>>>> to duty, or thermal issues to me, but of course this is something
>>>>> that is debatable, it is my perception. On the other side, as you
>>>>> mention, the servo condition is mantained even if it is vibrating,
>>>>> so the encoder seems to be working, it doesn´t have a runaway
>>>>> condition or similar. The robot system is grounded and customer
>>>>> demanded an UPS unit to protect the power supply (which we didn´t
>>>>> like at the beginning due to the inevitable presence of high
>>>>> frequency noise in this type of devices), since they have
>>>>> monstruous variations in tension in the plant.
>>>>>
>>>>> 5 - The servo unit starts with a surface temperature of 33 °C, and
>>>>> after a couple of minutes reaches 42 °C. By "hand" inspection, i
>>>>> feel that maybe the heat accumulated is excessive for the kind of
>>>>> duty we are applying, but could be anything, at this point i
>>>>> suspect of almost everything. On the other side, the sporadically
>>>>> message of D3 should say something regarding the heating and duty.
>>>>>
>>>>> 6 - Adept technician suggested me on the phone to exchange the J3
>>>>> servo drive unit on the new MB60R with the other damaged Mb60R
>>>>> axes(on the lower power axes they are stacked in 2, with J3 and J4
>>>>> sharing the same card), I opened up the unit, and found where the
>>>>> cards where, but I really didn´t want to proceed, since the unit
>>>>> is still in warranty, and don´t want to mess around without any
>>>>> proper instruction on how to open the MB60R (they didn´t have the
>>>>> manual either). I´m a mechanical engineer with good knowledge of
>>>>> robots (Fanuc, Motoman and Adept) and servos, but power
>>>>> electronics is still tabu soil to me, even if i suspect where the
>>>>> problem is, sure you understand the situation. On the other side,
>>>>> I was not responsible to sell the unit, it was Adept distributor
>>>>> in Argentina, which reached us to integrate the system, so my
>>>>> labour has been so far beyond the strict line of duty.
>>>>>
>>>>> 7 - The question that now arises is: in your technical opinion
>>>>> could it be that the improper or hazardous attempts (which I told
>>>>> you about on the previous email) with the connectors and god knows
>>>>> what else, could lead into this mess? The answer question is
>>>>> fundamental for warranty issues.
>>>>>
>>>>> I´m sorry to bother you with this questions, hope you can help us
>>>>> out on this. Thanks for everything,
>>>>>
>>>>> Regards
>>>>>
>>>>> Ottavio
>>>>>
>>>>>
>>>>> Juergen Bosse escribió:
>>>>>> Hi Ottavio,
>>>>>>
>>>>>> well that sounds like a proper nightmare to me. I think the only
>>>>>> thing you could have done to make it worse would have been to
>>>>>> crash the gripper into a customer fixture while troubleshooting
>>>>>> it. Repeatedly, preferrably.
>>>>>>
>>>>>> But let me tell you that you are one of very very few people on
>>>>>> this group who take the time to write up a very detailled
>>>>>> description of the system, the fault and incidental observations.
>>>>>> Well done! Hopefully, we'll be able to help you find the root
>>>>>> cause quickly.
>>>>>>
>>>>>>
>>>>>> Ok, so let's look at the issues one by one.
>>>>>>
>>>>>> 1) fire-miswire
>>>>>>
>>>>>> Basically, you can use ports 1.1 and 1.2 interchangeably. The
>>>>>> system doesn't even notice. That by itself would not have done it
>>>>>> any harm. Jamming the connector wrongly into the socket is not a
>>>>>> valid operation, though. In fact, what happens is that pins 1 and
>>>>>> 2 (24V), connect to pins 6 and 5 (data lines) and that will most
>>>>>> certainly smoke the MB60R's firewire circuitry. Any recovery you
>>>>>> try after that will be doomed. The RSC problems are caused by the
>>>>>> inability to even access the MB60R correctly.
>>>>>>
>>>>>> 2) New MB60R reports encoder errors first, but then works ok
>>>>>>
>>>>>> This behaviour is to be expected during the initialization, but
>>>>>> no more after that. Does it complain about E0-E6 every time you
>>>>>> power up or was it only the first time?
>>>>>>
>>>>>> 3) Vibration on Jt3
>>>>>>
>>>>>> Well I have experienced some mild Jt2/Jt3 vibration on the Viper
>>>>>> s850, but it was definately less than 0.1-0.2mm and only occured
>>>>>> in certain positions, where the position of the joints together
>>>>>> with the weight of our endeffector caused the resonant frequency
>>>>>> to be excited by small vibrations from the drive train. But this
>>>>>> is a purely mechanical issue and doesn't develop over time. It's
>>>>>> either there or not.
>>>>>>
>>>>>> So the behavior you see must be either thermal, electrical, or
>>>>>> maybe mechanical in a way you have a loose coupling or bad gear.
>>>>>> Since you can still servo with the vibration, I think we can rule
>>>>>> out a bad encoder signal or data transmission, as it is all
>>>>>> digital and would stop working altogether if there were any
>>>>>> issues with it. More likely, you have a bad motor (maybe broken
>>>>>> motor wire) or bad amplifier (you're keen on changing the MB60R
>>>>>> AGAIN?).
>>>>>>
>>>>>> Now back in the old days of PA4, we could have swapped individual
>>>>>> amps to isolate the problem... but not on the MB60R afaik.
>>>>>>
>>>>>> You can try to heat/cool the motor, the cables, the MB60R (within
>>>>>> reason, please!), shake cables, inspect the wiring inside the
>>>>>> robot, and you can use SPEC to diagnose motors individually. To
>>>>>> be honest, if I were on site to hunt down this bug, I would try
>>>>>> various random things, and learn from the observations. Try to
>>>>>> move the joint by hand with the brakes released manually. Try to
>>>>>> move the joint against the brake. It should not give way at all
>>>>>> (until you exert too much force for the brake) Try to measure the
>>>>>> ohm resistance of the motor windings of each motor. Between the
>>>>>> three phases, you should have a very similar reading for each
>>>>>> pair (1-2, 2-3, 3-1) per motor. Try to move the joint from hard
>>>>>> stop to hard stop and read the encoder. It should reproduce
>>>>>> within 0.01-0.02 degrees in the stops. Try this 5 times or so.
>>>>>>
>>>>>> Well - let us know what you find. Hopefully we can fix it quickly.
>>>>>>
>>>>>> Best regards and good luck - you'll need it.
>>>>>>
>>>>>> Juergen
>>>>>>
>>>>>>
>>>>>>
>>>>>> Ottavio Berbakow schrieb:
>>>>>>> Hello Everybody,
>>>>>>>
>>>>>>> Robot: Viper s650
>>>>>>> Controller: CX
>>>>>>> Servo Drive Unit: MB-60R
>>>>>>>
>>>>>>> I´m currently integrating a Viper s650 for a simple pick and
>>>>>>> place machine tending operation, and the process has been
>>>>>>> something like a nightmare. Maybe one month and a half ago,
>>>>>>> while comissioning the system, we had a fatal failure in the
>>>>>>> system, all six encoders were bad, and also had an RSC failure
>>>>>>> (initial message). The cause? Well, we left the robot (only the
>>>>>>> mechanical unit) in the laboratory on Friday night, in order to
>>>>>>> put it to work again on Monday morning, leaving the controller
>>>>>>> and electrical cabinet on application site. When we had the
>>>>>>> failure, we found that the firewire cables were plugged wrongly
>>>>>>> on the CX (like somebody removed from port 1.1 and put it on
>>>>>>> 1.2), but also finding the ports somehow damaged and deformed,
>>>>>>> almost like somebody tried to plug it in the wrong way and then
>>>>>>> powered on the system. We found also that one of the firewire
>>>>>>> ports on the MB-60R unit was damaged. I really don´t know if
>>>>>>> this type of "sabotage" could produce this type of damage, but
>>>>>>> the thing is that the system was working perfectly when we left
>>>>>>> it. Judge by yourselves.
>>>>>>>
>>>>>>> First we tried to fix the RSC problem by using the rsc_set, and
>>>>>>> RSC_RSTR restore programs, with poor results, after that, we
>>>>>>> tried to use the original RSC file to commit to the robot,
>>>>>>> without any results. After that, Adept sent us a new RSC card to
>>>>>>> change the currently installed, and the result was the same. On
>>>>>>> the RSC management programs, we had always that the system could
>>>>>>> not verify the encoders, hardware status code: 22. We could not
>>>>>>> commit any data into the RSC, and also we had encoder failure
>>>>>>> -1025 on the Adept Desktop screen.
>>>>>>>
>>>>>>> We checked the encoder power supply system, and everything was
>>>>>>> ok (using also the Denso Manual). Just to make the story short,
>>>>>>> we tried every possible way to troubleshoot the system, but the
>>>>>>> result were always E0 up to E6, RC on our MB-60R unit. On the
>>>>>>> other side, AS explained before, this unit had also one of the
>>>>>>> firewire (1.1) ports damaged, since we could not even find the
>>>>>>> network when we wrote SRV.N on the terminal. In order to find
>>>>>>> the network we needed to plug the cable to the 1.2 connector.
>>>>>>> Anyway, finally, suspecting that maybe the MB60R unit was the
>>>>>>> problem (since we had normal readings on the voltages of the
>>>>>>> encoder power supply, and also the voltage supply to the RSC),
>>>>>>> Adept sent us a new MB60R unit. When we installed, it immediatly
>>>>>>> recognized the RSC and hardware settings, and proceed to perform
>>>>>>> full data commit into the robot, by using our original RSC file.
>>>>>>> We finally made to load all the configurations, and even if we
>>>>>>> received some strange messages warning that some data could not
>>>>>>> still be committed to robot, the data finally got into the
>>>>>>> system. We checked the current values and parameters, and
>>>>>>> eveything seems to be correct. The system promptly responded
>>>>>>> with a OK message, and then, after a calibration, we had our ON
>>>>>>> status. When we power up the unit, in a very short burst, a
>>>>>>> message of E0 appears on the MB-60R unit, and then disappears,
>>>>>>> leaving place to the OK message.
>>>>>>>
>>>>>>> The robot is capable of moving without any problem, running
>>>>>>> programs and all, but after a while we are experiencing a heavy
>>>>>>> vibration on the servo motors, seeming almost like a tuning
>>>>>>> issue. We removed the gripper in order to exclude overweight or
>>>>>>> the effect of inertia, but it didn´t change much, after a while
>>>>>>> the system starts to vibrate heavily, specially on axis N°3. If
>>>>>>> we issue a power down on the servos, and then power on again,
>>>>>>> the systems behaves normally, and after a while vibration starts
>>>>>>> again. Is there a way we can troubleshoot this vibration and
>>>>>>> noise? While in this state, the system usually does not issue an
>>>>>>> alarm (we had only once a D3 alarm, a duty cycle alarm for
>>>>>>> joint3, on a very low speed, maybe due to heavy vibration), and
>>>>>>> we can run programs, and also jog the robot with the vibration
>>>>>>> on. Is there a way that maybe some servo parameters can be
>>>>>>> adjusted to eliminate this problem?? Do we need to perform any
>>>>>>> more calibrations beside the one we did on the system restore??
>>>>>>> Could it be the surface in which we mounted the system, maybe
>>>>>>> resonating at some point with the robot structure? If anyone has
>>>>>>> experienced something like this before, please advice,
>>>>>>>
>>>>>>> Regards
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>

--
_____________________________________________________________________

Juergen Bosse
Robo-Technology GmbH Sitz der Gesellschaft: Puchheim
Benzstrasse 12 Amtsgericht München HRB 140072
82178 Puchheim Geschäftsf.: Jürgen Bosse, Jörn Bosse
Germany

Tel: +49-89-8006390 http://www.robo-technology.de
Fax: +49-89-807917 juergen.bosse@robo-technology.de
Mob: +49-171-5178540
_____________________________________________________________________
juergen.bosse@robo-technology.de
 
Posts: 132
Joined: Tue Jul 09, 2002 5:00 pm


Return to Yahoo Software Group Archive

Who is online

Users browsing this forum: No registered users and 3 guests