Skip to main content
Siemens · Technical Blog

Siemens PLC and VFD Networking: Every Way to Connect a Drive

Hardwired, USS, Modbus, PROFIBUS or PROFINET — how each one works, what it carries, and how to exchange PZD data without a single %IW or %QW address.

2,500+ engineers trained 4.9/5 Google rating 21+ years, Chinchwad, Pune Next batch: contact for dates
Quick answer

A PLC can control a VFD by hardwired I/O, by a serial protocol (USS, Modbus RTU), or by a fieldbus or Industrial Ethernet telegram (PROFIBUS DP, PROFINET IO, Modbus TCP). Network methods exchange PZD process data — control word, setpoint, status word, actual value — every bus cycle. You do not need %IW and %QW addresses to reach that data: DPRD_DAT and DPWR_DAT exchange the whole telegram using the submodule's hardware identifier, library blocks such as SINA_SPEED take the same identifier, and USS or Modbus keep their data in data blocks with no I/Q addresses at all.

  • Hardwired control carries a few signals; a telegram carries the whole drive.
  • PZD is cyclic and belongs to run, stop and speed; parameters are acyclic and belong to commissioning values.
  • The hardware identifier replaces the address and gives consistent access to the whole telegram.
  • Whatever the path, the drive still sees the same STW1 and ZSW1 bits.

How to Network a Siemens PLC and a VFD

To network a Siemens PLC with a VFD you choose one of four methods: hardwired I/O, serial USS or Modbus RTU over RS-485, PROFIBUS DP, or PROFINET IO. For a SINAMICS drive on a new machine, PROFINET with Standard Telegram 1 is the default: the PLC writes a control word and a speed setpoint every bus cycle and reads a status word and the actual speed back. Everything below compares the methods, then shows how to reach that data in the program — including without %IW and %QW addresses.

Four Ways a PLC Talks to a VFD

Every method below ends at the same place — the drive's control and status information — but they differ enormously in how much they carry and what they cost to wire.

Hardwired I/OPLC sideDI/DO + analog 0–10 V or 4–20 mAVFDSINAMICS / any driveOne cable pair per signal, one drive per set of I/ODO → run · AO → speed · DI ← running · AI ← speedSerial: USS or Modbus RTUPLC sideRS-485, one master, several drivesVFDSINAMICS / any driveCheap, slower, needs instruction blocksControl word · Setpoint · Status word · Actual valuePROFIBUS DPPLC sideRS-485 fieldbus, polled by the masterVFDSINAMICS / any driveTelegram-based, drives appear as slavesSTW1 · NSOLL · ZSW1 · NISTPROFINET IOPLC sideIndustrial Ethernet, cyclic each send clockVFDSINAMICS / any drive Telegram-based, best diagnosticsSTW1 · NSOLL · ZSW1 · NIST
From top to bottom: more data, fewer cables and better diagnostics. The signals in the right-hand column are what the PLC actually exchanges.

What Each Method Can and Cannot Do

MethodWhat the PLC can doWhat it cannot doWiring per drive
Hardwired DI/DO + analogStart, stop, direction, speed setpoint, a few status signalsRead fault numbers, change parameters, see actual currentOne pair per signal — typically 6 to 10 cores
Serial: USSStart, stop, speed, status, actual values, parameter read/writeFast updates; the bus is polled in sequenceOne RS-485 pair for up to 16 drives on the bus
Serial: Modbus RTUSame as USS, using holding registersVendor diagnostics; speed is limitedOne RS-485 pair, multidrop
PROFIBUS DPFull telegram: control word, setpoints, status, actual values, acyclic parametersShare the cable with IT trafficOne DP drop per drive
PROFINET IOEverything above, faster, with topology and device replacement—One Ethernet cable per drive, line or star
Modbus TCP / EtherNet/IPRegister or assembly based control over EthernetPROFIdrive telegram features on Siemens drivesOne Ethernet cable per drive

Protocol Comparison

Read the table by the row that matters for your machine: reaction time, number of drives, or what the PLC must be able to read back. For a deeper look at the two fieldbuses see PROFINET vs PROFIBUS.

