deemesh-sdk 1.3.0

Instantaneous power readings, the Mitsubishi tool management table, two new status codes, and a run of fixes where a plausible value was silently wrong - lathe Y-offset writes that landed in the wrong column, and Siemens alarm reads that never recovered after a dropped link, among them. Fanuc lathes also gain G code system awareness (A, B or C), so modal answers now follow the system the machine is actually in.

Breaking: /machine/toolArea/toolGroupCount (Fanuc) answers -20 instead of 0 on a control without the Tool Life Management option. If your code tested the value for 0 to decide there are no groups, test for status -20 instead. Details under Changed.

Added

• New addresses /machine/channel/axis/axisPower and /machine/channel/spindle/spindlePower: the power being drawn right now, in W, on Fanuc and Siemens. They are the instantaneous partner of the cumulative axisEnergy* and spindleEnergy* (Wh), which need two reads and a subtraction to give usage over an interval. The value goes negative while an axis regenerates. There is deliberately no address for total machine power: Fanuc measures one but Siemens does not, and even on Fanuc the total does not equal the sum of the parts, so the catalog explains what to do instead.

• New addresses /machine/toolArea/tool/originalMagazineNumber and originalPocketNumber: where a tool returns to, on Siemens. magazineNumber and pocketNumber tell you where a tool is now; while it sits in a magazine the two pairs agree, and they part once the tool is in a spindle or gripper, where the current pair reads 0 and these keep pointing at its magazine place. That answers "where will the tool in the spindle go back to", which tool-change planning and magazine housekeeping need. Fanuc and Mitsubishi answer status -20.

• New address /machine/channel/activeToolName: the name of the active tool, on Siemens. It is the partner of activeToolNumber, and both exist for a reason: on a Sinumerik with tool management the T in a part program names the tool, so writing T3 from the number is refused (alarm 17190) while T="CUTTER 10" is accepted. Use this address for what goes into a program and activeToolNumber for the tool filter of the tool tree. The two share a group, so asking for both costs one round trip. Fanuc and Mitsubishi answer status -20; the catalog says why for each.

• Mitsubishi now answers the tool management table. Three new addresses carry that table's own columns, readable and writable: /machine/toolArea/tool/toolTeethCount (the count in "a 4-flute end mill"; Siemens carries teeth per cutting edge at toolEdge/toolTeethCount, this one is per tool), plus toolBodyLength and toolBodyDiameter (the tool body's own dimensions for interference checking, not the toolLengthGeometry compensation family; no other control supplies them). An unregistered tool number is refused with status -18, a value beyond what the field takes with status -16.

