Neutron Modbus RTU/TCP — integration manual

CloudScale Neutron NS and Neutron NT provide a Modbus interface for reading weighing data, status information, digital I/O and calibration data, and for executing selected scale commands. The interface is intended for PLC, SCADA, HMI, MES and custom software integrations.

Neutron supports the following Modbus transport variants:

The available functions and register areas are the same logical interface for Modbus TCP and Modbus RTU, except that TCP uses a Unit Identifier only where required by the client or gateway.

Important: Communication parameters such as serial port settings and network settings must be configured in Neutron before the Modbus master is connected. The device uses the Modbus address configured by parameter MBA.

Modbus TCP is available through the network connection of the Neutron. Use the IP address assigned to the device and TCP port 502. TCP communication does not require a serial line configuration.

To use Modbus TCP you must select Modbus TCP under scale communication interfaces (parameter SCI). You can use Modbus TCP while also using other interfaces, for instance you can still use RS-232 for communication with computer via CSCP protocol.

Where several SCI values are shown, configure the interfaces according to the selected Neutron communication configuration. After applying configuration changes, restart communication or the device where required by the configuration menu.

For a stable industrial installation, Ethernet is recommended whenever a wired network is available. Wi-Fi adds network-dependent latency and should be assessed in the application environment.

Modbus RTU can be used through RS-232 or RS-485. The serial communication settings of the Modbus master must match the serial interface settings configured in Neutron. The Modbus slave ID is set by MBA and defaults to 1.

To use Modbus RTU you must select either Modbus RS-232 or Modbus RS-485 under scale communication interfaces (parameter SCI).

Always follow the Neutron terminal marking and the wiring diagram supplied with the device. Manufacturers do not always label RS-485 polarity in the same way; if no communication is established, verify the A/B polarity and the master configuration.

This manual uses the conventional Modbus reference notation (for example, 40101). Many Modbus client tools use zero-based start addresses. In such tools, remove the leading register-area digit and subtract 1 from the reference address.

Confirm the addressing convention of the Modbus master before commissioning. An offset error of one register is the most common reason for incorrect data interpretation.

Example: where the decimal-position field indicates 2 decimals, the signed 32-bit value 12345 represents 123.45 in the active unit. The unit is available in register 40113 and is also encoded in the output/status configuration register.

Write operations to outputs controlled by a configured output function are rejected. Typical function-controlled outputs include tolerance and dosing outputs.

The main map allows simple masters to obtain net or gross weight and key status data using a small contiguous register range.

For applications that require all output states, use register 40115. Use register 40116 to determine which outputs are currently reserved by the active function.

Write a command code to holding register 40232. Write the optional parameter to 40233 before issuing the command. The command status can be read from 40231. Command code 0 clears the repeat guard and allows the same command to be executed again.

Shortcut: writing the command code to holding register 40001 also executes the command. For predictable integration, the extended command registers 40232 and 40233 are recommended, particularly where a parameter is required.

Example: To activate DO1 and DO3 with command code 25, write a bit mask of binary 000101 (decimal 5) to 40233 and then write 25 to 40232. Verify the result through register 40115 or coils 1..6.

Calibration is performed through holding registers. Successful calibration data are stored to flash memory. If calibration fails, the changed data are not saved.

Point 1 starts at 40310 (zero-based start 309). Each calibration point uses eight registers. The start register for point N is 40310 + ((N - 1) x 8).

Examples: point 1 = 40310-40317; point 2 = 40318-40325; point 3 = 40326-40333; point 8 = 40366-40373.

Flags register 40384: bit 0 controls whether stability is required. A value of 0 executes immediately; a value of 1 requires a stable ADC average. All other flag bits are reserved.

Firmware processes calibration only when the trigger register 40385 changes to a non-zero value. Use the following sequence for every calibration command:

Safety note: Calibration, zeroing, taring and output control can affect the weighing result and connected machinery. Apply access control, validate commands in the host application and ensure that all operations comply with the applicable metrological and machine-safety requirements.

This chapter describes the basic CHECKWEIGHER interface, register map version 1. It supports reading process status and the last completed result, selecting an existing recipe, configuring autostart, and START / STOP / STOP NOW / RESET. Recipe editing, filter configuration, application selection, I/O assignment and detailed debug streaming are not included. Configure these using the normal setup interface before using this block.