HardwiredUSSModbus RTUPROFIBUS DPPROFINET IO
MediumCopper per signalRS-485RS-485RS-485Ethernet
Typical speedInstant (analog)Up to 187.5 kbit/s9.6 – 115.2 kbit/sUp to 12 Mbit/s100 Mbit/s
Drives per line1Up to 16Up to about 30Up to 125 addressesLimited by the controller
Cyclic dataWired signals onlyControl + status wordsHolding registersTelegram PZDTelegram PZD
Parameter accessNoUSS parameter jobsRegistersPKW / acyclicAcyclic (index 47)
PLC blocks neededNoneUSS_Port_Scan, USS_Drive_ControlMB_COMM_LOAD, MB_MASTERStandard FB or SINA blocksStandard FB or SINA blocks
DiagnosticsWired fault relayStatus wordStatus registerSlave diagnosticsDevice and network diagnostics
Best forOne simple driveSmall machines, low costMixed-vendor drivesExisting PROFIBUS plantsNew machines and plants

Practise every method on real drives

Hardwired, USS, Modbus and PROFINET control of a SINAMICS drive from one PLC. Pune classroom or live online.

Book a Free Demo Class

PZD and Parameters: Two Channels

Any network connection to a drive carries two kinds of traffic. Mixing them up is the most common design mistake in drive programs.

Two data channels to the same drivePZD — cyclic process dataControl word, setpoint, status, actualPKW / parameters — acyclicRamp times, limits, fault bufferVFDDrive parameters and controlevery PROFINET cycle / bus cycle — a few msrequestresponseonly when the program asks — takes several cycles, never for fast controlRun, stop and speed always belong in PZD. Parameters belong in the acyclic channel.
PZD runs by itself every cycle; the parameter channel only answers when the program asks.
PZD — cyclicParameter channel — acyclic
CarriesControl word, speed setpoint, status word, actual valuesAny drive parameter: ramp times, limits, fault buffer
UpdateEvery bus cycle, a few millisecondsOn request, over several cycles
Triggered byNothing — it runs continuouslyA block call in the program
BlocksNone, or a mapping FBWRREC / RDREC, SINA_PARA
Use forRun, stop, speed, interlocksCommissioning values, recipes, diagnostics
Never use forWriting a parameter every scanStart, stop or speed control

The words inside PZD depend on the telegram — see G120 Telegram Selection in TIA Portal and STW1 and ZSW1 bit by bit.

PZD Without %IW and %QW

%IW and %QW are only one way into the process image. They are convenient for a two-word telegram, but they tie the program to addresses that move whenever the hardware configuration changes, and they read the telegram word by word. There are three routes to the same PZD data.

Three ways for the program to reach the same PZD wordsPLC programOB1 / FBProcess image%QW256 / %IW256ADirect addressesDPRD_DAT / DPWR_DATLADDR = HW identifierBData in a DBInstruction blockSINA_SPEED, USS, ModbusCData in its instance DBVFDPZD words: STW1, NSOLL, ZSW1, NISTAll three end at the same control and status words. Only path A needs %IW / %QW addresses in the program.
Path A uses absolute addresses; paths B and C use a hardware identifier or an instruction block, so the program never names an address.
MethodBlockKey input instead of an addressWhere the data livesWhen to use
Consistent telegram accessDPRD_DAT / DPWR_DATLADDR = hardware identifier of the telegram submoduleA DB structure you defineTelegrams longer than two words, or when you want no absolute addresses
Ready-made drive controlSINA_SPEED (DriveLib)HWIDSTW and HWIDZSW hardware identifiersThe block's instance DBStandard speed control on SINAMICS with telegram 1, 20 or 352
Parameter read/writeSINA_PARA, or WRREC / RDRECHardware identifier plus record index 47A request/response DBRamp times, limits, reading the fault buffer
Serial USSUSS_Port_Scan + USS_Drive_ControlPort hardware identifier and drive numberInstance and buffer DBsRS-485 drives — there are no I/Q addresses at all
Modbus RTU / TCPMB_MASTER / MB_CLIENTRegister address in the driveA DB arrayMixed-vendor drives

Paths B and C also solve data consistency. A telegram longer than a couple of words should be exchanged in one operation so that every word comes from the same bus cycle — that is exactly what DPRD_DAT and DPWR_DAT do.

The Hardware Identifier

The hardware identifier is the key to all of this. TIA Portal creates one for every module and submodule, including each drive telegram, and lists them in the System constants tab of the device properties.

