deemesh-sdk 1.4.0

Soft-limit areas become addresses of their own, a new status code says "busy, send it again shortly", the working-area limit gets its per-axis switch, and a run of fixes where a plausible value was silently wrong: axisSoftLimitPositive / …Negative reported area I even while the PLC had another area in force, a Siemens R parameter the channel does not have read as 0, and a Siemens node the server refused read as 0 too. One breaking change: those two soft-limit addresses are read-only from this version. Refusals that are really machine state now say so with status -22 (a Siemens file the channel is using, a Mitsubishi work offset during automatic operation), a Siemens upload over an existing file answers -21 instead of pretending to overwrite, and a Siemens deemesh_destroy / deemesh_disconnect that could block forever once the peer had vanished now returns within a few seconds.

Breaking: /machine/channel/axis/axisSoftLimitPositive and …Negative are read-only from this version; a write answers status -20. Write the setting of a named area through axisSoftLimitArea/axisSoftLimitPositive / …Negative instead.

Added

• Soft-limit areas: five new addresses under /machine/channel/axis/. axisSoftLimitAreaCount (Fanuc 2 or 8, Siemens 2, Mitsubishi 1), axisSoftLimitArea/axisSoftLimitPositive and …Negative (the setting of the area named by the axisSoftLimitArea filter, read and write), and axisSoftLimitPositiveAreaNumber / …NegativeAreaNumber (the area in force for that direction, read-only). The Siemens 2nd software limit switch is reachable through the area folder.

• New status code -24 (DEEMESH_ERR_BUSY): busy right now, send the same request again shortly. Fanuc: EW_BUSY (another call in progress) was reported as -17. deemesh-hub uses it with HTTP 409 when a machine's file-operation or download slot is taken, and with HTTP 503 while it is shutting down. Unlike -22 nothing has to change at the machine.

• New address /machine/channel/axis/axisWorkAreaLimitOn: the per-axis switch of the working area limit, read and write on Fanuc (parameter 1310#0) and Mitsubishi (#8202). Those two controls switch it per axis, so axisWorkAreaLimitPositiveOn / …NegativeOn answer status -20 there; Siemens switches per direction and answers status -20 here instead. The same no-entry-box gate as the value addresses applies.

Changed

• /machine/channel/axis/axisSoftLimitPositive and …Negative are read-only (a write answers status -20). Write a named area through axisSoftLimitArea/… and find the area in force with axisSoftLimit…AreaNumber.

• Siemens: writing /machine/ncMemoryPath/fileContent to a file that already exists answers status -21 (already exists) instead of -17, and the file is left untouched. Siemens does not overwrite; delete the file through fileExists first, then upload. The catalog said the file was overwritten, which was never the case on Siemens (Fanuc with parameter 3201#2 set and Mitsubishi do overwrite); it now states the behavior of each control. deemesh does not delete and recreate on your behalf, because a failed creation would lose the original.

Fixed

• Siemens: a file operation refused because a channel is using the file answers status -22 (machine state) instead of -17. Deleting the selected main program or a subprogram that is running or already opened by the look-ahead, renaming such a file, and creating a file under such a name all answered -17 (BadInvalidState / BadNotSupported). When the control refuses, deemesh now checks the channels and answers -22 when one is not in Reset. A failed creation no longer leaves an empty file: when Open, Write or Close fails after CreateFile, deemesh deletes the file it just created, and says so in the error text if the control does not let it.

• Mitsubishi: writing /machine/channel/workOffset/axis/workOffsetValue while the control is in automatic operation answers status -22 (machine state) instead of -17. The control refuses the edit (the panel shows "Executing automatic operation"); reset the channel or wait for the program to end. A rejection outside automatic operation now answers -16 (the value), since the control uses the same code for a value it cannot store. The catalog's workOffsetValue section now tabulates, per control, whether the table can be edited during automatic operation and when an edit reaches the coordinates.

• Siemens: /machine/channel/variable/variableValue with an R number the channel does not have answers status -18 with the allowed range (expected 0-99), on reads and writes. A read answered status 0 with value 0.0, so a program could not tell a missing R parameter from one holding zero, and a write answered -17. deemesh now reads numRParams (machine data 28050) per channel at connect and checks the number before contacting the machine. R numbering starts at 0.

• Siemens: a node the server answers with a Bad status no longer reads as value 0 with status 0. Every scalar and array read on Siemens turned a missing value into 0; such an item now answers status -17 with the node and the server's status in the error text. On a healthy machine nothing changes: an old-vs-new sweep of every Siemens read address on the test bench differed only in the R-parameter case above.

• /machine/channel/axis/axisSoftLimitPositive and …Negative now return the soft limit in force. They returned area I (Fanuc 1320/1321, Siemens 1st switch) even while the PLC had selected another area, so on such a machine the value was not the limit actually enforced. On a machine that never switches areas the value is unchanged.

• /machine/channel/mainProgramPath write: a selection refused because of the channel's state answers status -22 (machine state) on all three controls, with the state in the error text. Fanuc answered -18 "no program at that path" while a program was running; Siemens (channel not in Reset) and Mitsubishi (program operation in progress) answered -17. A path that really is missing or malformed stays -18.

• Siemens: deemesh_destroy and deemesh_disconnect could block indefinitely when the peer had vanished without closing the connection (server killed, machine powered off). Both now try the graceful close for a few seconds and then return; a live connection still closes in well under a second. Blocking bounds per function are listed in FFI_KO.md / FFI_EN.md.

• Siemens: reading /machine/channel/alarmList no longer writes an INFO log line per read. The diagnostic line is now DEBUG, so polling alarms every few seconds no longer fills the log with it and write audit lines stay readable. Turn it back on with RUST_LOG=deemesh::nc::opcua_siemens=debug. The line that reported which event-notifier candidates the server does not use moved to DEBUG as well, and no longer calls them "rejected": probing several candidates and keeping the ones the server accepts is how the alarm subscription is set up, so the leftovers are a normal result, not a fault. A real failure is an error, not a log line.