MECHATROLINK-II interface

just got it running. the interface seems to be working ok so far using a cannibalized ethernet transformer for rs-485 isolation and off-the-shelf USB cables/connectors. the controller is implemented in a FPGA on one of my SSCNET cards. will probably make Mechatrolink II version soon...

Please contact me in regards to this project. Thank you.

Impressive!
It's a shame I've not visited RE stackexchange for quite a while and therefore I've missed your reply on frontend RE.

Anyway, since the time I asked that question, I built a receiver, captured some data from a live machine, found some helpful leaked docs on chinese sites and managed to write some software to parse the logic analyzer captures automatically. So, now I have some understanding of physical and data link layers.
But the docs for SGDB/M drives I have are somewhat ambiguous on many topics related to mechatrolink commands. And I don't think I understand the motion commandset and the phases (connection init) quite as well. I hope I'll be able to sort it out by capturing some more data for different phases and dissecting it.

Sadly, there's one mechatrolink-unrelated thing I can't understand. I've seen the architecture block diagram in the LinuxCNC developer manual, and it implies that Servo PID loop, Homing and Interpolation are essential parts of the real-time subsystem, i.e. they precede HAL. But yaskawa servopacks have all that built in. Therefore, when using Mechatrolink, all we've to do is send coordinates to the servopacks right after trajectory planning.
I already know that you've been able to make YMTL2P board, therefore this has to be possible. But is it easy? How do I even approach this task?

Btw, I've dropped you an email, have you received it?

hey! nope, i haven't got your email...

all i've done i bought an MP2300 and SDGS drives and snooped on the bus. then it was obvious that it is a manchester encoding with bit stuffing. and some headers in packets. everything else in documented in public yaskawa docs. following your posts on stackexchange i used an ethernet transformer with a diff transceiver. seems to be working fine so far.,,
you're right, you don't have to have a position PID loop in linuxCNC. the drive handles it, i just feed it with a target position.

and on the mechatrolink... how i did it. the interface card has a state machine for each axis. the state mostly corresponds to the last MII command sent. it starts from
DISCONNECT, if a reply is received next state is
CONNECT, next
CONFIG
SENS_ON
ADJ
ALM_CLR
SMON - here it loops sending motor feedback position, alarm status, and so on to the linuxcnc driver. until joint.x.amp-enable-power goes true, then
SV_ON
INTERPOLATE - loops again like in SMON until amp-enable-power is deasserted. then
SV_OFF and back to SMON loop

CONNECT command is used to go directly to sync comm mode 3, and always stay there in constant 1ms cycle. subcommand in INTERPOLATE is SMON used to monitor torque and position error.

i haven't yet implemented absolute position, but it should be similar to mitsubishi.. it just basically means that 32-bit position feedback counter is non-volatile. i don't use drive's homing functions. instead i use normal linuxcnc homing functionality with limit switches. patched linuxcnc a bit so it stores motor_offset in a position file upon exit. i also added joint.x.set-homed pins which set "homed" flag for a joint and i assert this pin when a drive reports it is in absolute mode and battery is ok so the position is valid.

Yes, the sequence you posted is what I expected to see on my system. However, this is not the case.
My setup is actually quite old, SGDM-xxDN (btw, there are no docs for DN models, they don't have a panel operator and are mechatrolink-only) drives from 2003 and JASP-NT001 (looks like an ISA (PC/104) ancestor of JAPMC-NT110). It's running Mechatrolink-I, 4Mbps. Manchester, HDLC etc is of course, the same, NOPs and SMON (30h) are the same too. There are also sync frames (address FF), that divide the communication timeline into transmission cycles. In idle state (after booting up the system) I do get NOPs and SMONs (00 and 30h). Have not looked thoroughly at captures during motion, so this is out of the question for this post.

Finally, the differences are:
1. There's a ton of what looks like garbage inside each transmission cycle. Nonexistent (reserved?) address 00h, control code values all over the place (24, 68, 4F hex etc), all 14 data bytes non-zero and appear to be random, but consistent with control code (i.e. only one data string corresponds to one code, only 2-3 bits vary independent from control code). At first I thought these are just fillers to fill empty space inside transmission cycle (HDLC allows it), my cycle is 2ms with only 6 servos, so there's plenty of time to waste. But the correlation between control codes and data bothers me. And also, why bother filling empty space with any data at all, why not with zeros...
2. There's no clear DISCONNECT -> CONNECT sequence after the master is powered on. I've done proper measurements, i.e. set up a delayed trigger source to skip just the noise present on the bus after powering everything on and then triggred on any edges on the line itself. There's not a single edge before I boot the PC up and log in (it's running Windows + IntervalZero RTX). After login the master just starts sending some nonsensical commands, starting from a random, but this time valid address each startup (e.g. 42h). After about 500 packets everything settles and NOP loop starts (I'll attach a parsed capture). Transmission cycles are also "filled" with nonsensical packets with zero address as described in p.1. 0F [disconnect] and 04h [config] commands seem to be present in the capture, but 0F is always sent to 44h only (just as 1B to 43 etc), so I think this is just a coincedence; and 04 is a part of "filler", sent to 00.

The manuals are not-so-public, official mechatrolink specifications are available for MMA members only, and while the membership is free, they simply don't reply to my emails. And for obscure pieces of gear like my ISA mechatrolink controller, that are only Mechatrolink-I-compliant, I suppose there are no docs left at all... Yaskawa's servopack manuals contain some info on mechatrolink commands, but this info is not always complete. For example, I can't find the I/O field (in SMON) bit layout, and it appears yaskawa didn't follow a reference one (like in "General command specifications for Stepper Motors", that somehow covers servos too). STATUS field bit layout I'm using appears to be partially correct, Main PSU ON bit toggles when it should, but "Zero point" and other homing/motion-related bits are just never toggled (neither after initial homing, nor after manual jog, but the software somehow knows whether homing has been successful or not). All alarm codes I've come across are vendor-specific (>80h), and I've not yet figured out whether mechatrolink alarm codes coincide with error codes, intended to be displayed on panel operator. For example, my servos always (almost) report 99h. Never seen this code in SGDM manuals (may be it means "OK" though?)...

I'm starting to think that Mechatrolink-I had some different connection mechanism.

Attachment: full initialization after power on. The start of the file demonstrates what I described in p.2, and the end of the file corresponds to p.1