Connecting fanuc-driver to NCGuide simulator (standard install, no NCGuide-Pro / NCGuide_COMM license)

[sencelik]

TL;DR

fanuc-driver can be made to work against the standard NCGuide simulator on the same Windows host as the driver, using cnc_allclibhndl2(node=9) and fwlibNCG64.dll instead of cnc_allclibhndl3 over TCP. This bypasses the EW_MMCSYS error that standard NCGuide returns for any FOCAS-over-Ethernet connection attempt. 22 of 28 commonly-used FOCAS calls work on a vanilla NCGuide install.

I've also put together a small Python HTTP proxy that exposes the working FOCAS calls as JSON endpoints — that way VMs / remote hosts can poll a real NCGuide simulator without needing a licensed network bridge.

Background — why this needs documenting

The repo bundles fwlibNCG.dll and fwlibNCG64.dll (the NCGuide-specific FOCAS plugins) but the docs, issues, and discussions don't mention NCGuide once. There's no example, no config snippet, no troubleshooting note. The natural assumption — ip: localhost, port: 8193 in config.machines.yml — fails with EW_MMCSYS (-15) against a running NCGuide simulator, regardless of:

• which controller variant (tested FS30i-B, FS30i-B Plus)
• which DLL (NCGuide's bundled Fwlib32.dll, this repo's Fwlib64.dll)
• which port (8193..8196)
• which IP (loopback, host IPv4)
• which OS privilege level (normal, elevated)
• whether NCGuide_COMM SettingManager.exe is launched

So I spent some time figuring out why, and what actually works.

Root cause

Standard NCGuide does not implement FOCAS2/Ethernet on TCP 8193. The port listens, completes the TCP 3-way handshake, but resets the connection as soon as it receives anything that looks like a FOCAS preamble. NCGuide-Pro / NCGuide_COMM are the licensed Fanuc products that add real network FOCAS — standard NCGuide only supports in-process IPC via shared memory + global mutexes + a named pipe (\\.\pipe\CNCGUIDE1).

The IPC objects Simbase exposes are all accessible at normal user privilege:

• Shared memory: FanucFocas1ProcCommonVarMap (4 KB)
• Mutexes: Global\Fanuc300iLibMutex_0_0_{0,1,2}, FanucPmcLibGeneralMutex_0_0, FanucPmcLibWindowMutex_0_0
• Named pipe: \\.\pipe\CNCGUIDE1

fwlibNCG64.dll is the loader that knows how to use them. It exports cnc_allclibhndl and cnc_allclibhndl2 — but not cnc_allclibhndl3 (the TCP one). That alone tells you the design intent: NCGuide's FOCAS surface is HSSB-style local IPC only.

What works

import ctypes
from ctypes import c_short, c_ushort, byref

fw = ctypes.WinDLL("fwlibNCG64.dll")
fw.cnc_allclibhndl2.argtypes = [c_short, ctypes.POINTER(c_ushort)]
fw.cnc_allclibhndl2.restype  = c_short

h = c_ushort(0)
rc = fw.cnc_allclibhndl2(9, byref(h))   # <-- node = 9
# rc == 0, h.value == 1 (valid FOCAS handle)

The node argument is 9 against a default NCGuide install. I found this by brute-forcing -1..50 while Simbase was running; only 9 returned EW_OK, every other value returned EW_NUMBER (-3). The semantics of "node 9" appear undocumented in any FOCAS reference I could find — best guess: Simbase registers itself at a hardcoded HSSB slot index. (If anyone from Fanuc / a longtime user knows the actual reason, I'd love to learn it.)

FOCAS calls that work on standard NCGuide via this path

Tested against a default FS30i-B Plus install (series=G317, version=19.0, mt_type=M):

Working	Notes
cnc_sysinfo	series/version/type
cnc_statinfo	aut/run/motion/alarm
cnc_exeprgname	running program name
cnc_rdprgnum, cnc_rdseqnum	program + sequence number
cnc_rdspeed, cnc_actf, cnc_acts	commanded + actual feed/spindle
cnc_rdaxisname	axis name table
cnc_alarm, cnc_alarm2	alarm bitmap + code
cnc_modal	modal G-codes
cnc_rdparam	parameter read (any number)
cnc_rdmacro	macro variable read
cnc_rdsvmeter, cnc_rdspmeter	servo + spindle load meters
pmc_rdpmcrng	PMC R area bytes

Not working	Likely cause
cnc_absolute, cnc_machine, cnc_relative	EW_FORMAT (-2) — possibly struct packing / size arg
cnc_toolnum	EW_NOOPT (-6) — option not in standard NCGuide license
cnc_rdcncid	rc=1 — option-gated
cnc_rdopmsg	EW_FORMAT (-2)

So out of 28 calls I tried, 22 work. More than enough for the data Ladder99's FanucMachine strategy collects.

Reference implementation: HTTP proxy for VM clients

The catch with HSSB IPC is that it only works from a process running on the same Windows session as Simbase. To make a VM (or any remote tooling) consume the data, I put together a small http.server-based proxy:

GET /sysinfo  /status  /program  /feed  /axes  /alarm
GET /param/<n>     e.g. /param/3105
GET /macro/<n>     e.g. /macro/100
GET /pmc/R/<s>/<e> e.g. /pmc/R/0/15
GET /all           composite poll

It uses safe_call(...) with a single persistent handle + auto-reconnect on EW_RESET (-8). ~250 lines of pure stdlib Python, no extra deps. Happy to clean it up and PR it as examples/windows/ncguide-proxy/ if maintainers would find it useful — let me know if there's a preferred shape (Docker, batch script, etc.).

Suggestion for fanuc-driver

Two small, non-invasive things would help future users land on this path much faster:

1. Doc note under "installation-windows.md" — something like:

   "NCGuide simulator support: standard NCGuide does not serve FOCAS over TCP. To use this driver against NCGuide on the same host, see ."

2. NCGuide example config that wires FanucMachine to a local FOCAS handle obtained via cnc_allclibhndl2(node=9) rather than cnc_allclibhndl3 over TCP — could be a new transport selector or just a documented config preset.

I can put both of these together as a PR if there's interest.

What I'd love to know

• Does anyone here know whether node=9 is hardcoded by NCGuide, derived from the controller variant ID, or something a future Fanuc release might change?
• Has anyone gotten real (network) FOCAS working against NCGuide without the NCGuide_COMM / NCGuide-Pro license? Curious if there's a path I missed.
• Is there interest in folding this into the driver as a first-class "NCGuide local" transport, or is the HTTP proxy approach (separate process) preferred?

Thanks for the great work on this driver — the bundled DLL set saved me a lot of time even though the docs didn't cover the simulator case.