How to collect Fanako CNC data from industrial intelligent gateways

• 1
  Key takeaways
• 2
  What data a Fanako control actually gives you
• 3
  Gateway features that decide whether the pilot survives
• 4
  Wiring and network layout for the shop floor
• 5
  Tag mapping and naming that survives a machine swap
• 6
  Common failures and how to avoid them
• 7
  How to collect Fanako CNC data, step by step
• 8
  Which connection path fits your machine

Fanako-class CNC controls do not hand out one tidy data stream. They expose a set of registers, and what you read depends on which ones the machine builder enabled. On a typical machining center you can get spindle speed and load, axis positions, feedrate override, program number, active tool number, run status, alarm codes, and part counters. Some builders also publish servo temperature and lubrication pressure.

The practical limit is the communication option. Older machines ship with RS-232 or a 10/100 Ethernet port and a FOCAS library. Newer ones may have an OPC UA server as a paid option. If your machine has neither, you are looking at a hardware signal tap on the I/O board, which is a different project with a different budget.

Before you write any code, get the parameter list from the machine builder or the control manual. Write down the address of every tag you want, its data type, and its unit. This one-page table saves days later, because the gateway configuration is only as good as that list.

• 1
  Read-only firstCommand writes back to the control need a separate safety review. Get monitoring working before you attempt remote start.
• 2
  Watch the unitsSpindle load may come back as a percentage, a raw count, or amps. Record which one.
• 3
  Check the firmwareOlder FOCAS versions cap how many tags you can read in one call. The manual lists the limit.

An industrial intelligent gateway sits between the machine network and your plant network. Its job is to poll the controls, normalize the values, and push them upstream in a format your MES or historian understands. The feature list on a datasheet is long, but only a few items change the outcome of a project.

Protocol support comes first. The gateway must speak the control protocol natively on one side and something your IT team accepts on the other, usually OPC UA, MQTT, or a REST endpoint. A gateway that only supports Modbus TCP forces you to buy a protocol converter for every Fanako machine, which doubles the cabinet space and the failure points.

Second is local storage. Machines run through shift changes, network switches reboot, and the plant VLAN gets reconfigured. A gateway with a few gigabytes of flash can hold days of buffered samples and replay them when the link comes back. Without that buffer, a five-minute outage becomes a five-minute hole in your cycle-time data.

Third is the polling engine. You want per-tag scan rates, not one global rate. Status bits at 1 s, counters at 60 s, and alarm words at 500 ms is a normal split. A gateway that forces a single rate makes you choose between network load and missed events.

• 1
  Native control protocolNo external converter in the cabinet.
• 2
  Per-tag scan ratesFast for status, slow for counters.
• 3
  Edge bufferingStore and forward across network drops.
• 4
  Timestamp at sourceGateway time, not server time, or your sequence analysis breaks.

Keep the machine network separate from office traffic. A managed switch on the cell, a gateway with two Ethernet ports, and a single uplink to the plant backbone is enough for most shops. The gateway should sit on the machine side, not behind a firewall rule set that IT changes every quarter.

Use shielded Cat 5e or Cat 6 cable for runs inside the cabinet and keep it away from spindle drive cables. A 24 V servo cable running parallel to a network cable for three meters will inject noise that shows up as CRC errors and dropped polls. If you must cross a drive cable, cross at 90 degrees.

For RS-232 machines, keep the run under 15 m at 19,200 baud. Longer runs need a converter to RS-485 or fiber. Terminate the far end properly and check the ground reference between the control and the gateway. A floating ground is the most common cause of intermittent communication alarms.

Label every port. In a shop with 40 machines, a mislabeled patch cable costs an afternoon of debugging that nobody budgets for.

The gateway configuration is where most projects quietly fail. Every tag needs three things: a source address, a normalized name, and a unit. If you name tags after the machine, such as MC04_SPINDLE_LOAD, replacing that machine next year forces a rewrite of every dashboard.

Name tags after the function instead: CNC_SPINDLE_LOAD, CNC_CYCLE_COUNT, CNC_ALARM_CODE. Store the machine identity as a separate field. Then a new machine is a configuration change, not a software project.

Decide early whether you push raw values or computed ones. Raw values keep the gateway simple and let the historian do the math. Computed values reduce bandwidth but hide the inputs when someone questions a number six months later. For a first project, push raw.

Scale and deadband matter. A spindle load that jitters by ±0.5 percent every second will fill your database with noise. Set a deadband of 1-2 percent on analog values and publish only on change. Digital status bits should publish on every transition, not on a timer.

• 1
  Function-based namesCNC_SPINDLE_LOAD, not MC04_SPINDLE_LOAD.
• 2
  Machine ID as a fieldSwapping a machine becomes a config edit.
• 3
  Publish on changeDeadband 1-2 percent on analog tags.
• 4
  Keep raw valuesCompute downstream so the inputs stay auditable.

The most frequent failure is polling too hard. A gateway configured to read 200 tags every 100 ms can saturate a control's communication task and trigger a communication alarm mid-cut. Start at 1 s for status and 60 s for counters. Watch the control for a week before you tighten anything.

The second is time. If the gateway stamps samples with its own drifting clock and the historian stamps them again on arrival, your event sequence becomes unreadable. Run NTP on the gateway and keep the source timestamp in the payload. Never let two systems both claim to be the time authority.

The third is scope creep in the tag list. Teams start with run status and part count, then add 80 more tags before the pilot is stable. Each added tag is another scaling decision and another chance to misread the manual. Lock the list for the pilot, get it right, then expand.

Finally, do not put the gateway on the office VLAN through a firewall rule that nobody owns. Machine data is operational traffic. Keep it on the machine network with one documented uplink, and document who can change that uplink.