Where the hardware identifier comes fromDevice overviewTelegram submodule of the driveSystem constantDrive_1~Standard_Telegram_1LADDR / HWID inputDPRD_DAT, DPWR_DAT, SINA_SPEEDTIA Portal creates one hardware identifier for every module and submodule. Find it in theSystem constants tab of the drive's properties, or type the name and let TIA complete it.The identifier replaces the address: the block reads or writes the whole telegram, consistently, wherever TIA Portal placed it
The same identifier serves DPRD_DAT, DPWR_DAT and the SINA blocks. If the addresses change, the identifier does not.

SINA_SPEED and Library Blocks

Siemens DriveLib blocks wrap the drive state machine so the program only supplies a run command and a speed. SINA_SPEED is the usual one for speed control; it takes the two hardware identifiers instead of telegram addresses.

SINA_SPEED inputMeaningTypical value
EnableAxisRun commandFrom the machine sequence
AckErrorFault acknowledge — edge triggeredReset pushbutton pulse
SpeedSpSpeed setpoint in rpmFrom the HMI
RefSpeedReference speed, must equal p20001500.0
HWIDSTWHardware identifier of the setpoint (Q) submoduleFrom System constants
HWIDZSWHardware identifier of the actual value (I) submoduleFrom System constants
ActVelocity (output)Actual speed in rpmTo the HMI
Error / Status (outputs)Block error and status wordTo diagnostics

A block of your own does the same job with less hidden behaviour and is easier to teach — see G120 PROFINET Standard FB, which maps the telegram bit by bit.

Serial Drives: USS and Modbus

On an RS-485 link there is no process image at all. The instruction blocks move the data between the communication port and data blocks, and the port itself is addressed by its hardware identifier. USS is the Siemens protocol and carries a control word and status word much like a telegram; Modbus RTU uses holding registers instead.

Typical G120 Modbus RTU registerDirectionContent
40100PLC → driveControl word (STW1)
40101PLC → driveSpeed setpoint, 16384 = 100 % of p2000
40110Drive → PLCStatus word (ZSW1)
40111Drive → PLCActual speed
4xxxx parameter registersBothIndividual drive parameters

Register numbers differ between drives and firmware versions, so always confirm them in the drive's Modbus register table before writing the program.

Acyclic Parameter Access

Ramp times, current limits and the fault buffer are parameters, not process data. They travel on the acyclic channel: the program sends a request, the drive answers over the next cycles.

Reading and writing drive parameters without PZDPLC programWants p1120 ramp timeWRREC / RDRECIndex 47, HW identifierParameter channelPROFIdrive requestDrive parameterp1120 = 5.0 sThe same route carries the answer back. SINA_PARA and similar library blocks wrap these steps.Acyclic access takes several cycles — never use it for run, stop or speed.
A parameter request goes out through the same connection as PZD but on its own channel, and returns over several cycles.

Choosing a Method

Choosing how to control the driveOne drive, simple start/stop and a speed pot?YESHardwired I/OCheapest, no programNODrive on a PROFINET or PROFIBUS network?YESTelegram + PZDStandard FB or SINA_SPEEDNOOnly an RS-485 port available?YESUSS or Modbus RTUInstruction blocks, DB dataNODrive on an Ethernet network without PROFINET?YESModbus TCPMB_CLIENT with registersNOCheck the drive manualEvery VFD lists the protocols it supports
Work down the questions; the first yes gives the method that fits the machine.

Pitfalls

PitfallWhat happensAvoid it by
Reading a telegram word by wordWords can come from two different bus cyclesUsing DPRD_DAT for the whole telegram, or a single consistent access
Writing parameters cyclicallyThe drive's memory wears and the bus load risesWriting once on a change, through the acyclic channel
Holding the fault acknowledge bit highA repeating fault is hidden and the motor keeps restartingSending a short pulse on the rising edge
Driving the HMI lamp from the run commandThe lamp lies when the drive is not runningUsing the status word bit for operation enabled
Mismatched reference speedSetpoint and actual speed are scaled wronglyMaking RefSpeed or your scaling equal p2000
Serial link too slow for the taskSpeed updates lag, interlocks react lateUsing a fieldbus where the reaction time matters

Step-by-Step Lab: One Drive, Three Methods

Hands-on
Before you start
  • An S7-1200 or S7-1500 with a SINAMICS G120 on PROFINET, Standard Telegram 1 configured, and a motor on a test bench.
  • The DriveLib library installed if you want to try SINA_SPEED.
  • Estimated time: 75 minutes.
1

Method A — absolute addresses