• Mitsubishi: /machine/toolArea/toolCount, toolList and tool/toolExists now answer, and toolExists creates and deletes tools there: true writes the number into the first empty row of the tool management table, false clears that row. A duplicate is refused with status -21, and deleting a tool that is not there succeeds. toolCount and toolList take about 1.2 s on Mitsubishi and are not for polling (that control's table has 999 slots read one at a time); creating, and deleting a tool that is not there, walk the whole table too. The tool/… addresses stop at the match and answer in tens of milliseconds. toolList items keep one key set on every control: the common keys (null where a control has no such concept - on Mitsubishi the location fields included) plus that table's four per-tool columns (null outside Mitsubishi). On Mitsubishi the list comes in the table's row order - the order its screen shows - rather than ascending tool number.

• New address /machine/toolArea/tool/toolOffsetNumber (Mitsubishi, read/write): the link from a tool number to that tool's compensation values. Put it into the toolOffset filter of /machine/channel/toolOffset/… and you get the geometry, wear and nose radius; it can differ from the tool number. Writing it changes which compensation values apply to that tool, so it is not an edit of one value; the upper bound is /machine/channel/toolOffsetCount.

• New status code -23 DEEMESH_ERR_NO_ROOM: nothing is there to collide with, but there is no free slot to create it in. The sibling of -21: where that one refuses because the object already exists, this one refuses because a table or magazine with a fixed number of slots is full. Creating a tool on Mitsubishi when the tool management table has no free row answers it (refusing as -16, invalid write value, would point at the wrong thing - the value is fine and so is the filter, and the caller's next move is to delete one entry to free a slot). The name carries no resource, so the same code fits the next fixed-size place.

• New status code -22 DEEMESH_ERR_MACHINE_STATE: the request is right but the machine will not do it in its current state (running, write-protected, in alarm, emergency stop, wrong mode). These refusals used to come back as -17, which means "an internal fault, nothing for you to do" - the opposite of the truth, since an operator can clear the state. It covers Fanuc EW_PROTECT/EW_MODE/EW_REJECT/EW_ALARM/EW_STOP, the Siemens alarm 4230 refusal of setting-data writes outside Reset, and the Mitsubishi safety password lock. Do not put it in an automatic retry loop: unlike -10 and -14, clearing it usually needs someone at the machine.

Changed

• The catalog now says plainly that axisLoad, axisPower and spindlePower have never been seen to produce a value on Siemens. On our test machine they stayed 0 while an axis moved at 1498 mm/min and a spindle turned at 1425 rpm, with axisCurrent and spindleLoad moving at the same moments. It is not our reading: during a program run that moved every axis we compared the channel-local and the global block of the value in one request and both read 0 for every axis, so that machine simply does not supply it (the manual restricts these values to PROFIdrive drives). We have still not seen a machine that does. Since a control does not distinguish 0 from "no value", each section tells you to confirm a value appears before relying on the address there.

• Fanuc: /machine/toolArea/toolGroupCount refuses with status -20 when the control has no Tool Life Management option, where it used to answer 0. A count of 0 read as "the feature works and there are no groups", which is not what a missing option means. toolCount and toolGroupCount now answer the same question for their own option, so reading the two tells you which tool features a control has.

• The catalog's auxModal/auxModalValue section now describes the measured Siemens behaviour instead of a warning that it was unverified. Measured while running: S and M are modal there as on the other two controls, but go back to null when the program ends (M30), where Fanuc and Mitsubishi keep the last value even through a reset; and on a machine that changes tools on T itself, T stayed null even after being programmed, so read the commanded tool from activeToolNumber.

• Fanuc: /machine/cncModel now names the control's generation in desc where the control reports one (Series 31i-B, Series 0i-F; it used to say Series 31i, Series 0i). value is unchanged. Controls that do not report a generation - 0i-A/B/C, 30i-A and earlier series - get no letter, so treat the letter as extra information rather than something every machine carries.

Fixed

• Siemens: after a dropped and re-established OPC-UA session, every alarm read (alarmList, alarmCount, alarmStatus, and emergencyStatus while the machine is not ready) timed out with status -14 until the process was restarted. SINUMERIK does not let a new session take over the old session's event subscription, and it accepts a refresh call on the dead subscription without complaint, so the SDK kept waiting for events that no longer had anywhere to arrive. The subscription is now rebuilt after a reconnect, and a timed-out alarm read also resets it so the next read recovers on its own. Long-running processes on links that drop periodically were affected; plain reads and writes were not.

• Fanuc lathes: /machine/channel/toolOffset/toolYGeometry and toolYWear addressed the wrong column of the offset table. Geometry read and wrote the Y wear value, and wear read and wrote the imaginary tool nose column, which holds the tip direction code rather than an offset. Reads therefore returned a plausible number from the wrong place and writes landed in the wrong column, the tip direction included. The type codes now follow the FOCAS table (toolYWear 8, toolYGeometry 9). Only Fanuc lathes with the Y-axis offset option were affected; every other offset leaf was already correct. The remaining seven columns are now verified against a lathe's own offset screen: a distinct value written to each through this SDK appeared in the matching column of both the WEAR and the GEOMETRY page.

• Fanuc lathes: deemesh now reads the G code system (A, B or C) when it connects, and modal answers follow it. /machine/channel/gModalCategory/gModal?gModalCategory=3 (absolute/incremental) refused with status -20 on every lathe, which is right for system A - that system has no such modal group and uses the U/W addresses instead - but wrong for systems B and C, which do have it. The system comes from GSB (bit 6) and GSC (bit 7) of parameter 3401, read once per path at connect. It also selects the right codes for the twelve group-and-index pairs where the three systems disagree, such as the single fixed cycles G90/G92/G94 in system A against G77/G78/G79 in B. A control whose parameter cannot be read is treated as system A, which is what the control itself does when the B and C options are absent. The refusal message now says which system the machine is in and what it uses instead.

• Fanuc lathes on older controls: G code group 17 reported G50 where no such group exists. That group belongs to G code systems B and C, not to system A, which is what the fallback table describes. A control that does not report the group hands back a zero, which the table then rendered as an active G50. It now reports nothing there. This only affects controls old enough to lack cnc_rdgcode (Series 16/18/21, 16i/18i/21i, 0i-A/B/C, Power Mate i); newer ones get the code as text from the control itself.

• Fanuc: a tool offset column the control does not have answered status -17 (an internal fault) instead of -20. The catalog already said -20 for a column a machine lacks; now the code agrees. A lathe without the Y-axis offset is the common case, and the machine type alone does not settle it, since the columns a control actually carries are part of its configuration. Reads and writes both answer -20 and the message names the columns the machine type can have.

• The catalog claimed that on Siemens /machine/channel/activeToolNumber only changes once a tool change has completed, so programming T alone would still show the previous tool. That is not true on every machine. Whether M06 or T itself performs the change is a machine-builder setting; on our 840D sl bench, T="CUTTER 10" alone completed the change, and the tool's toolLocationType moved from magazine to buffer while the tool it replaced went the other way. The catalog now says the Siemens behaviour depends on the machine and points at toolLocationType as the reliable answer. It also records that under Siemens tool management a part program addresses tools by name, so this value (and the tool filter) is the control's internal number, not the text you type: T3 was refused with alarm 17190 while T="CUTTER 10" was accepted and resolved to internal number 3.

• Fanuc: /machine/toolArea/toolGroupToolCountList, registeredToolGroupList and exchangeRequiredToolGroupList returned an empty array on a control without the Tool Life Management option. The catalog already said they refuse with status -20; now they do.

• A path or PLC type the control rejected came back as status -17 (an internal fault) instead of -18 (fix your input). Reading /machine/ncMemoryPath/fileContent with a directory path did this on Fanuc and Siemens, and so did /machine/plcAddress/plcType/plcValue on Mitsubishi when the device does not accept the given plcType. All three now answer -18 and say what to change; Mitsubishi already answered -18 for the directory case, and the other plcType values already did.

• Fanuc: writing /machine/channel/mainProgramPath answered the wrong status for a bad path. A directory came back as -16 (invalid write value) and a path that does not exist as -17 (an internal fault, nothing for you to do), where the catalog promises -18 for both and Siemens and Mitsubishi already answer -18. The same situation now reads the same code on all three controls, and the nonexistent-path message names the path so you can fix it. A machine that refuses the selection because of its mode still answers -22.

• Fanuc: /machine/ncMemoryPath/entry and entryName failed on the NC memory root (the very path /machine/ncMemoryRootPath hands you), where Siemens and Mitsubishi answered. They now return the root as a directory entry. On Siemens the same read returned the internal node name FileSystem; it now returns the name the path uses, NC.

• Mitsubishi: /machine/channel/operateMode answered 99 (Unknown) for a part system with no mode selected, where the same state reads 5 (no mode) on Fanuc. 99 means we could not interpret what the control gave; here the control was saying plainly that no mode is selected, and the operator panel shows it. It now reads 5. This is common on a multi-part-system machine, where each part system has its own mode: while you work in one, the other sits in this state. A response too short to carry the mode bits still reads 99, since that is us not seeing the answer rather than the machine giving one.

• The test-environment note now says what each machine actually is. Three corrections, none of which changes an address: the Siemens side was called a physical machine when it is a real SINUMERIK 840D sl control on a bench, with drives and no machine tool, the same kind of setup as the FANUC Series 31i already described that way; a FANUC production machine is now listed, since the data-server fix in 1.2.1 was verified there; and the Mitsubishi entry no longer claims the M700 series. Every Mitsubishi measurement was made on an M800-series NC Trainer2 plus. The system_type token for an M700 opens a session against that simulator, which is what led to the claim, but no M700 control was ever involved. The four models the adapter supports are unchanged; only the account of what was tested is corrected.