517,959 active members
2,736 visitors online
Register for free
Login
IndustryArena Forum > CNC Electronics > Servo Motors / Drives > Help with Yaskawa SGDM-04ADA-V ac servo drives
Page 1 of 2 12
Results 1 to 20 of 32
  1. #1
    Registered
    Join Date
    Nov 2006
    Posts
    6

    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.

  2. #2
    Registered
    Join Date
    Feb 2007
    Posts
    77
    I have not found any source for the Sigma II data stream format either. You could do some sleuthing and get to the bottom of the Yaskawa serial encoder signal, but you would need a Yaskawa motor to do it. And a lot of time... It's probably not worth it.

    For your second point, it is a rather difficult challenge. And impossible at times. Sticking with "generic" servos instead of proprietary ones is your best bet. Advance Motion Control makes a drive to push just about any non-proprietary servo drive on the planet. "Old school" AC servos (and DC for that matter) had spec sheets that gave enough information to correctly match a drive to them. Kev for volts per 1000 RPM, rated current, peak current, etc..

    But the proprietary drive/motor combos are best matched to each other. It's all driven by marketing and to simplify their support infrastructure. You can't blame them. Sell a drive and be assured to also sell a motor. And then that makes supporting it that much easier. It's also not bad for the customer either as he has a known combination that works together. It's just bad for us gear heads that are tying to make the best use of stuff that we have lying around.

    Steve

  3. #3
    Registered
    Join Date
    Jun 2010
    Posts
    0

    IAI linear actuators

    Hi there,

    Think I may be in the same boat...
    i just bought a pair of IAI linear actuators from good ol' ebay; and i'm now trying to figure out how to turn it into my dream g-code munching cnc router.

    Did you have any luck finding a way to drive or control the IAI linear actuators without throwing away the inbuilt servo motors they came with?

    Any help would be much appreciated.

    Cheers,
    Firstyear

  4. #4
    Registered
    Join Date
    Nov 2006
    Posts
    6
    Reply to firstyear

    No, not much joy up to now. There seems to be a lotof technician level "hands-on" knowledge out there about particular ac servo drive/motor combinations, but little in the way of actual in depth technical understanding of the actual encoder interface details. Nobody that I have spoken to (including local Yaskawa in house technician) could even tell me how many poles their motors were. There are probably good commercial and support reasons why manufacturers nowadays seem to keep these details secret.

    Some of the IAI actuators use simple A,B,Z quadrature incremental encoders, but i don't understand how they get their initial alignment for ac power sync with rotor position. Maybe they use sensorless controll untill they pick up the first Z pulse.

    The IAI actuators that I have are ISD- L type which us a Tamagawa 17 bit serial encoder. It can even be programmed to hold data, which can be used for motor identification or parameter steeing when interrogated by the drive.

    I suspect that the later Yaskawa servos that use serial encoders are a bit similar to this. So if your encoder does not talk nicely to the drive it will error out on you, even if the communication hardware and protocol match.

    I have resigned myself to either:
    A - make my own AC servo drive. I have been able to characterise the IAI servo motor. 400W, 8 Pole, Just need to figure out the orientation of the encoder zero count with the magnetic pole positions (easy eh?). Then there is the small mater of making a servo drive controller!

    B - Smash the motor and encoder off the ball screw shaft and mount a stepper or servo onto it with a matching drive. Would seem to be a shame, but may turn out to be the simplest way.

    Hope you have better luck than I in finding out info. In about a month or so I will be doing more testing on my IAI's to establish encoder zero position. Then it'll be plain sailling. I will post results for you then on what I find.

  5. #5
    Registered
    Join Date
    Jun 2010
    Posts
    0
    Hi Geebow,
    Thanks for your great response.

    I've been searching high and low for a way to drive this contraption short of replacing the servo's.
    I was lucky? to pick up an X-SEL controller as part of the deal, it's arriving tomorrow so I'll look into it then.
    From what I can tell so far, the servo motor connects to both an independent driver and an independent servo cpu (which the encoder connects to) within the X-SEL controller.. the servo cpu then connects to an independent controller cpu (breakout board).

    so..

    1. motor > driver > controller cpu
    2. motor encoder > servo cpu > controller cpu
    3. controller cpu > home/office PC

    PLAN A -
    My new plan is to miraculously replace the controller cpu with a new cnc breakout board and cross my fingers and hope it will understand G-code.

    OTHER PLAN A - Hope that geebow can make sense of the IAI info below..

    http://www.intelligentactuator.com/p...ning_intro.pdf


    Encoder Operation (SEL-G)

    • X-SEL - 17 bit incremental encoder, 14 bit control resolution, 16384 pulses/rev

    • “3-phase, Optical Incremental Encoder” allows for relative positioning (loses
    position when power is cut, cable is damaged; good because home value is based
    off of encoder).

    • Z-phase is based on aligning motor coils with Z-pulses.

    • A/B-phase sensors are used for position feedback. Controller must know where
    the actuator is while moving in order to control drivers.

    • After over current limit is sensed, the motor rotates until the z-pulse is sensed to
    “zero” position (0.000 mm).

    • Motion then occurs using the A/B pulses, feedback, and servo drivers.

    • Quadrature (see diagram) allows for an effective resolution 4 times that of the encoder count (384 or 768 pulses per revolution).

    A/B – phase
    (384 or 768)

    Z – phase
    (1-4 notches)

    Example encoder assembly: IS unit w/ 16 pitch ballscrew

    “Quadrature”:
    four distinct
    states (90° out
    of phase).
    A B
    1 0 0
    2 0 1
    3 1 0
    4 1 1

    Geebow if you have any ideas that would be great!
    By the way do you think my 1st idea may work? or do you know of an alternative servo drive that can take G-CODE commands?
    Cheers

  6. #6
    Registered
    Join Date
    Jun 2010
    Posts
    0
    More info...

    (X-SEL-Q)

    • X-SEL Q - 15-bit rotation data backup absolute encoder
    Both have a control resolution of 14 bits (16384 pulses)

    *this is the one that came with my IAI linear actuators

  7. #7
    Registered
    Join Date
    Dec 2006
    Posts
    29

    Serial encoders protocol

    Hi Guys.
    This thread is a bit stale , but.
    I also have some IA actuators (off Ebay ), but mine have the standard quadrature encoders on. (They are really neat bits of gear!)
    I've got them working off a ATMEGA2560, with 24V I can get full torque but speed is limited, shortly to go to 60V drive.

    Anyway I have some mitsubishi HC-KFS23 motors (200W) and a pair of MR-J2S-70B drives (700w) and you can plug them together, and you just get the "1A" error code (wrong_motor_attached_dummy).
    However it is also a 2.5Mbaud 17 bit serial encoder,"OBA17-051", (the same or similar to yours).
    And when the two are connected they bounce data back and forth that changes as you turn the shaft.
    Any way.... if you hook up a logic analyser you can see what's going on.

    When first powered up an ascii character <146> is sent and the encoder replies with <146> <1> <65> <20> <0> <0><0><0>

    This appears to be some version number thingy.
    Next the drive repeatdly sends <162> and gets a reply like
    <162> <49> <8> <18> <15> <253> <127><192> <136>

    Next you program your AVR UART to run at 2500kbaud , (quite a challenge!)
    get your micro to send <162> and record the 9 byte reply while turning the shaft in a controlled fashion , squirt the numbers out another serial port with commas between them, log the serial sessin as a CSV file and read them with Excel.
    Eventually you figure out enough of the protocol to use the encoders. The 9 byte response looks like:
    <cmd> <type> <ph_l> <ph_m> <ph_hi> <rot_l> <rot_m> <rot_h> <crc>
    Where
    <cmd> is the command echoed back
    <type> is the motor type (I'm guessing , I don't have any more motors to play with)
    <ph_h> <ph_m> <ph_l> are the three bytes that make up the 17 bits of the phase angle (mechanical shaft angle) of the encoder, note that ph_hi has four leading zero bits , and ph_l has 2 trailing zero bits
    <rot_h> <rot_m> <rot_l> Are three bytes that make up the total number of full rotations of the shaft , (I/m not sure about rot_h, as I haven't turned the shaft far enough yet!!!)
    <crc> is a cyclic redundancy check, but I can't match it using any CRC checkers I have, the best guess is that it uses a standard CRC-8 polynomial of &hEA (as that's the one used in the Mitsubishi encoder patents).

    Anyway my basic advice is to snoop on the data line, then replicate the command bytes , possibly <162> works for you too.

    Cheers, BobT :cheers:

  8. #8
    bobs bots
    do you have a j2s setup software? there's a file in there called mottyp.dat. for kfs23 it gives the following id:

    12FF2300 HC-KFS23

    i think it should be there in your snooped data... also, if you're seriously into hacking those drives, have a look at parj2s*.dat. there's a lot of parameters to fool with. for example, No.157...181 should allow the amplifier to work with any motor, i believe. at least, i successfully reprogrammed 70b-U005 into j2s-70b and U006 to work with kfs73, kfs46 and kfs410 motors. maybe just a change in "amp capacity" param will turn off this 1A error

  9. #9
    Registered
    Join Date
    Dec 2006
    Posts
    29
    Hi Dm1try,
    Thanks for your information.
    I picked up 8 of the KFS23 with ballscrews and couplings off Ebay about a year ago. The deal included two of the MR-J2S-70B even though they were known to be incompatible.
    Last week was the first time I tried to power up the drives, just to see how the encoder worked.
    I intended to drive the motors with a drive of my own manufacture.

    I don't have the J2S setup software , (or even any cabling to communicate with the drive) , however your information has encouraged me to consider modifying the drive in maybe a month or so.

    I looked through all the responses from this motor/encoder and nothing seems to match any part of "12FF2300" . it looks like 4 hexadecimal bytes
    maybe the "12" is 120volts or "23" is the motor type.

    Its difficult to find much info, I would appreciate any links to information about these drives/motors.

    Cheers , BobT

  10. #10
    Member
    Join Date
    Jan 2005
    Posts
    10913
    geebow

    Your drives will take step/dir so you can get them going really easy, down load the user manual number SIEPS80000015 & this one also TOE-S800-34 You get these down loads from the Yaskawa site Yaskawa America, Inc., Drives & Motion Division

    This has all the information you need to get them going
    Mactec54

  11. #11
    Registered
    Join Date
    Nov 2011
    Posts
    0

    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

  12. #12
    Quote Originally Posted by bluenone View Post
    1. dm1try: you say that we can hack the software to work with any motors. Which software should we change. Is it just changing the parameters
    yes, it's a Pr.183 called "test mode 2". not sure if it's safe to use long term, but no problem so far

    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.
    they are used by the shflash.exe, which comes with setup161e. it's just a sh7065f flash memory map and a bootloader


    3. dm1try: Can we get the software on the MRJ2SA or MRJ2SB microprocessor or reprogramme it.
    shflash.exe out of setup161e package is enough

    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.
    what you mean with MRJ2SB-60A? MR-J2S-60B or MR-J2S-60A? you want to replace it with a fresh drive with the same letter? yes, i think it's possible. can you run a sw on a windows pc with old "custom" drive connected to its serial port? i can have a look to get an idea what's custom about it. pm me with your email please

    about the custom encoder. BobT said:
    When first powered up an ascii character <146> is sent and the encoder replies with <146> <1> <65> <20> <0> <0><0><0>
    <65> is the encoder type for j2 super series motors. so the drive just knows that it is 17bit. it also knows 5 other types. maybe they just added another encoder id in your drive...

  13. #13
    Registered
    Join Date
    Dec 2006
    Posts
    29
    Hi Bluenone,
    I haven't had any time or opportunity to progress this any further.

    The encoder appears to use an ASIC rather than a FPGA , this means Mitsubishi would have invested a fair amount of money in the design, and they have a patent, so more than likely the same design and protocols are used on all their encoders.

    Certainly the way the bytes are set up implies upto 20bit resolution is possible in the same format . The encoder position is represented as a fraction , so there should be no need for Mitsubishi to change the firmware , the servo control loop works the same whether or not the least significant bits have data or are zeros. The higher resolution allows better speed estimation , and the user accessible parameters allow you to change the parameters to take advantage of this improvement.
    The encoder also has some configuration bytes , which are used by the controller to determine the voltage/frequency/poles, probably this is just a (hexadecimal) part number

    I don't have any experience with the controller or programming of it, However If I did design it , there would be some tables in a configuration file. (Maybe the inf file?) The error you are seeing probably indicates the table is missing an entry that matches the encoder.
    It is possible, but extremely unlikely that your firmware actually has some custom code in it, nobody wants to write and keep track of hundreds of code variants, you just want the one piece of code, which changes functionality according to what it finds in a configuration file, sure you will do upgrades, but the basic functionality is still there
    Cheers , BobT

  14. #14
    Quote Originally Posted by bobs bots View Post
    The encoder also has some configuration bytes , which are used by the controller to determine the voltage/frequency/poles, probably this is just a (hexadecimal) part number
    the only specific thing about the encoder thru the same motor series is the motor ID. it's an opaque integer which indexes a tabe. all the motor constants are kept in that table in the firmware. and they tune some constants and add new motors between firmware releases

    It is possible, but extremely unlikely that your firmware actually has some custom code in it
    well, looks like they do have a few code variants. maybe just some conditions in the same source code base. at least i've seen a full closed-loop firmware version which differs from the standard one.

  15. #15
    Registered
    Join Date
    Nov 2011
    Posts
    0

    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

  16. #16
    Registered
    Join Date
    Dec 2006
    Posts
    29
    Hi Bluenone.
    I Initially used a small USB logic analyser to look at the signals, it has a neat feature whereby it can emulate a UART , I basically connected the wires , then fiddled with sample rate until I got something that looked like a serial string , I then downloaded the data as a CSV and looked at it some more in Excel. Once I had it vaguely sorted, I initially wrote some simple code in the micro that took a snapshot of 2.5MBd data and spat it out at 19.2kBd, you then turn the encoder and figure out whats going on.

    Most Uart's run with an internal frequency of 16 x baudrate, so there are 16 clocks per bit. The uart samples the input at clock ticks 7,8,9 so a one or zero is decided by simple majority.
    Your PIC documentation implies you have a factor of 64 division (I'm not familiar with this chip)
    My hardware uses a general purpose micro controller board by JEDmicro , with a Atmel ATMEGA2560 , because I had a spare one lying around.
    You basically need a micro with 2 uarts (and a triple output PWM to drive the motor) so a ATMega128 would have worked too. An Xmega would have been ideal, but they weren't available at the time.
    So to get to 2.5MBd , I needed to set a special bit inside the UART to make it "high speed" , this changes the clock divider to 8 , and turns off the triple bit checking. I then swapped the crystal for 20.0Mhz , and set the baudrate divider register to 0 , i.e prescale=1, divider=1, so 20/8=2.5.
    The set up lines of code are
    ---------------snip -----------------
    '------------------ set up com4 = hardware uart3 Mitsubishi Encoder 2.5Mbd , buffered,

    Config Com4 = 2500000 , Synchrone = 0 , Parity = None , Stopbits = 1 , Databits = 8 , Clockpol = 0

    Set Ucsr3a.1 ' set ucsr3a.1 double speed
    Config Serialin3 = Buffered , Size = 30 ' its actually com4:

    Open "COM4:" For Binary As #4


    Enable Interrupts


    ---------------snip -----------------

    As an alternative to a UART you could nand assemble a bit of tightly coupled code that used the SPI interface, you could even bit bang with something like shift_in_a_bit,NOP, NOP,NOP,shift_in_a_bit,NOP, NOP,NOP,shift_in_a_bit ...
    Its only 8bytes, so you can fit it into the available register space of most micros. (Or just push the IOport onto the stack 80times and sort it out later)

    I've attached the ISR routine where the Mitsubishi data is read and converted
    (I could have written this bit is assembler, but it worked in compiled basic so I left it alone, I use "BASCOM")
    (a) I transmit a byte : Udr3 = 162
    (b) I read 8 bytes in a loop into an array with this : Enc_string_bytes(mit_char_count) = Udr3
    (c) I process that data
    There is not enough time to check for UART Tx or Rx buffer status or frame errors or anything else, so I assume if the second byte is a "49" the rest must be good.

    The encoder read routine can also read a simple incremental encoder I made up in a PLD (Before I discovered the LS7366!)

    Servo loop:
    My main interrupt routine runs at 1kHz , which is basically my loop update speed. I drive the motor in what most people call "voltage vector control", I.e.
    I just make 3 sinusoidal PWM waveforms , where amplitude is proportional to speed. ( I also boost it during acceleration) I also check the phase angle between my commanded speed and what the encoder says it is, this difference is the "electrical angle", it is zero at no torque and 90 degrees at maximum torque. If the electrical angle gets to 80degrees then I simply skip cycles in the PWM update, this allows the shaft to catch up. This is surprisingly simple yet nearly bulletproof.

    Cheers, bobT
    Attached Files Attached Files

  17. #17
    Registered
    Join Date
    Nov 2011
    Posts
    0

    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,

  18. #18
    Registered
    Join Date
    Dec 2006
    Posts
    29
    Hi Bluenone.
    You have almost got the baudrate calculation correct, but you can't enter "1.5" into the divider register. It must be an integer.
    so your options are 10MHz:SPBRG=0 20MHz:SPBRG=1 30MHz:SPBRG=2 40MHz:SPBRG=3

    As to your queries:
    1) The main purpose was to develop a generic servo motor driver that could use surplus servo motors . To this end it was necessary to be able to read any encoder. Particularly the Mitsubishi servos are quite cheap on the used market, and they have a lot of power for their size. So, no, it was not an academic exercise in "building" a "virtual encoder interface".

    2) The JED micro JED AVR256 Single Board Computer using the ATmega2560 CPU was something I originally used to make some machine controllers, it has the big advantage that you know it will work once you turn it on! , But they are expensive at $600 , although this price would have been acceptable in the end product, the real issue was the labor cost involved in wiring up all the other interfaces to the JED board. So I made my own board after using the JED board for development. I then upgraded the first 6 machines we built, which left me with 6 of these JED boards.

    I'm using BASCOM from MCS electronics Home - MCS Electronics for code writing , it has a very usable IDE , and it is a true compiler, and it allows you to seamlessly blend in assembler lines if required, it also easily supports overlaying of variables, lookup tables and working with individual bits, all very useful for bit-bashing, it does have an emulator , but I rarely use this (except for comparing speed/size of different ways of performing maths functions . I am a hardware designer so basic is much easier for me to work with.

    All of the arithmetic is done as fixed point or fractional integer.

    3) The Mega2560 is a bit of an overkill , whereas the mega128 is much cheaper and readily available on development boards. the Olimex AVR-MT-128 is a good example it has LCD and 5 buttons too. The other issue is that the encoder operation is very demanding of the CPU, so it can't also be used for other general purpose activities. And finally the M2560 is a 100pin fine pitch IC, so a bit finicky for soldering.

    4) The motor I experimented with was a HC-KF S238
    The connector on the rear of the encoder is a 9 pin square connector
    I think the connector numbers have been posted before, anyway these are from my record book:
    Pin 1,2 are MR and MRR this is recieve data into encoder
    Pin 4,5 are MD and MDR this is TX data out of encoder
    Pin 3 is battery (I didnt use)
    pin 5 is +5v power to encoder
    pin 8 is logic ground.
    MR/MRR and MD/MDR are differential data lines.
    You then connect some of these wires to your micro-controller TTL serial port:
    Micro TTL serial out to MR pin
    Micro TTL serial in to MDR pin
    connect about 1.5v to MRR as a reference ( I use 2k/4k resistors from 5v)
    connect +5 and LG to +5 and gnd on the micro

    The motor connections are 1=U , 2=V , 3=W, 4=Ground/chassis 5,6 are the 24v brake release connections.
    U V W are the motor phases, approx 7.3ohm per phase, nominal values are 118vat 3000rpm and 1.1A.
    I used a hard-switched MOSFET bridge operating off about 70v (12v initially while I was experimenting) I think I used FAN73835's to drive the MOSFET's
    For hobby/experimental purposes you could use a L6205 combo bridge to drive the motor from a 48V supply , this limits speed to ~ 1200RPM.

    Hope this helps, Cheers, BobT

  19. #19
    Registered
    Join Date
    Nov 2011
    Posts
    0

    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,
    Attached Thumbnails Attached Thumbnails Yaskawa_SGDM_Data_sample.JPG   General_RS232_data_sample.JPG  

  20. #20
    Registered
    Join Date
    Dec 2006
    Posts
    29
    Hi Bluenone.
    Some excellent sleuthing on your part.
    The data does look to be manchester encoded.
    Seems to have a clock frequency of 4MHz so a "baud rate" of 4MHz too
    (The 125nS is for 1/2 of bit period)
    Your data grab seems to start with a data value of 10101010 for synchronisation then have about 4 data values of 00000000 There seem to be more than 8 bits in each frame. so it is possibly framed something like UART data i.e. with at least a start bit.
    There are chips out there like the HD-6409 that can decode back to "normal" serial (but the HD-6409 is too slow)
    If you are interested in grow-your-own manchester encoders I'd suggest googling "manchester encoder floppy disk" because the manchester encoding scheme was originally developed to record data on primitive tape drives and floppy disks . So there are probably some experimenters out there who have already figured it out, (maybe twenty years ago!).
    Cheers, BobT

Page 1 of 2 12

Similar Threads

  1. Yaskawa SGDM fault help needed
    By tommee10533 in forum Servo Motors / Drives
    Replies: 7
    Last Post: 05-06-2017, 08:37 PM
  2. connecting YASKAWA sgdm-04ADA servopack
    By ba99297 in forum DIY CNC Router Table Machines
    Replies: 0
    Last Post: 04-29-2013, 07:20 PM
  3. Yaskawa SGDM cannot run over 400 RPM!!
    By danielm in forum Servo Motors / Drives
    Replies: 7
    Last Post: 04-11-2012, 11:30 PM
  4. zero speed problem with servo pack Yaskawa SGDM
    By ferdi_mcrohl in forum LinuxCNC (formerly EMC2)
    Replies: 0
    Last Post: 06-01-2010, 02:40 PM
  5. yaskawa SGDA-08AS SERVO DRIVES
    By blackbeard52 in forum Servo Drives
    Replies: 0
    Last Post: 07-08-2008, 02:07 PM

Tags for this Thread

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •