Mitsubishi RV-6SDL Robot

Hi,

I am currently looking to buy a used RV-E2 with a broken CR-E116 controller.
@dm17ry Do you have any information an that controller? I found manuals for the robot, but nothing about the controllers.

Thanks,
Jonas

Generally speaking your chances of getting usefull information for and eventually actually repairing the controller are _very_ slim.
My controller has 3 identical IGBT modules (with driving electronics on board) and one was broken. I swapped one of the working modules in for the broken one and the controller would then no longer accept the modules even if I swapped them back into the original places.
There is likely some sort of diagnostic/configuration software required to service these controllers. It's all extremely proprietary and secretive.

The only thing of use from the original controller turned out to be some of the connectors, the safety relay assembly and the information extracted from the eeprom from which dmitry could then derive the motor settings to get the motors running using regular mitsubishi motor drives.

jst wrote:

@dm17ry Do you have any information an that controller?

no, i don't... @aciera managed to read the servo drive firmware back then, it looks like a couple of MDS-DM-V3 3-axis drives on a single PCB.
there can be some subtle differences from a normal MDS-D-V though. i played with a MDS-C1-V2-0505 with "ROBOT-D6c" firmware. it had a bunch of extra parameters. and usually the control protocol provides only the target position, but this drive also required torque limit plus feedback torque tolerance (?) (kinda dynamic collision detection i guess).
don't know anything about the NC controller inside.

My controller has 3 identical IGBT modules (with driving electronics on board) and one was broken.

From the pictures I found of the CR-E116 controller, the IGBT modules look very similar:
i.ebayimg.com/images/g/UTIAAOSwIgRkKHWq/s-l1600.jpg
I was hoping to reuse the drives of the old controller, but it looks like the encoder feedback is integrated on the main board.
Your controller had a separate doughter board for the encoder feedback (the long one with the connectors on top left of the IGBT modules)?

From the manual it looks like they recommend an MR-H drive for additional external axis.

I will look at the robot in two weeks and report back then.

dm17ry wrote:

jst post=295500 userid=37579@dm17ry Do you have any information an that controller?
no, i don't... @aciera managed to read the servo drive firmware back then, it looks like a couple of MDS-DM-V3 3-axis drives on a single PCB.
there can be some subtle differences from a normal MDS-D-V though. i played with a MDS-C1-V2-0505 with "ROBOT-D6c" firmware. it had a bunch of extra parameters. and usually the control protocol provides only the target position, but this drive also required torque limit plus feedback torque tolerance (?) (kinda dynamic collision detection i guess).
don't know anything about the NC controller inside.
 

Its possible that they are doing some trickery for the robot drives compared to the normal ones. Like you guessed for collision and overload (meaning to high workpiece weight) detection, but also for features like compliance mode:


At work i program yaskawa welding robots and the goes in a lot to make the precise movements possible (e.g. compensation for the moving mass of the robot arm and tool).

Your controller had a separate doughter board for the encoder feedback (the long one with the connectors on top left of the IGBT modules)?

As I recall, the encoders were connected to the main board. The daughter board you are referring to had a couple dozen capacitors on it so it must have been (at least partly) used for the power stage. Lots of processors/FPGA chips on the other side of it though. The driver boards also had processors on board. There is likely extensive serial inter-processor communication/ startup configuration going on so it its highly unlikely you would be able to reuse the drives from the controller without _very_ extensive reverse engineering.
Also, as you and dmitry already noted there seems to be very close integration of the drivers into the controller to achieve features like 'compliance'.