The map is identical on Modbus TCP and enabled Modbus RTU interfaces. Use one controlling client/master; additional readers may monitor the data. There is one shared command mailbox across all transports, not one mailbox per client. Do not use broadcast requests for this interface. Before controlling, read the block and confirm application=4 (CHECKWEIGHER), channel and snapshot validity.

Addresses below are zero-based PDU addresses. For clients using 4xxxx notation, reference = 40001 + address: address 400 is 40401 and address 480 is 40481. Use function 03 (or 04) to read. Write commands only with function 16 (0x10), starting at 480 and writing exactly eight registers. Function 06 and partial writes are rejected. Result/status registers are read-only. The gap between the read and write blocks is not readable.

Read address 400, count 48 to obtain status, command acknowledgement and the last result in one request. Alternatively read 400/count 24 for status or 424/count 24 for the result. All 32-bit values use the high word first; each register uses the standard Modbus high-byte-first order. Do not split a 32-bit value across separate requests.

Status and the last result are copied under the process lock. Each response contains a consistent snapshot; a subsequent request may see newer data. RESULT_SEQ, RESULT_ID, DECIMALS and UNIT belong to the stored result, not to the currently selected recipe. Before the first result, flags bit 0 is clear: do not interpret the zero-filled result fields as a real zero-weight product. Reading never consumes or clears a result.

Example: W high=0x0000, low=0x07D1 gives signed integer 2001. With DECIMALS=1 and UNIT=0 the mass is 200.1 g. Negative values use 32-bit two’s complement. If conversion exceeds INT32 or the scale value is not representable, the corresponding validity bit is clear, its numeric registers are zero, and flag bit 3 is set. The original product result is not changed.

For COMMAND 2, 3 or 4, CHANGE_MASK, RECIPE_ID and AUTOSTART must all be 0. Settings may be combined with COMMAND 0 or 1. Recipe selection and autostart changes require a stopped, drained process. START without the recipe-change bit starts the currently selected recipe. Application selection and recipe creation remain outside Modbus scope.

The complete frame is validated before it is accepted. No partial control-block writes take effect. A normal function-16 response means the request was accepted into the mailbox, not that START succeeded. Execution occurs from the existing main loop. Poll until ACK_ID equals the submitted ID and COMMAND_STATE is DONE or ERROR. BUSY may be too brief to observe; never require observing it before accepting DONE.

Keep one request outstanding. If the write times out, reread BOOT_ID, REQUEST_ID and ACK_ID. If the boot token is unchanged, retransmit exactly the same eight words if necessary. A repeat of the most recently accepted request with identical data is acknowledged without executing it again, whether pending or completed. The same ID with changed data, skipped/old IDs, a different boot token, or another request while BUSY is rejected. After a reboot, resynchronise with the new token and current process state; do not automatically replay an old START.

Only the latest request is retained for duplicate detection; there is no persistent command journal. A network restart without a device reboot does not clear the mailbox. This protocol assumes one controlling PLC; it does not arbitrate competing writers. The boot token and request counter prevent accidental replays, not unauthorised access.

Recipe selection is applied first, autostart second, and the command last. Syntax, ID range and recipe validity are checked before setting changes. Flash errors can still leave an earlier setting applied. APPLIED_MASK reports exactly which requested settings succeeded. For example, recipe 25 and AUTOSTART=1 may be saved while START is refused because CONS is inactive: COMMAND_STATE=ERROR, COMMAND_ERROR=11, APPLIED_MASK=3. Settings are not rolled back. Read back ACTIVE_ID and AUTOSTART before deciding what to retry.

The error codes below belong to COMMAND_ERROR and must not be confused with process/product error fields. A rejected transport-level write does not change the mailbox or ACK_ID. Illegal addresses, read-only writes, partial writes and unsupported block ranges return Modbus exception 02. A correctly addressed eight-word control write with invalid data, token, sequence or mailbox state returns exception 03.

