English
Device Discovery
Device discovery finds the devices on your network so you do not have to know their addresses in advance. You give Pulse a network range, it scans for Siemens S7, OPC UA, and PROFINET devices, and it shows you what is there — one entry per device, with everything it found out about it. You then decide which of those findings become data sources.
It doubles as an inventory. A scan reports every module that answered, not only the ones you can read values from, and every host it saw on the segment, including the ones that turned out to speak nothing it knows. What you can add and what is on your network are two different questions, and the results page answers both.
Open it from Assets > Discover devices in the sidebar, or from the Discover devices button on the data sources page. Only organization admins can run a scan.
INFO
Discovery only ever reports what it finds. It never creates a data source on its own — adding a device takes you to the ordinary create form with the discovered values filled in, and you confirm it yourself.
What each protocol finds
| Protocol | What it looks for |
|---|---|
| Siemens S7 | Every module that answers over ISO-on-TCP — the CPU, and the communication processor in front of it. Each is listed with its rack, slot, order number, firmware version, serial number and operating state — RUN or STOP — where it reports them. |
| OPC UA | OPC UA servers, including the endpoints and security settings each one offers, and manufacturer name, product name and firmware version from the server when it offers an unsecured endpoint |
| PROFINET | PROFINET devices in the same network segment as the scanner, found over DCP on layer 2, including devices with no IP address yet |
Each protocol is enabled separately on your license. If one is not enabled, its checkbox is disabled and marked not in your plan. The rest still work.
Read access on S7-1200 and S7-1500
S7-1200 and S7-1500 need PUT/GET enabled
These controllers leave the factory with PUT/GET communication switched off, and the same applies to a CPU running with full protection. Such a controller still appears in the results — the scan reaches it — but it says nothing about itself: no order number, no firmware version, no serial number and no operating state. Its finding is marked Read access disabled, and Pulse cannot read values from it later either.
To make it readable, enable PUT/GET access in the controller's protection settings in your engineering tool, then scan again. S7-300 and S7-400 controllers usually need no such change.
PROFINET reaches one segment only
PROFINET cannot cross a router
PROFINET devices are found over DCP, which works on layer 2: the scan reaches the devices in the segment the scanner itself is attached to, and no further. A wider network range does not change that, and a router cannot be bridged however the range is written. S7 and OPC UA are unaffected — those are scanned over IP and reach across routers as usual.
To cover a segment the appliance is not attached to, scan it from a collector that is.
Run a scan
- Go to Assets > Discover devices.
- Click Configure to open the scan settings:
- Network range — Pulse fills in the networks it is already attached to, so in most plants you can leave this alone. To scan somewhere else, replace it.
- Look for — choose the protocols to scan for.
- If your organization has remote collectors registered, Scan from — this appliance (the default) or a specific collector. Use a collector to reach a segment the appliance cannot access directly. A scan cannot start if the selected collector is not currently connected, has been revoked, or has been removed. If a previously selected collector was removed from the organization, the picker shows Collector removed in its place; choose a connected collector or scan from this appliance.
- Click Start scan.
Once a scan finishes, Scan again starts a fresh scan with the same settings.
Network range formats
Separate several entries with spaces or commas. You can mix formats:
| Format | Example |
|---|---|
| A single host | 192.168.10.5 |
| A CIDR block | 192.168.10.0/24 |
| A range | 192.168.10.10-20 |
| A longer range | 192.168.10.1-192.168.10.254 |
If a range covers a large number of hosts, Pulse asks you to confirm before starting. That check exists to catch a mistyped prefix — a /16 is far more addresses than a /24.
Try every rack and slot
An S7 module answers on a particular rack and slot. By default Pulse tries the four most common positions, which covers almost every installation.
A rack usually answers more than once. Where it is reached through a communication processor — a CP 443-1 in an S7-400, for example — the CP answers for itself at a rack and slot of its own, and the CPU answers behind it. Both are listed under the same device, each with its own order number and firmware, because both are equipment you own. Only the CPU offers Add: a communication processor holds none of the CPU's data blocks, so a data source pointed at one would connect and read nothing.
One module can also answer at more than one position — an S7-1500 CPU answers at slot 1 and at slot 0. It is listed once, at the position a data source addresses it on.
If a device shows a communication processor and no CPU, the CPU is usually in a position outside the four Pulse tries by default.
Turn on Try every rack and slot (in Configure) when you expect CPUs in unusual positions. It finds more, but takes considerably longer, because every position is tried on every address that did not already answer.
While the scan runs
The page fills in as results arrive, rather than waiting until the end. A status bar across the top of the results shows the elapsed time and counts of warnings and errors — click it to open the full scan log.
The results, one entry per device, filling in as the scan proceeds. Use the filter above the table to narrow by device name, address, order code, or serial number. Click any row to open a panel with the full details the scan collected — serial number, station name, function and location tags, endpoint URL, and CPU state.
Where a device answered on more than one protocol, or a rack answered for multiple modules, click the expand arrow on the row to see each finding listed separately.
On a directly attached network the devices appear before they have been probed: the Siemens S7 scan asks the segment who holds each address before it probes anything, and that answer is already an inventory. Each device then fills in with what it turned out to speak. Scanning across a router skips that step — there devices appear as they answer.
You can leave the page and come back — the scan keeps running, and the page shows it again with everything found so far. The same goes for another browser tab or another device: whoever opens the page while a scan runs sees that scan and can stop it. To stop early, click Stop. Devices already found are kept.
The page's address names the scan it shows, so a bookmark or a shared link opens that scan again, also after it has finished. Opened without such a link, the page shows a running scan, or is ready for a new one.
Only one scan runs at a time per organization. Two overlapping scans would probe the same controllers at once, which can exhaust the limited number of connections an S7-300 accepts and lock out an engineering station.
What a PROFINET finding shows
Every PROFINET finding shows the device's MAC address, and its IP address if it has one. Pulse then asks the device itself for its identification data, and adds the order number printed on the housing, the firmware version and the serial number to the finding.
Pulse also asks for the tags your commissioning engineer wrote onto the device: what it does, and where it is. When a device carries them, the finding is headed by that name — the one on your cabinet label and in your documentation — and the PROFINET device name moves down into the line beneath it. Many devices have no tags, because the fields are optional and often left blank; those findings are headed by the PROFINET device name instead.
That second question is optional in both directions. A device with no IP address cannot be asked at all, and neither can a device whose address lies outside every subnet the appliance is on — on any of its network interfaces; and not every device answers — some firmware does not support the request. When it goes unanswered the finding is still complete; it simply shows what the scan alone could tell.
Asking takes a moment. Pulse questions several devices at once, and gives a device that does not answer a few seconds before moving on, so PROFINET findings can keep arriving for a short while after the search itself has ended. After thirty seconds Pulse stops asking regardless; any device still waiting is reported with what the search alone found.
Alongside the I&M0 read, Pulse also listens for LLDP announcements on the segment. A PROFINET device that announces itself over LLDP — typically a switch or a managed device — adds its LLDP system name and LLDP system description to the finding's detail panel. Because LLDP is a passive, independent protocol, these values are populated whether or not the I&M0 read succeeded: a switch that declined the acyclic read may still broadcast its full identity string over LLDP in the same scan. The system description is the raw text the device itself sends — manufacturer name, product name, and firmware version in the vendor's own format — rather than individual parsed fields.
What an OPC UA finding shows
Every OPC UA finding reports the server's endpoint URL and the security configurations it advertised during discovery. When the server offers an endpoint with no security (None/None), Pulse also reads its BuildInfo — the server's own account of what it is — and adds the manufacturer name, product name, and firmware version to the finding. These are the same fields PROFINET and S7 findings populate from I&M0, so a mixed fleet of devices reads consistently across protocols.
If the server offers only encrypted or authenticated endpoints and no unsecured one, BuildInfo cannot be read without credentials. The finding is still complete; it simply shows what endpoint discovery found.
What an S7 finding shows
The detail panel for an S7 device includes a Racks and slots tried section showing which rack and slot positions the scan probed and what happened at each one:
| Outcome | Meaning |
|---|---|
| Answered | A module responded at this position and reported its order code, serial number, and firmware. |
| Answered, refused identification | A module responded but would not report its identity — see Read access on S7-1200 and S7-1500. |
| Refused the connection | Nothing the scan could reach was at this position. A module with all its connections in use also refuses, so a position that answered in a previous scan may refuse now while an engineering station is connected. |
| Not tried | The scan stopped after finding 8 modules on this device. A module may still be at that position. |
When the scan tried every rack and slot — more than 32 positions total — only the positions that answered are listed individually; positions that refused or were not tried are counted in a summary line below.
Why a device name can look scrambled
A PROFINET device name may only contain lowercase letters, digits, hyphens and dots, so an engineering tool has to rewrite any name that does not fit — it lowercases it, replaces the characters it cannot use, and adds a short checksum. A device named Tank4_SRV in TIA Portal therefore reports itself as tank4xbsrv5554. A name that only had to be lowercased is passed through unchanged. TIA Portal shows both names side by side in the properties of the PROFINET interface, as the device name and the converted name.
Pulse reads that rewriting back where it can. The checksum tells it the name was converted, so a device reporting itself as xva34xnh10-kt11a343 is headed =a34+h10-kt11 — the designation your project uses. Two things it cannot do: capitals are discarded by the conversion and cannot be recovered, so a reconstruction is always lowercase, and a name using a substitution Pulse does not recognise is left exactly as reported.
Nothing is hidden either way. The name as the device reports it stays on the row beneath the heading, so it still matches what you see in your engineering tool or in the device's own web interface. A device that carries commissioning tags is headed by its tag instead, since that one was typed by a person rather than reconstructed.
How Pulse recommends connecting a device
A scan can find one machine three times over: a CPU on port 102, that same CPU's own OPC UA server on 4840, and a PROFINET name on the wire. Each device row therefore carries one recommendation rather than a list — hover it for the reason.
| Recommendation | What it means |
|---|---|
| Symbolic | The CPU answered an S7CommPlus session, so Pulse can read it by tag name with nothing switched on. |
| OPC UA | The device's own OPC UA server answered. A documented interface, and it needs no PUT/GET either. |
| S7 (classic) | The CPU identified itself over PUT/GET, so it can be read at absolute addresses. |
| No path yet | The CPU answered on port 102 and neither of the above. The tooltip says what would have to change. |
The order is not a preference. Symbolic comes first because it reads the names the program already carries and needs nothing enabled on the controller; the CPU's own OPC UA server comes next for the same PUT/GET-free reason; the classic path works and costs a setting many plants switch off on purpose.
No path yet is an S7-1200 or S7-1500 with PUT/GET off and firmware or a TIA project older than symbolic reading needs. What opens it is one of: migrate the project to TIA Portal V17 or later (with firmware V2.9 on an S7-1500 or V4.5 on an S7-1200), switch on the CPU's own OPC UA server, or enable PUT/GET access. Where the scan could read the firmware and it is already new enough, the hint says so and names only the TIA migration.
A scan shallower than Identify asks none of this, so devices from such a run carry no recommendation at all.
S7CommPlus probe in the detail panel
Opening a device's detail panel shows a S7CommPlus field for every S7 finding, with one of three answers:
| Answer | What it means |
|---|---|
| Yes | The CPU answered an S7CommPlus session — it can be read by tag name. |
| No | The CPU was asked and did not answer the S7CommPlus probe. |
| Not checked | Nothing asked this device for S7CommPlus. The scan stopped before identify, or the collector that ran it is older than the probe. This is not the same as the device saying no. |
Scanning from an older collector: if the selected collector does not support the S7CommPlus probe, a warning banner appears on the scan page. Classic S7 devices are still found; only the symbolic capability check is skipped. Update the collector to check both.
Add a discovered device
Findings you can read values from have an Add button. It opens the create form for the recommended path with the discovered values already filled in — the address for a symbolic S7 CPU, address with rack and slot for a classic one, or the endpoint URL for OPC UA. Review them and save.
Findings without one are still real: they are equipment on your network that this scan identified, and they are listed for that reason. What they lack is anything a data source could read.
Devices that already match a data source are marked Already added, so a repeat scan does not offer to add the same controller twice. The detail panel says the same for each module a data source can read — a classic or symbolic S7 CPU, an OPC UA server — and links to the data source that already reads it.
Some findings need attention before they can be read:
- Read access disabled — the CPU answered but would not identify itself. The device is real and can be added, but it needs PUT/GET access enabling on the controller before Pulse can read from it. If it is also marked Symbolic, you do not need to: it can be read by tag name as it stands.
- Communication processor — a CP in front of a rack. It is real equipment with its own order number and firmware, and worth knowing about, but it holds no data blocks, so there is nothing to add. If it appears without a CPU beside it, scan again with Try every rack and slot, or check which slot the CPU is in.
- Not identified — something answers on the S7 port and accepted none of the rack and slot positions tried. It may be a CPU at an unusual position, an HMI, or a gateway. Try every rack and slot to find out more.
- Seen on the network — a host that answered the network sweep and none of the protocols scanned for. These are folded into a collapsed count at the bottom of the results; toggle Show hosts without a protocol to expand them. Nothing is known about them beyond their address and, where Pulse could learn it, their hardware address.
- No IP address — a PROFINET device that answered on the network segment but has no usable IP address yet. It has to be given one before it can be monitored.
If nothing is found
- Check that the network range is the one the controllers are actually on.
- Check that Pulse can reach that network. A range behind a router is reachable for S7 and OPC UA.
- For PROFINET, check that whatever is scanning — the appliance or a collector — is attached to the segment the devices are in: PROFINET cannot cross a router.
- If you expect an S7 CPU in an unusual rack or slot, run the scan again with Try every rack and slot turned on.