Contribution proposal: read-only SLMP (MELSEC-Communication 3E) driver

[LivingLikeKrillin]

Following up on #1728 (the answer there was essentially "no plans, but contributions welcome") — I'd like to build this.

I've previously implemented the MC protocol family in production — the 3E frame in both ASCII and binary codings — so the protocol itself is well-trodden ground for me; the genuinely new part for me is PLC4X's mspec/SPI conventions. I'd implement strictly from Mitsubishi's publicly available MELSEC Communication Protocol Reference Manual (SH-080008), which documents the 3E/4E frames, the device-code table, and the batch/random-read commands — so there's no dependency on member-restricted CLPA material.

To keep it reviewable, I'd start with a deliberately small read-only PoC and grow it in stages:

• v0 (first PR): 3E binary frame, read-only, Batch Read (0x0401, word units), D device, types INT/WORD/DINT/REAL, single request — plus a ParserSerializer test-suite so the wire layer is verifiable without hardware.
• then, in stages: more devices (W/R/M/X/Y/B) → bit units → Random Read (0x0403) with an optimizer (batch-vs-random selection, max-points splitting) → ASCII coding → 4E frame (serial-number correlation) / write / iQ-R extended addressing.

On naming and structure: I'd call the driver slmp (the open CLPA spec name, which covers the MC protocol — happy to switch to mc/melsec if you'd prefer), laid out mirroring the modbus driver: stateless TCP request/response, a base module plus thin per-coding modules, and a discriminatedType ADU switching frame-type/coding, which maps cleanly onto 3E/4E × binary/ASCII. The device-addressing tag layer I'd model on s7 (MemoryArea + bit/word transfer-size + offset), since SLMP's device-code matrix (D/M/X/Y/W/B/R, per-device radix, bit/word) is structurally much closer to s7 than to modbus's flat register model. The later read optimizer would draw on s7's S7Optimizer/S7BlockReadOptimizer.

Before I open the first PR, two things I'd rather confirm up front:

1. Placement — does protocols/slmp (mspec) + plc4j/drivers/slmp work, or would you rather it incubate elsewhere first?
2. Granularity — is a staged, read-only-first PoC PR an acceptable way to start, or would you rather see a larger initial scope?

Happy to open a draft PR with the v0 scaffold + tests if that's easier to discuss concretely.

[chrisdutz]

Hi,

that would be awesome ... I've had that driver on my todo list for quite some time now. So I'm also happy to jump in and help you with that.

From a procedural point of view, usually the best strategy is to start with the mspec, use that to generate the parsers and serializers. If you have a pcap of some reference communication, I ususally use that to test the mspec to ensure it is able to correctly decode and encode all message types.

As soon as that's done, I start building the driver logic.

I would strongly encourage you to start that way too ... and please don't look at the current Java driver implementations on the develop branch. I'm currently completely rewriting the SPI and all drivers to work without Netty and with a lot simpler architecture. Implementing a new driver based on that will be a lot less frustrating.

I'm expecting to merge my changes back to develop in a week or two ... still two drivers that need porting. As soon as they are done, I'm planning on merging and then replace the other parts that I want to renew (connection cache and new version of the scraper).

So ideally we discuss things on dev@plc4x.apache.org (YOu need to subscribe by sending an empty email to dev-subscribe@plc4x.apache.org and confirming the email you'll get after that). But also feel free to open a PR here, if you feel more comfortable with that. If you're interested in really joining the team ... the dev list will be the way to go.

Feel free to ping me, if you need any help with anything.

[LivingLikeKrillin]

Thanks @chrisdutz, that's really encouraging — and thanks especially for the heads-up about the SPI rewrite. I'll steer clear of the current develop-branch driver implementations and build the driver logic on the new SPI once it lands.

I've followed the mspec-first path you described and made a start (wire layer only, read-only):

• An slmp.mspec for the 3E binary frame, modelled strictly from the public SH-080008 manual — subheader (50 00 / D0 00), the fixed 3E access route, the little-endian length/timer fields, Batch Read 0x0401 in word units, and the MELSEC-Q/L 1-byte device codes.
• A ParserSerializer test suite with request/response vectors taken straight from the manual's worked example (reading D350/D351). The protocol module builds and its type-resolution check is green; the byte-level round-trip lives in the driver module and lands with that step. As an extra sanity check I also pointed pymcprotocol at a small mock and the framing lines up byte-for-byte.

On validation — point taken that a real pcap is the right standard, not just my reading of the manual. So before I'd call the wire layer done, I'll pin the mspec against a real-hardware 3E capture rather than only spec-derived vectors.

One thing I'd like to check before pushing further: does the mspec language and the generated read-write code stay stable through your SPI rewrite? My plan is to keep the mspec + ParserSerializer work going now (it's the codegen layer and shouldn't touch the runtime SPI), and only build the driver logic — protocol logic, transport, tag handler — on the new SPI after it merges. Does that sequencing match what you'd want, or should I hold the mspec too until then?

I've kept this on the issue since it's a quick question, but happy to move over to dev@ if you'd rather discuss there. No rush on my end — and I can open a draft PR with the mspec + ParserSerializer suite whenever it's useful. Thanks again!

[chrisdutz]

The mspec language generally stays totally stable. However in place of a freemarker based generator I created a javapoet based java implementation. The generated code is slightly different, but semantically stays the same. One thing that the new SPI requires, is explicit encoders for the various types of variable-types. The old SPI had hard-coded standards, but now all is dynamic any the root type in an mspec grammar should provide these defaults.

Example:

[discriminatedType ModbusADU(DriverType driverType, bit response) byteOrder='"BIG_ENDIAN"' unsignedIntegerEncoding='"unsigned-binary"' signedIntegerEncoding='"twos-complement"' floatEncoding='"IEEE754"' stringEncoding='"UTF8"'

[chrisdutz]

Hi,

I just saw that you were aiming at multiple places to improve things ... while GH Issues and PRs provides the means to communicate technical aspects, the mailinglist and the slack instance is where the community hangs out. People usually don't follow issues and prs they are not involved to. So the mailinglist and slack are the places to go, if you're also interested in the community behind this great project.

Chris

[LivingLikeKrillin]

Thanks Chris — point taken, on both the technical side and the community side.

Quick ack so your encoding-defaults note isn't left hanging: got it — I'll declare the encoding defaults at the root in the quoted-string form (byteOrder='"LITTLE_ENDIAN"' etc.) when I move SLMP onto the new SPI, and keep the mspec on current develop until your rewrite lands. I'll bring the details to the list rather than pile them up here.

Subscribing to dev@ and joining Slack now, and I'll carry the SLMP discussion there — keeping this issue just for tracking. Thanks for pointing me to where the community actually is.

[chrisdutz]

For Slack, please ping me directly if you're not yet a committer at any apache project, because you'll need an invite.

Send me a direct message to cdutz@apache.org and I'll send you an invite.