MECHATROLINK-II interface

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

i never tried M-I, only M-II. i haven't found any manuals on the SGDM-DN either.
with MP2300 the 1ms comm cycle looks like this:
0x02ca in the sync packet is a 16-bit sequence counter. no garbage packets, everything is mostly by the book... edited init sequence log attached.

do i understand correctly that you check the CRC and all those random data packets are ok?

a while ago when i was messing with mitsubishi QD75M it also has random data in packets. it was just uninitialized RAM contents changing with each power-on. only a few meaningful fields were set in each init step. CRC was ok to. maybe the same is here?

Yes, I do check the CRC, it's CRC16-X.25. They are okay.
I'm also planning to check watchdog, since i've found the field layout.
Probably it will help to solve some minor puzzles. For example, sometimes servopacks respond to 30h (SMON) as if they were replying to NOP (00h command and data according to NOP layout) and vice-versa. I wonder if there's some kind of "delayed answer" possibility, i.e. to return response next during next transmission cycle. Though it doesn't sound real-time, which is the whole point.

RAM initialisation... Hm, gotta check whether those bytes change after a powercycle.

Anyway, I believe all Sigma-II drives support M-II, so this won't be a problem. How hard is it to modify your firmware to support some more commands (parameter read/write)? Our OEM didn't bother much about tuning and we experience some nasty vibrations (and of course their hell-of-proprietary software doesn't have tuning options).

I thought there would be some kind of PM on this board, but it turned out there is none. So I'll send you (AFAIU, sscnet@[your-personal-site]) another email.

answered via email, duplicating here for the reference
yes, amps do answer with a 2 cycle delay. picture from the manual attached
my card firmware supports parameter reading/writing while servo is on, i just omitted it for simplicity.
but i doubt SGDM drives support M-II. but i could take on implementing it if there's a reason to do it. i have the hardware on hand for debugging.

Oh, hi, i finally figure out this was you, haha.
I'm looking at a biesse with sgdb mechatrolink drives. its got 6 of em, so it seems better to try and keep them than replace, since the performance is adequate.

Whats the status of this card? if i buy this biesse, can i buy a board and run with no issues?

Thanks

i still haven't got an opportunity to test my M-I implementation with an SGDB drive.

so far it works ok with SGDS and SGDV set to an M-I 4Mbps/17byte mode. just yesterday tried with SGDM-xxDN's - there's an issue: drives showing a warning 95 right after controller connects, not every time and not sure why yet. i hope i will sort it out in a few days...

also tested with Omron R88D-KNxxx-ML2 (i believe it's made by panasonic) - the ADJ command is implemented differently and the card firmware can't query connected motor's native encoder resolution. added a module param to manually specify it as a workaround for now. otherwise seems to be functional. M-II implementation details are not in the manual unlike yaskawas. purchased myself such a drive, we'll see what i can find out about it.

as for SGDBs - pretty sure they will work. perhaps it will require some software tweaking during initial testing, but apart from that i don't expect any show-stoppers.

thanks

still not sure if i'm getting this machine, transport is turning out to cost more than the machine so far, oof.