Help with Yaskawa SGDM-04ADA-V ac servo drives
I have some IAI linear actuators type ISDL, that I want to make an 800x600 xy table. These actuators have 200V 400W 8 pole 3000rpm AC servo motors integrated directly onto the ball screw spindle. I would like to retain them if at all possible, but suitable IAI controllers are almost impossible to get hold of. Shaft rotary position is resolved to 17 bits by a Tamagawa absolute (1 revolution) encoder. Position data is transmitted serially at 2.5Mbaud by a two wire differential pair.
I can get a hold of some Yaskawa SGDM-04ADA-V AC servo drives at a quite reasonable price, and the voltage and power levels match. The drawback with these is that they communicate directly with the motor encoder electronics on startup for motor type data, and the drive will give a fault if the attached motor does not return a valid Yaskawa motor code.
To make it all work I figured that I could knock up an AVR or PIC interface to act as an interpreter between the Yaskawa SGDM and the IAI encoder. This would convert the serial position data to the appropriate format for the Yaskawa drive and also respond properly with the appropriate motor data when interogated at start up.
I've looked in all of the Yaskawa literature that I can find on line and cannot find any of the technical details of this electronic intercourse between the Ysakawa drives and the Yaskawa motors. So I am a bit stumped there before I start.
Secondly, I can find no data on the rotor alignment at the encoder zero point. This is critical for AC servo drives as it is the very cornerstone of proper phase synchronisation and actual rotor position.
So I have two questions for the learned gentlemen of the forum
1 - Does anybody have access to the technical details of the yaskawa SGDM-04ADA-V encoder interface and the automatic motor identification process that is performed on start-up?
2 - Am I dreaming the impossible dream? Is it just too darn difficult to mix and match AC servo drives and motors from different manufacturers? I am seriously tempted to take an axe to the existing integrated AC servo motor and replacing with an external step or brushed servo motor. These actuators are so beautiffuly made and dust tight, that I would hate to tamper with their envelope integrity. Is there a better way that I haven't thought off?
This is my first serious post. Feel free to tell me if I've posted this in the wong place, broken some ettiquite (I'm not even sure if I can spell the word), or just plain rambled on for too long.
Start the servo hacking topic
Dear All,
You are the first community I've ever faced, gives the detailed information about encoders and servopacks. I have too many questions about this. Please lets start the topic again.
My questions are below. I'll be appreciate if you share you comments
1. dm1try: I have a communication link wit setup161E software of Mitsubishi and you say that we can hack the software to work with any motors. Which software should we change. Is it just changing the parameters of setup161E or
reprogramme the RENESAS SH7065 or SH7034 IC via the flash programmer. It'll be very helpful. If you explain which programme should we hack and how like a begineer style.
2. dm1try: There is a SH7065F.sub and 7065.inf files in SETUP161E folder. What are they? These files are the default flash programme of servomotor I think? Actually I bought a renesas programmer (Named. E8A) with a flash development programme to reprogramme the device. Up to time I can not do this. Do you have any suggestions, any explanations about these files.
3. dm1try: Can we get the software on the MRJ2SA or MRJ2SB microprocessor or reprogramme it.
4. We have a machine that has a custom MRJ2SB-60A servomotor have a capability of using 18 bit ( not 17 bit) encoder. We bought fresh MRJ2SB from mitsubishi and change all of its parameters plus the invisible ones. Everything was OK. But we can not pass the encoder communication error. When I go in detail with SETUP161E I see that the custom one shows the encoder resolution as 18 bits (262144) and the fresh servo shows 17 bit(131072). My best quess is that the motor used in our system has 18 bit motor and mitsubishi makes a custom MRJ2SB supports 18 bit encoders.
So I think I should get the embedded code in old servo to the new servo. Is this possible do you have any suggestions about this.
5. Bobs bots: Is your serial datas are only valid for MRJ2S series or can we think that it is a general protocol used by all mitsubishi and plus yaskawa servos. Do you have any new investigations.
6. I looked for a standart RS485-RS232 converter supports 2.5 Megabaud and Embedded Ethernet, Serial to Ethernet have these devices so I think we do not have to design a fast rs485-rs232 converter.
If we start the topic again I'll be glad. I have still too many technical information and also questions about this.
best regards
baudrate calculation for communicating with servo
Dear Bobs bots,
Can you explain your hardware for investigating the mitsubishi encoder interface. How did you reach 2.5Mega baud. Did you use a logic analiser ? I think you did not built a PIC or ATMEL embedded system. It is your suggestion I guess. Please see below.
I selected a fast PIC PIC18F24K22 to built up a virtual encoder like your suggestion. There is a baudrate calculation formula in PIC technical documantation like below;
Desired Baud Rate = FOSC / (64([SPBRG + 1])
So
SPBRG = (FOSC / Desired Baud Rate / 64) - 1
When
FOSC : 16000000 Hz
Desired Baud Rate = 2.5Megabaud = 2500000
SPBRG = (16000000/2500000/64) - 1 = -0.9 :)
If we use the PLL and make the PIC run at its fastest speed
FOSC : 64MHz (Fastest speed with PLL)
Desired Baud Rate = 2.5Megabaud = 2500000
SPBRG = (64000000/2500000/64) - 1 = -0.6 :)
As you see a fast PIC can not handle this baudrate !
We have to use at least a 300 MHz - 500 MHz DSP for this purpose. And from this point of view using a microcontroller is a wrong choice for this purpose. Using a CPLD or FPGA would be necessarry.
You may know the encoder communication is handled via an ASIC in mitsubishi servo (Like dimirty says) and I'm pretty sure that why mitsubishi use an ASIC for encoder communication is "2.5Megabaud" request
Bobs I think you are sure that it is 2.5Megabaud ?
Best regards
One correction and new questions
Hi Bobs
Really thanks for your explanations.
I realized that I had a mistake about the baudrate calculation in PIC. There is a same structure you can decrease the prescaler to 4 so the formula is
SPBRG = (FOSC/Desired Baud Rate /4) - 1
When
FOSC = 25MHZ
Desired Baudrate = 2.5Megabaud
SPBRG = (25000000/2500000/4) - 1 = 1.5 This is OK
I have questions again
1. I want to summarize what I understood about your system. You made an encoder reader via Jedmicro and also make a motor driver software on it. You read the encoder and drive the motor via this encoder information. Why did you need such a driver system. I mean why did you drive the motor. Is it necessary for reading encoder bits? Your main purpose was not building a "virtual encoder". Your main purpose was making a motor driver.
I know it sounds like a stupid question but I couldn't summarize my understandings with my limited english :)
2. I think JEDmicro is an embedded PC It has UARTs, monitor, etc. And you compile your code like you are compiling in Visual C++ in Windows. I mean you are not using an "emulator + microcontroller" structure
You confused me. If you have a ready to go system like jedmicro why do you suggest an ATMEGA128. Does Jedmicro not have 2 UARTs or you want to give a way for real system without a system like jedmicro
3.Which mitsubishi servo pins did you use to drive it ? Can you give a little detail about it.
I hope I don't bother you.
with my best regards,
2 Attachment(s)
Return to SGDM yaskawa servos
Dear All,
I'm ok with mitsubishi servos now. Really thanks to dimitry. He solved all of my mitsubishi problems
Now I returned to investigate yaskawa servos (SGDM series). I want to share my works up to now.
1. I started to dump the interface between SGDM and the encoder (motor is :SGMSH)
2. The interface is Half duplex RS485 with data enable strobe. The interface IC is SN75LBC176. When servo start a new transmission it makes Data enable pin High and send the data after the transmission it makes data enable low to receive the replies from encoder.(A standart half duplex RS485 structure)
3. "Bobs bots" said that the MRJ2S interface baudrate is 2.5Megabaud. So I started to dump the SGDM with this baudrate. The Datas I got were stable but When I sent the dumped datas to the encoder the encoder didn't response.
3. So I looked at the signals with an oscilloscope. I saw that the baudrate was really high. It is 8MHz (One bit is 125nsn) Please see the attached file for the oscilloscope screenshot.
4. I looked the oscilloscope screenshot in deep and compared with standart RS232 serial datas but there is something different in the signals.
If it is a standart serial datas The transmission should have
- One start bit (0: for UART side)
- 8 data bits (positive logic for UART side)
- 1 or 1.5 or 2 stop bits (1: for UART side)
I attached a very good explanation of standart serial port datas. You may compare two screenshots like I do. If you looked at the screenshots bit by bit.( With "start bit+8 bit datas+stop bit" structure as the reference) Actualy I tried to mount all of the serial signals like
- One stop bit, 1.5 stop bits, 2 stop bits didn't deal with the osc. screen shots
- It was look like a 16 bit or 32 bit interface (Not a 8 bit interface) But 16 bit 32 bit reference didn't deal with the osc. screen shots again
You will see that sometimes there is an extra zero or one after stop bits or start bits.
5. Some yaskawa documentations mention about "Manchester encoding and decoding techniques" My best guess that these datas are encoded with a modulation technique !!! I'm not sure so I'll be appreciate if you investigate the attached pictures detail. May be I miss something
6. End of explanation :)
Please note that white picture is the REAL SGDM datas and black picture is a generic serial port data for just a comparision purpose. (Not a real data an internet picture)
best regards,