Copilot commented on code in PR #2597:
URL: https://github.com/apache/plc4x/pull/2597#discussion_r3489398114


##########
protocols/slmp/src/main/resources/protocols/slmp/slmp.mspec:
##########
@@ -0,0 +1,167 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one
+ * or more contributor license agreements.  See the NOTICE file
+ * distributed with this work for additional information
+ * regarding copyright ownership.  The ASF licenses this file
+ * to you under the Apache License, Version 2.0 (the
+ * "License"); you may not use this file except in compliance
+ * with the License.  You may obtain a copy of the License at
+ *
+ *   https://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing,
+ * software distributed under the License is distributed on an
+ * "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+ * KIND, either express or implied.  See the License for the
+ * specific language governing permissions and limitations
+ * under the License.
+ */
+
+// SLMP (Seamless Message Protocol) / MELSEC Communication protocol.
+//
+// Specification: Mitsubishi "MELSEC Communication Protocol Reference Manual"
+//   (SH(NA)-080008, public). All field layouts below are taken from that 
manual:
+//     - 3E frame message format ....... section 5.2
+//     - Subheader (50 00 / D0 00) ...... section 5.3
+//     - Access route (3E fixed value) .. chapter 6
+//     - Request/response data length ... section 5.3 (2-byte, little-endian)
+//     - Commands (Batch/Random/block Read) chapter 7 / 8.1 / 8.3 / 8.4
+//     - Device code list ............... section 8.1 (MELSEC-Q/L, 1-byte 
binary)
+//     - Batch Read data layout ......... section 8.1 (binary, word units)
+//     - Random Read data layout ........ section 8.3 (binary, word units)
+//     - Multi-block Read data layout ... section 8.4 (binary, word units)
+//
+// Scope of this initial version: 3E binary frame, read-only, Batch Read
+// (command 0x0401), Random Read (command 0x0403) and Batch Read Multiple 
Blocks
+// (command 0x0406) in word units (subcommand 0x0000). This is the wire layer
+// only; typed value decoding
+// (INT/WORD/DINT/REAL) and the device-addressing tag layer are intentionally
+// NOT modelled here yet and will follow once the driver logic is built.
+// Validated hardware-free via the ParserSerializer test suite.
+//
+// All multi-byte numeric fields are little-endian (transmitted 
least-significant byte first).
+// The 2-byte subheader (0x50/0xD0 then 0x00) is modelled as two single bytes 
so
+// its on-wire order is preserved regardless of the frame byte order.
+
+[constants
+    // Typical SLMP TCP port; the actual port is configured on the device and 
is
+    // overridable by the driver, so this is only a default.
+    [const uint 16 slmpDefaultPort 5007]
+]
+
+// Device codes for MELSEC-Q/L series commands (subcommand 0x0000 / 0x0001),
+// 1-byte binary, from the device code list in SH-080008 section 8.1.
+// Only the word/bit devices needed by the read-only road-map are listed.
+//
+// These 1-byte binary device codes are confirmed identical in the Mitsubishi
+// MELSEC iQ-F FX5 SLMP manual (JY997D56001) -- D=A8 W=B4 R=AF M=90 X=9C Y=9D
+// B=A0 -- so the same frame works on FX5 hardware (e.g. FX5S) as well as
+// MELSEC-Q/L. (FX5 also offers a 2-byte/extended code form via subcommand
+// 0x0002/0x0003 for ZR and large device numbers, which is out of scope here.)
+[enum uint 8 SlmpDeviceCode
+    ['0xA8' D]  // Data register   (word, decimal addressing)
+    ['0xB4' W]  // Link register   (word, hex addressing)
+    ['0xAF' R]  // File register    (word, decimal addressing)
+    ['0xC2' TN] // Timer, current value (word, decimal addressing) -- used by 
the
+                // Random Read worked example in SH-080008 section 8.3
+    ['0x90' M]  // Internal relay  (bit,  decimal addressing)
+    ['0x9C' X]  // Input            (bit,  hex addressing)
+    ['0x9D' Y]  // Output          (bit,  hex addressing)
+    ['0xA0' B]  // Link relay      (bit,  hex addressing)
+]
+
+// 3E frame. The Ethernet/TCP header is added by the transport and is not part
+// of this message. Request and response are distinguished by the subheader 
byte
+// (0x50 request / 0xD0 response).
+[discriminatedType SlmpMessage byteOrder='"LITTLE_ENDIAN"' 
unsignedIntegerEncoding='"unsigned-binary"' 
signedIntegerEncoding='"twos-complement"' floatEncoding='"IEEE754"' 
stringEncoding='"UTF8"'
+    [discriminator uint 8 subHeader]                  // 0x50 request, 0xD0 
response
+    [const         uint 8 subHeaderReserved 0x00]     // second subheader byte 
is always 0x00
+    [typeSwitch subHeader
+        ['0x50' SlmpRequestFrame3E
+            // Access route - fixed value for 3E frame (chapter 6): 00 FF FF 
03 00
+            [const    uint 8  network                  0x00]
+            [const    uint 8  pcNumber                 0xFF]
+            [const    uint 16 requestDestModuleIoNo    0x03FF]
+            [const    uint 8  requestDestModuleStation 0x00]
+            // Number of bytes from the monitoring timer up to the end of the 
request data.
+            // = monitoringTimer(2) + command(2) + subCommand(2) + requestData
+            [implicit uint 16 requestDataLength        '6 + 
requestData.lengthInBytes']
+            [simple   uint 16 monitoringTimer]                 // 0x0000 = 
wait infinitely
+            [simple   uint 16 command]                         // 0x0401 = 
Batch Read
+            [simple   uint 16 subCommand]                      // 0x0000 = 
word units
+            [simple   SlmpRequestData('command') requestData]

Review Comment:
   `subCommand` is currently modeled as a free `uint16`, but this mspec only 
implements word-unit layouts (documented here as subcommand `0x0000`). Leaving 
it unconstrained allows constructing/serializing frames with unsupported 
subcommands that will still be treated as word-units by this model, producing 
invalid or misleading messages.



-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: [email protected]

For queries about this service, please contact Infrastructure at:
[email protected]

Reply via email to