Write STW1 to the telegram Q word and read ZSW1 from the I word using PLC tags on those addresses.

On screen: watch table with the Q and I words in hexadecimal.
The motor starts on 16#047F and the status word changes. Note the addresses you used.
2

Find the hardware identifiers

Open the drive properties, System constants tab, and note the identifiers of the two telegram submodules.

You have two names such as Drive_1~Standard_Telegram_1 that TIA Portal completes automatically.
3

Method B — DPRD_DAT and DPWR_DAT

Create a DB with two words for send and two for receive, then exchange them with DPWR_DAT and DPRD_DAT using LADDR.

The drive behaves exactly as in step 1, but no %IW or %QW appears anywhere in the program.
4

Method C — SINA_SPEED

Call SINA_SPEED, wire EnableAxis, SpeedSp, RefSpeed and the two hardware identifiers.

The motor runs from a speed in rpm, and ActVelocity reports back without any bit mapping.
5

Change the address on purpose

In the Device overview, change the telegram start address and download again.

Method A stops working until the tags are corrected; methods B and C keep running.
6

Read a parameter acyclically

Read the ramp-up time p1120 with SINA_PARA or RDREC, then write a new value.

The value appears in the program and the drive ramps differently after the write.
Checkpoint — how to know you did it right

You have understood PLC to VFD communication if the same motor ran through three different program paths, if you can say why methods B and C survived the address change, and if you can name which data belongs in PZD and which belongs in the parameter channel.

Frequently asked questions

How do I network a Siemens PLC with a VFD?

Pick the connection the drive supports and the machine needs: hardwired I/O for a single simple drive, USS or Modbus RTU over RS-485 for low-cost serial control, PROFIBUS DP on existing plants, or PROFINET IO on new ones. For a SINAMICS drive on PROFINET, configure Standard Telegram 1 in the hardware configuration, set p0922 to match in the drive, then exchange the control word, speed setpoint, status word and actual speed cyclically from the PLC program.

Can a PLC control a VFD without using %IW and %QW addresses?

Yes. DPRD_DAT and DPWR_DAT exchange the whole telegram using the hardware identifier of the submodule, and library blocks such as SINA_SPEED take the same identifier as HWIDSTW and HWIDZSW. Serial protocols like USS and Modbus never use I/Q addresses at all — their data sits in data blocks.

What is a hardware identifier?

It is a number TIA Portal assigns to every module and submodule, available as a system constant such as Drive_1~Standard_Telegram_1. Passing it to a block tells the block which device to talk to, so the program no longer depends on the absolute I/Q addresses.

What is the difference between PZD and parameter access?

PZD is the cyclic process data — control word, setpoint, status word and actual values — exchanged every bus cycle. Parameter access is acyclic: the program asks for or writes a single parameter, such as a ramp time, and the answer comes back over several cycles.

Should I use SINA_SPEED or write my own function block?

SINA_SPEED is quick to apply and handles the drive state machine for you. A block of your own is smaller, easier to follow in the classroom, and lets you decide exactly how each bit behaves. Both use the same telegram underneath.

Does USS or Modbus RTU need I/Q addresses?

No. The communication module is addressed through its own hardware identifier and the data is exchanged through data blocks. That is also why the update rate depends on the instruction call and the baud rate, not on the process image.

Is hardwired control still acceptable?

For a single drive with start, stop and a speed potentiometer, yes — it is cheap and needs no program. It stops being sensible as soon as you want fault numbers, actual current, parameter changes or more than a couple of drives.

Which method gives the fastest reaction?

A fieldbus or Industrial Ethernet telegram, because the data is exchanged automatically every cycle. Serial protocols depend on the instruction being called and on the baud rate, and hardwired analog is fast but carries almost no information.

Reviewed by Bhawesh Kumar Singh Industrial Automation Trainer and Industry 4.0 Consultant · Softwell Automation · 21+ years industry experience

Get the full syllabus + free demo class

Share your details — a Softwell training advisor will call you within 24 hours with batch dates, fees and hardware access options.

No spam. Used only to share course details for this enquiry.

Learn with practical industrial examples

Join live online, Pune classroom or corporate in-plant automation training.

Request Course Details
Verified learning pathway

Discuss Your Automation Requirement

Get guidance for training, corporate programs, projects or technical resources.

Content reviewed: 22 September 2026

☎ Call WhatsApp ✉ Email Enquire Now