How Do SINUMERIK 840D sl TCU Network Transfers Work?

The correction file works on Windows-backed machines, but a TCU-based SINUMERIK 840D sl cannot expose its CompactFlash user storage as an ordinary writable Windows share. The commissioning decision is therefore architectural: write into the NC filesystem through the supported remote-transfer path, or place the file on a shared NAS and let SINUMERIK Operate read it as a logical network drive.

1. TCU and PCU architecture

A TCU is not a replacement Windows file server. It presents the HMI running on the NCU through VNC, so connecting a TCU does not create a general-purpose disk that another computer can browse and modify. This differs from the existing machines, where the background Windows computer was joined to the company network and selected folders on its hard disk could be shared.

The term logical drive here means a storage location that SINUMERIK Operate can access. It does not mean that Operate publishes the NCU CompactFlash card or an attached USB device as a writable Windows network share. Creating CompactFlash user storage or configuring USB as global storage therefore does not, by itself, solve inbound access from the measuring computer. Publishing either medium would require a network file-server service that this configuration does not provide.

Check 1: Identify where Operate actually runs. Expect the TCU to act as the display terminal and the NCU to own the HMI and NC-accessible filesystem. If a Windows PCU is present, document it separately rather than applying the TCU path.

2. Transfer-path selection

Select the route according to the required failure behavior. The production requirement is to update Correctionfile.spf from quality assurance while avoiding dependence on a central server. The existing process reads that correction data on every program cycle, approximately every four minutes.

Direct transfer removes the NAS dependency but grants a remote system write access to an active NC filesystem. Restrict the destination and credentials to the correction-file workflow. The NAS route preserves the familiar shared-folder model and was demonstrated with a NAS Ethernet adapter connected to the cabinet switch.

Check 2: Disconnect the central server logically from the proposed data path. Expect either the NCU itself or the local NAS to retain the correction file and remain reachable by both endpoints required for production.

3. Network-interface assignment

The installation used NCU interfaces X130 for the company LAN/PN/IE network and X120 for the operator-panel network. Remote file transfer belongs on the interface connected to the authorized external computer. In this arrangement, that interface is X130.

Before changing the firewall, record the NCU address, subnet, route, target interface, and the measuring-computer address. A successful ping alone proves IP reachability, not that the file-transfer service is open or authenticated. Conversely, an unavailable service on port 22 should not be diagnosed as a file-path error until interface reachability and firewall state have been checked.

1. Confirm that the measuring computer reaches the NCU address through the network attached to X130.
2. Confirm that X120 remains assigned to the operator-panel side rather than being treated as the company-network transfer path.
3. Record whether a hostname or a fixed IP address will be used. If a hostname is chosen, verify its resolution from the sending computer before testing SFTP.

Check 3: From the authorized sending computer, expect the configured NCU address to resolve to the X130 network and remain stable. A response from another interface or host is a addressing fault that must be corrected before opening a service.

4. SSH port activation

With SINUMERIK 840D sl CNC software 4.7 SP1 HF4, the cited behavior states that the firewall blocks SSH port 22 on X130 by default from software 4.7 SP1. This prevents external access used by tools such as WinSCP and Access MyMachine, as well as some Operate-on-PCU/IPC/PC functions.

1. Open SINUMERIK Operate on the NCU.
2. Navigate to Commissioning > Network > Company network > Change.
3. Activate the checkbox labeled SSH (TCP/22).
4. Apply the configuration and return to the network view to confirm that the setting remains active.

Opening port 22 exposes the transfer service; it does not create a Windows SMB share. Windows Explorer therefore cannot browse the NC program directories as though they were shared folders. Use compatible transfer software. The documented choices in this installation were WinSCP, PuTTY command-line tools, or Access MyMachine. FileZilla was unsuitable for the described connection because the session authenticated through SFTP and then used a protocol fallback that the client did not handle.

Check 4: Attempt an authenticated connection to the NCU address on TCP port 22. Expect an authentication prompt or successful session, not a timeout or connection refusal. Do not proceed to file-path troubleshooting until this check passes.

5. NC program-directory targeting

The NCK filesystem appears as a directory tree on the CompactFlash card and exposes NC program locations. The demonstrated upload target for a subprogram was /nckfs/_N_SPF_DIR/. A Linux example copied a file with:

scp meineDatei manufact@meinemaschine:/nckfs/_N_SPF_DIR/meineDatei

A Windows PuTTY example used:

pscp.exe -pw CUSTOMER _N_TEST1_SPF [email protected]:/nckfs/_N_SPF_DIR/_N_TEST1_SPF

These are syntax examples, not installation-ready credentials or addresses. The examples contain different user names, and 192.168.215.1 is only the address shown in the command example. Insert the account, password, source filename, and NCU address assigned to the commissioned machine. The sample password token is CUSTOMER; placing a password directly on a command line can expose it to process listings, logs, macros, and command history, so use the credential-handling facility approved for the production computer.

Linux paths and filenames are case-sensitive. Treat Correctionfile.spf, CORRECTIONFILE, and NC-formatted names such as _N_TEST1_SPF as distinct representations until the actual target directory shows how Operate stores the file. Do not silently change underscores, capitalization, or the destination directory in an automation script.

Check 5: Upload a non-production test subprogram and list the contents of /nckfs/_N_SPF_DIR/ with the same client. Expect one file at the intended path with the transmitted size, capitalization, and modification time.

6. Direct-transfer automation

