Series 199 PROFINET Explained: IRT Isochronous Synchronization and Device Name Assignment

The 199PROFINET series is Germanjet’s PROFINET fieldbus magnetostrictive displacement sensor, aimed at industrial-Ethernet sites built mainly on Siemens control systems. PROFINET has three real-time classes: non-real-time (NRT), real-time (RT) and isochronous real-time (IRT). IRT reserves fixed time slots for cyclic data through a pre-planned communication schedule, achieving highly deterministic synchronised transmission, suited to coordinated multi-axis motion. Measuring performance of 199PROFINET matches the rest of the range — absolute position output, resolution steps 1–100 μm, repeatability of the order of ±0.002 mm, typical non-linearity <0.02% FS.

The essential difference between RT and IRT

Item	RT real-time	IRT isochronous real-time
Scheduling	Priority tagging; transmission is seized by priority	Pre-planned time slots; cyclic data exclusively occupy reserved bandwidth
Determinism	Fair, but jitter exists	High; jitter is strictly limited
Topology requirement	Relatively loose	Must match the planned topology in the engineering configuration
Hardware requirement	Standard PROFINET device	Device and switch must support IRT
Configuration effort	Medium	High; topology planning and sync-domain configuration required
Typical use	General process data, status monitoring	Multi-axis coordination, high-dynamic position closed loop

The selection criterion is clear: if strict multi-axis synchronisation is not needed, use RT; use IRT only when it is needed. IRT brings determinism and also constraints — topology must be fixed and match the configuration; plugging into a different port may report a topology error. That is the most common IRT field cause of “it stopped working after we changed the wiring”. Basic concepts of IRT and device names are in PROFINET introduction: IRT and device-name assignment.

Device-name assignment: the PROFINET entry threshold

Unlike other Ethernet protocols that address by IP, PROFINET identifies devices at run time by device name; the IP address is assigned and downloaded by the controller at start-up. The engineering meaning of this mechanism is:

• A new device going live must first be assigned a device name, which must match the name in the configuration exactly (including case and separator rules), or the controller cannot find it;
• When replacing a device it is enough to write the device name into the new device; the configuration need not be changed — this is the PROFINET design for easier maintenance, provided the site knows the original device name;
• A duplicated device name causes an identification clash, as fatal as an IP clash.

In practice the device name should match the electrical-drawing tag (for example named by station or axis number) and a label should be fitted on the device. Going live on a “scanned default name” alone makes later maintenance very confused.

GSDML and the configuration flow

The description file for a PROFINET device is GSDML (XML format), with stronger descriptive capability than a Profibus GSD. A typical configuration flow: import GSDML → add the device in hardware configuration → assign device name and IP → configure modules and I/O data → (if needed) plan topology and sync domain → download and start.

Three easy mistakes:

First, GSDML version does not match firmware. The symptom is missing module options or a parameter error after the configuration is downloaded.

Second, I/O data length does not match reality. The byte count of the position value, and whether a status word is included, must match the configuration, or the data that are read will be misaligned.

Third, IRT topology does not match the actual wiring. After topology is planned, any port swap triggers a topology diagnostic alarm. A wiring change must be accompanied by a configuration change. PROFINET diagnostics and topology identification are in PROFINET diagnostics and the truth about topology.

What IRT isochronous synchronisation means for displacement measurement

The value of IRT appears in multi-axis systems: position acquisition and control output of the axes are placed in fixed time slots on the same time base, so the multi-axis data the controller receives represent the system state at the same instant. Without synchronisation, axis data are scattered at different instants within the cycle; in high-dynamic motion the inter-axis deviation that is then calculated already contains error, and synchronised-control accuracy is limited.

The same physical boundary applies: bus synchronisation cannot remove the sensor’s own measuring delay. The magnetostrictive update rate depends on torsion-wave travel time; the longer the measuring range, the slower it is — typically about 0.5 ms to 5 ms, depending on measuring range. A multi-axis synchronised system should therefore as far as possible choose sensors of similar measuring range, and confirm that the bus cycle is not shorter than the sensor update rate — a cycle set shorter than the update rate will only repeatedly read the same value. Matching methods are in How to match response time / refresh rate to the control cycle; multi-axis configuration is in Selecting for multi-axis synchronisation.

Where 199PROFINET is suitable

New Siemens-system lines. The controller is an S7-1200/1500, the network backbone is PROFINET, the sensor joins directly, no gateway is needed, and engineer familiarity is high.

Lines that need to fuse with the upper IT network. PROFINET is based on standard Ethernet, so it is convenient to share a segment with MES and data-acquisition systems or to interconnect through a switch, suiting digital-conversion projects.

High diagnostic demand. PROFINET supports rich diagnostic alarms and topology identification, locating to a specific port; fault-finding efficiency is higher than with a conventional fieldbus.

Lines upgrading from Profibus. When an existing Profibus network (see Series 195 Profibus explained) migrates to Ethernet, PROFINET is the smoothest path within the same system.

Choosing against EtherCAT

Dimension	PROFINET (199PROFINET)	EtherCAT (197 / 198)
Ecosystem	Mainly Siemens systems	Beckhoff systems and a wide range of third-party masters
Description file	GSDML	ESI (XML)
Device addressing	Device name + controller-assigned IP	Physical position (series order)
Synchronisation	IRT time-slot reservation	DC distributed clocks
Network hardware	IRT-capable switch required	Slaves forward themselves; no switch needed
Topology flexibility	Star/tree supported; must be fixed under IRT	Mainly linear series
Reason to choose	Consistent with the existing Siemens control system	Shortest cycle and strongest real-time performance

The decision principle is not which protocol is more advanced, but follow the master system. Whatever the master is, that is what the sensor should be; adding a gateway across systems only adds a fault point. On the EtherCAT side see Series 197 EtherCAT explained and Series 198 single M12 explained; the full trade-off among the four fieldbuses is in Comparing the whole fieldbus range. Product pages: 199PROFINET series, Series 197 EtherCAT, Series 194 CANopen. General fieldbus wiring points are in Fieldbus practical guide.