Syntec CNC over Ethernet: RemoteAPI v4 DLLs in 32-bit PowerShell; the v2 kit returns NOTREADY/CNCBusy forever

Collecting state, running program and part counts from a shop's Syntec milling controllers (220-series) to a Windows PC on the same LAN.

In the maintenance menu, open Network settings and find the "core server" option (localized name). Set "start server at power-on" to ON and confirm. That only takes effect at the next power-on, so you must also press "start server" to run it now. The controller then listens on ports 5566/5568/5570/5572, plus a few others. OPC UA on these models is a paid option, so the RemoteAPI is the free path.

• Use the v4 RemoteAPI kit (Syntec.RemoteCNC.dll plus the native OCAPI.dll). With the older v2 kit the connection succeeded, but every read returned NOTREADY/CNCBusy indefinitely.
• OCAPI.dll is 32-bit native, so the host process must be 32-bit: %SystemRoot%\SysWOW64\WindowsPowerShell\v1.0\powershell.exe or an x86 .NET exe. Mono on macOS failed loading it.
• Find controllers by MAC prefix in the ARP table after a ping sweep (Syntec OUI, e.g. f8:46:2d), so DHCP renumbering doesn't matter.

Reading all machines in parallel (one 32-bit process each) starved the readers and produced false "hung" verdicts. What worked was one serial reader that writes each result as it finishes. A supervisor kills the reader if one IP takes more than 15 s, rests that machine with an escalating back-off, and relaunches for the rest.

Model, software version, main program, mode, READY/START state and total parts were read in about 264 ms per machine. With the serial reader, 14 of 16 controllers reported live (up from 5 of 12 with parallel reads), and the cutting state matched machines seen running.