The measuring workbook generates fine-correction variables and writes them to Correctionfile.spf. Its automation must perform more than launching a transfer process: it must generate a complete file, send it to the correct destination, capture the client's exit status, and prevent a partially written file from becoming the next program input.

1. Generate the correction content in a local temporary file and close the file handle before transfer.
2. Validate the generated content against the expected variable-only structure. Reject an empty file, malformed line, unexpected program statement, or value outside the process limits defined for the machine.
3. Transfer under a temporary remote name in the same target filesystem when the selected client and NCU workflow support it.
4. Verify successful completion and compare the remote file size with the local file size.
5. Promote the completed temporary file to the production filename using a tested same-filesystem operation. Do not overwrite the active correction file incrementally while the NC may open it.
6. Write a transfer record containing the timestamp, target machine, result, and file identity without recording the password.

The direct-write method can be tested while the machine is running because successful transfer is visible immediately in the destination. Testing program execution or replacing the live correction file is a separate commissioning action. First prove transport with a harmless test name; perform the live change during the production-approved window.

If the workbook invokes pscp.exe, build the command using the PuTTY syntax shown above: options precede the source, and the remote specification has the form user@host:/path/file. A generic SFTP example that supplies -l, -pw, and a separate host:path layout must be reconciled with the actual executable rather than copied untested.

Check 6: Run the automation with a test filename. Expect a success exit status, an audit record naming the intended NCU, and an exact remote size match. Force one bad password or unreachable address in the test environment and expect the workflow to reject the update rather than report success.

7. NAS logical-drive configuration

The demonstrated interim design connected a Digitus NAS Ethernet adapter to the cabinet switch. Its fixed address was 192.168.55.65, and the shared folder was NASC4. Both the measuring computer and the machine accessed that local device, avoiding storage on the central server.

1. Create or select the NAS folder that will contain Correctionfile.spf.
2. In SINUMERIK Operate, open HMI > Logical drives.
3. Create an NW Windows drive.
4. Enter the demonstrated share path as //192.168.55.65/NASC4, substituting the commissioned NAS address and share name where they differ.
5. Activate the logical drive after entering the network path.
6. From Operate, browse the logical drive and confirm that the file is visible.

A commissioning access level may be required to edit the logical-drive configuration. The password CUSTOMER was suggested for the demonstrated configuration, but the correct authorization for a machine must come from its active access-level setup. The configuration data may also be represented in logdrive.ini under the CompactFlash user area; inspect it only when the Operate configuration does not produce the expected drive, and preserve the existing configuration before changing it.

Check 7: Create a test file from the measuring computer in the NAS share, then refresh the logical drive in Operate. Expect the same filename and size without copying it manually at the control.

8. EXTCALL path and invocation

For the NAS route, channel setting data 42700 | $SC_EXT_PROG_PATH defines the external-program search path. The working configuration used:

\192.168.55.65	tNASC4

The intended value is the UNC path with the share name NASC4:

\192.168.55.65\NASC4

The first displayed form above contains a transcription artifact before NASC4; enter the normal UNC form shown in the second block and verify it at the control. Keep this channel setting aligned with the logical-drive target. A reachable logical drive does not prove that EXTCALL searches the same directory.

Store Correctionfile.spf in that share and call it from the running NC program as:

EXTCALL("CORRECTIONFILE")

Omit the extension in the call. Do not append .spf or .mpf. With direct upload into the active SPF directory, the correction routine may be invoked as an NC subprogram without the external network path; the exact program call must match the name shown by the NC program manager.

1. Set $SC_EXT_PROG_PATH to the commissioned UNC share.
2. Place a test .spf file in the share.
3. Call the test program with EXTCALL and no extension.
4. Confirm that the NC resolves the intended file rather than an older program of the same base name in another search location.

Check 8: Execute a harmless test subprogram from the NAS. Expect the called file to run from the configured share with EXTCALL written without an extension. A file-visible but program-not-found result points to the channel path or naming, not basic NAS reachability.

9. End-to-end production verification

The final test must prove data generation, transport, name resolution, NC execution, and server-outage independence as separate observations. Use a correction value that is unmistakable in the program data but remains within the approved process envelope. Do not infer successful execution merely because the remote file timestamp changed.

1. Check 9.1 — Generation: Change one approved test input in the measuring workbook. Expect a newly generated Correctionfile.spf containing the corresponding variable value and no partial final line.
2. Check 9.2 — Transfer: Run the selected SFTP or NAS workflow. Expect the destination file's size and modification time to match the completed local output.
3. Check 9.3 — Resolution: View the destination from the control. Expect the file under /nckfs/_N_SPF_DIR/ for direct transfer, or on the configured NW Windows drive for the NAS route.
4. Check 9.4 — Invocation: Run the controlled test call. Expect EXTCALL("CORRECTIONFILE") to resolve the NAS-hosted SPF without an extension, or expect the installed NC subprogram to resolve through its validated local call.
5. Check 9.5 — Consumption: Read back the affected NC variable or approved diagnostic indication after the call. Expect the new test value, not merely a successful transfer message.
6. Check 9.6 — Failure handling: Block the chosen transfer path in the test arrangement. Expect the automation to retain the last valid production file, report failure, and avoid publishing an incomplete replacement.
7. Check 9.7 — Server independence: Make the central server unavailable while leaving the NCU or local NAS path active. Expect generation and transfer components that were deliberately kept local to continue without referencing the server.
8. Check 9.8 — Cycle boundary: Observe two consecutive program cycles; the installation's normal interval is approximately four minutes. Expect each cycle to consume one complete correction-file revision, with no mixed or truncated content.

FAQ