STOP DRAIN accepts no new products and finishes accepted products and output events. Its DONE acknowledgement means the stop was requested; STATE=5 confirms completion. STOP NOW cancels open products/events and deactivates process outputs. STOP is not a substitute for RESET in a blocking fault. RESET rechecks the scale and prerequisites and does not start the belt; if the cause remains it fails. All commands use the normal checkweigher interlocks. A result is a measurement outcome, not confirmation that a physical reject actuator operated.

AUTOSTART is the persistent CWAUTO setting, default 0. Enabling it does not start immediately; combine with COMMAND=1 for an immediate START. At the next device boot, application CHECKWEIGHER must be selected, initial zeroing enabled and successful, and a valid last active permanent recipe available. Normal START checks still apply. A failed boot attempt is not retried when an input later changes. Manual STOP, PAUSE or faults do not trigger automatic restart. Unchanged values do not cause another settings write.

AUTO_STATE: 0 DISABLED; 1 WAIT_ZERO; 2 ZERO_DISABLED; 3 ZERO_FAILED; 4 NO_PRODUCT; 5 STARTED; 6 START_FAILED; 7 CANCELLED; 8 INACTIVE; 9 INIT_FAILED. AUTO_ERROR is the rejected boot START code. This is the outcome of the boot attempt; STATE and PROCESS_ERROR describe the current process.

Example 1 — read everything: function 03, PDU start=400, count=48 (reference 40401). Verify MAP_VERSION=1, APPLICATION=4 and SNAPSHOT_VALID=1. Save BOOT_ID and ACK_ID. No command is needed to read data.

Example 2 — select recipe 25, enable autostart and START in one write. Assume BOOT_ID=0x12345678 and ACK_ID=0. Write function 16, PDU start=480, count=8 with decimal words: [1, 3, 25, 1, 0, 1, 4660, 22136]. The boot words are illustrative: always copy them from the device. Wait for ACK_ID=1 and COMMAND_STATE=2, then verify STATE=2 (RUN). If COMMAND_STATE=3, inspect COMMAND_ERROR and APPLIED_MASK.

Example 3 — STOP DRAIN. Assuming the previous request completed, submit [2, 0, 0, 0, 0, 2, 4660, 22136]. Wait for ACK_ID=2. DONE confirms acceptance; continue polling until STATE=5 (STOPPED). Pending products may still produce results while DRAINING.

Example 4 — change only the recipe, once stopped: [0, 1, 26, 0, 0, 3, 4660, 22136]. This leaves autostart unchanged and does not start. Start later with [1, 0, 0, 0, 0, 4, 4660, 22136].

Example 5 — reset a corrected fault: COMMAND=4 with mask/recipe/autostart=0, next request ID and current BOOT_ID. Wait for a successful acknowledgement; issue a separate START if required. Do not send RESET repeatedly without diagnosing the fault.

Suggested cyclic PLC logic (Structured Text pseudocode; adapt Modbus block names to your PLC):

ReadHoldingRegisters(Start := 400, Count := 48, Data := Rx);
BootId := JoinUInt32(Rx[1], Rx[2]);
AckId := JoinUInt32(Rx[18], Rx[19]);
IF BootId <> SavedBootId THEN
    SavedBootId := BootId; HaveSeenResult := FALSE;
    (* Resynchronise command handling; do not replay old START. *)
END_IF;
IF (Rx[15] = 1) AND ((Rx[27] AND 1) <> 0) THEN
    Seq := JoinUInt32(Rx[24], Rx[25]);
    IF NOT HaveSeenResult OR (Seq <> SavedSeq) THEN
        SavedSeq := Seq; HaveSeenResult := TRUE;
        IF ((Rx[27] AND 2) <> 0) AND (Rx[29] <> 65535) THEN
            Mass := SignedInt32(Rx[30], Rx[31]) / Power10(Rx[28]);
        END_IF;
        Samples := Rx[40]; ProductResult := Rx[38];
        (* Process this snapshot once, including invalid/rejected products. *)
    END_IF;
END_IF;

NS refers to the last completed product and is unchanged until a new result arrives. A last-result register block is not a queue: if two products finish between polls, the intermediate result is not retrievable through this basic map. Monitor SEQ changes and choose a poll interval below the shortest product interval. After reconnecting, decide whether the first available result should be recorded as a recovered snapshot or used only as the initial baseline. This interface does not guarantee an audit trail for every product.