iqToolPro — User Manual

IQ2 Development · IO-Link

iqToolPro User Manual

Configuring and diagnosing IO-Link devices through an IQ2 IO-Link master. The tool runs on your own PC and is used in a browser.

Part one

Getting started

1.1Installing

There is nothing to install. Unzip the folder somewhere you can write to — Desktop or Documents — and keep it together: iqToolPro.exe needs the wwwroot folder and appsettings.json beside it.

Do not run it from inside the .zip, and avoid Program Files unless you are installing deliberately; the tool writes downloaded device descriptions into a cashed_iodd folder next to itself.

1.2Starting and stopping

Double-click iqToolPro.exe.

A console window opens and stays open. That window is the application — leave it running. Your browser opens automatically at http://localhost:5291.

To stop it, close the console window or press Ctrl+C in it. Closing the browser tab alone leaves the tool running.

First run

Windows may warn that the file is not recognised, because it is not code-signed. Choose More info → Run anyway.

User manual, at the top right of every page, opens this manual in a new tab — the copy that came with this version of the tool, so it needs no internet.

1.3Connecting to a master

Open Connections and press Connect.

The tool finds the master itself. It scans every serial port for a modern G06 master first, and if none answers it scans again for a legacy iqInterface / iqLink master. The port dropdown is informational — it does not restrict the search.

On success the page names the stack that answered and shows Master Identification: vendor, master ID, type, feature flags and port count. If nothing answers, the error names what each attempt reported; the usual causes are a master that is not powered, a driver still installing, or another program already holding the port.

This manual assumes a G06 (SMI) master

Everything in it works with one. A legacy iqInterface / iqLink master speaks an older protocol that has no equivalent for some services, so a few pages do less — each page in Part 2 ends with what a legacy master cannot do, and 3.6 collects them in one table.

The Connections page after a successful connect
Connected to a G06 master on COM15; the badge says which stack answered. The version is beside the name at the top of the menu — quote it when you report a problem.
Prerequisite

Every other page needs this connection. Each one says so and links back here.

1.4Your first look at a device

  1. Connect the master.
  2. Plug the IO-Link device into port 1.
  3. Open Port, press Read, and confirm Port Mode is an IO-Link mode and the port has reached OPERATE.
  4. Open Process Data to watch what the device is measuring, or IODD to see its parameters by name.

Steps 3 and 4 depend on the device description.

1.5Device descriptions, and why they matter

Without a description, a device's process data is a row of hex bytes and its parameters are numbered indexes. With one, everything has a name, a unit and a sensible range.

The tool handles this by itself. When a device reaches OPERATE it reads the Vendor ID and Device ID, downloads the matching description from IODDfinder, and keeps a copy in cashed_iodd so the same device works offline afterwards. An internet connection is needed only the first time a given device type is seen.

  • A description belongs to one device type. Swap the device and the old description is released immediately, whether or not a new one can be found. A page reporting no IODD is giving you the honest answer, not failing.
  • Not every device is published. If IODDfinder has nothing, use Load file on the IODD page. An uploaded description is cached against that device's identity and comes back by itself next time.
  • The local library is never used automatically. It is reachable through Match from device, where the choice is yours.
Part two

The pages

Connections /

Find the master, and see what it reports about itself.

Covered in 1.3.

On a legacy master

The page works in full. It is also where the tool tells you a legacy master answered, and lists what that costs elsewhere.

Port /port

Configuration and live status for one port.

Choose the port number at the top and press Read.

Configuration

Port Mode, Validation & Backup, IQ Behavior, Cycle Time, and the Vendor/Device ID used for validation. Edit, then Write; Reset restores what was last read from the master.

Power Control

Switch port power off permanently, on permanently, or off for a set number of milliseconds.

Status

Refreshed once a second: the port's state, the connected device's identity, the port quality bits, and any diagnostic entries the master is holding.

The Port page
Configuration on the left, Power Control beside it. Port Mode, Validation & Backup and IQ Behavior decide whether a device is accepted at all.
Start here on a new setup

A port left Deactivated never reaches OPERATE, so no device is detected and no description is bound.

On a legacy master

The page works — reading and writing the configuration, the live status, and all three power commands — except Cycle Time, which is shown read-only: a legacy iqLink cannot set it, and Write leaves it as it is.

Process Data /process-data

The cyclic data exchanged with the device, refreshed once a second.

What you see depends on the port's mode.

IO-Link mode — input

Process Data In shows the raw frame as hex, and beneath it the named fields the description declares. A value that changes flashes green for a second, so you can watch one field without staring at all of them.

IO-Link mode — output

Process Data Out is an editor, not a display. Each declared output field gets the control its type implies — a list of named choices becomes a dropdown, a plain on/off a checkbox, anything else a text box. Set the values and press Write PDOut; Reset returns to the last known output.

Bits that no field declares are always sent as zero. If no description covers the output, you get a grid of raw bits to click instead — the only way to write an output nothing describes.

Process Data for a temperature sensor
The raw frame is 23:E1; the description names it ambient temperature process value and gives 9185. This sensor declares no process data output, so the Out card is empty — a device with outputs shows its editors there.

C/Q modes

In DI C/Q mode the single input bit is shown. In DO C/Q mode you get the current output state and buttons to set it HIGH or LOW.

On a legacy master

DI C/Q and DO C/Q are not available at all — the legacy protocol has no C/Q input or output service, and the page says so instead of showing controls that would fail.

IO-Link mode works, with one difference: Process Data Out shows the last value this tool sent rather than a reading from the device, because there is no output readback to ask for.

IODD /iodd

The device's own parameters, named and grouped the way the vendor intended.

Along the top: the port number, Match from device (search the local library), Load file (a .zip or .xml you supply), and Clear.

Below that, the description's identity, the Language selector, and the Role selector — Operator, Maintenance or Specialist. The role decides how much the vendor exposes; Specialist shows the most.

Each tab is shown as one fully expanded tree. Opening it reads every value in the background, so the page stays usable while it fills in.

The IODD page
The description was fetched from IODDfinder — the green badge says so. The live badge next to Read all reports three values being re-read on a 0.5 s cycle.

Editing a parameter

Writable parameters have an editor, and under it a grey line stating what the description allows — range -50…50 °C, up to 8 characters, 12 hex octets. Values are shown and entered in the units on screen, scaling included.

Type an unacceptable value and the limit is replaced by the reason as you type, the box turns red, and that row's Write is disabled until it is fixed. Nothing is sent to the device that the description already rejects.

Each row has its own Read and Write; Read all refreshes the tab. Parameters that are commands rather than values appear as an Execute button.

A rejected entry on the IODD page
38 characters typed into a field that holds 32. The box turns red, the limit is replaced by the reason, and Write for that row is greyed out. device: *** below still shows what the device actually holds.

Live values

Parameters the description marks as changing on their own — temperatures, hour counters, signal quality — are re-read continuously while the tab is open, and flash green when they change. The header shows how many are being watched and how long a full pass takes.

That figure is measured, not promised

Every live value costs one request to the device, so a tab with many of them cycles more slowly. The header always reports the pass the tool actually achieved.

On a legacy master

The page works in full. Every value here is read and written one parameter at a time, which is how the page behaves on any master.

Device Access /device-access

Direct read and write by index and subindex.

For when you know exactly which parameter you want, or when there is no description. Choose a format — byte array (hex), decimal, hexadecimal, or UTF-8 string; the numeric formats are big-endian. Read and Write are independent panels.

Device Access
Index 0x0010 read as a UTF-8 string — the standard Vendor Name parameter.
Unguarded

There is no range checking here and no name to confirm you have the right parameter. Prefer the IODD page wherever a description exists.

On a legacy master

The page works in full.

Data Storage /data-storage

The device's parameter set, as held by the master.

This is how a configured device is cloned onto a replacement: the master keeps a copy, and writes it into whatever device is plugged in next.

Data storage has to be switched on for the port first

Until it is, the master keeps no copy and this page has nothing to show. It is enabled on the Port page, not here.

FieldSet it to
Port ModeIO-Link Manual (0x01)
Validation & BackupCompatible + Backup & Restore (0x03)
Vendor ID0
Device ID0

Press Write, and the port restarts into the new configuration.

Leaving both IDs at 0 is deliberate — the master fills them in itself from the device on the port, so there is nothing to look up and nothing to mistype. Read the configuration back afterwards and you will see the real Vendor and Device ID in place of the zeros you wrote.

Autostart will not do. In Autostart the master does not use the Validation & Backup setting or the two IDs at all; writing Autostart leaves whatever was there before. Data storage needs the manual mode together with a backup-enabled validation setting, which is why the two are set together above.

The two backup settings differ in direction:

  • Compatible + Backup & Restore (0x03) — the master both takes new values from the device and writes its copy back. This is the one to use while configuring a device.
  • Compatible + Restore only (0x04) — the master writes its copy into the device but never takes anything new. Use it once the stored set is the one you want and should not drift.

Reading and writing the object

Read from master fetches it and shows the header — parameter checksum, Vendor ID, Device ID, Function ID — followed by every stored parameter. Save to file writes the raw object to a .bin; Load file opens a saved one for inspection without touching hardware; Upload to master writes one back.

The Data Storage page after Read from master
Three parameters stored for the device on port 1, 60 bytes in all; the badge says the set came from master rather than from a file. The header records which device the set belongs to, which is what lets the master decide whether a replacement is the same type. Index 24 is the Application-specific Tag, padded out to its full 32 octets — 2A 2A 2A is *** followed by zeros — while 256 and 257 are the device's own parameters.

ParamDownloadStore sends that system command (0x05) to the device on the port. Changing a parameter does not by itself start data storage — the device has to be told the change is complete. Press it after changing parameters, then Read from master to see what the master holds.

Before you rely on it

Upload writes a whole parameter set to the master. Read it back and compare.

The Validation page does this switching itself

Its Data Storage tab puts the port into Manual with Backup & Restore, exercises the whole cycle, and sets the port back when it finishes.

On a legacy master

This page is unavailable in its entirety. Data storage is held by the master, and the legacy protocol has no service for reading that copy out or writing one back. The page says so in place of its controls.

Dashboard /dashboard

A presentation of the device on one page, showing only what you choose.

Named panels, each holding the parameters, process data values, commands and device information you picked from the device's description. It needs a connected master and a description bound to the port.

There is one dashboard per device type (VendorID and DeviceID). Plug in another device of the same type and its dashboard appears; plug in a different type and that type's dashboard, or none, is shown. A device that is unplugged and reconnected, or a master that is disconnected and connected again, shows its dashboard again.

Never saved or loaded automatically

A dashboard is kept only while iqToolPro runs; Save to file keeps it, Load from file… brings it back (see Saving and loading below).

The sample dashboard

The first time a device type is connected while iqToolPro runs, Dashboard shows a sample built from the device's description:

  1. Identity — the device identification block;
  2. Identification — the parameters of the description's Identification menu;
  3. Parameters — the parameters of its Parameter menu, submenus included;
  4. Observation — the parameters of its Observation menu.

A menu the description does not have gets no panel. Every writable parameter has its editor; the sample holds no commands. Change it with Edit, or close it with Close dashboard — it does not come back until iqToolPro is started again.

Creating a dashboard

  1. Open Dashboard. With no dashboard open for this device type, the page says so.
  2. Click Create dashboard. The page switches to edit mode with one panel, Identification, holding the device identification block.
  3. Add panels and items as below, then click Done.
A dashboard for the MAXREFDES42
A dashboard for the IQ2 Development MAXREFDES42 temperature sensor. Device: picture, logo, identity, transmission data and the M12 connector with its wire colours. Measurement: the process value, updated every second, and the temperature in °C and °F. Settings: the two switch-point parameters, made editable — each shows its range and Write — and the Application-specific Tag. Status, across the full width: vendor, product, firmware, error count, device status, and the Restore Factory Settings command.

Adding a panel

  1. Click Edit (skip this while you are still creating the dashboard).
  2. Click + Panel in the toolbar. A new panel — Panel 2, Panel 3, … — appears at the end.
  3. In the panel's header, type its name and choose its width: ⅓, ½ or full width. On a narrow window every panel takes the full width.
  4. Add items to it (next section).
  5. Click Done.

Adding items to a panel

  1. In edit mode, click + Item under the panel.
  2. The list shows everything the device's description offers, grouped the way the description groups it:
    • Identification — the device identification block;
    • the description's Identification, Parameter, Observation and Diagnosis menus, with their submenus where the description has them — for example Parameter › Statistics › Lot Counter;
    • Process data — the fields of the process data input;
    • System commands — the system commands the description offers;
    • Other variables — parameters no menu shows.
    Each entry says what it is: parameter, PD, command or identity.
  3. Type in the filter box to narrow the list — by name or by group.
  4. Click an entry to add it. An entry already in the panel is marked ✓; you can still add it again.
  5. Click Done to close the list.

Changing items

In edit mode every item has:

  • a name box — type a name of your own; leave it empty to use the description's name;
  • ↑ / ↓ to move it within the panel, and ✕ to remove it;
  • for a writable parameter, Editable — tick it to show an editor with Write on the dashboard.

Some parameters can be shown but never edited, and say why instead of offering Editable: the Direct Parameter pages (index 0 and 1), the System Command (index 2), DS_Command (index 3) and Device Access Locks (index 12) — the same indices the Validation page never writes. The System Command is offered only as its separate commands, each with its own Execute, so a command is never sent by mistake.

Moving and removing panels

In edit mode, each panel's header has ◀ / ▶ to move it left or right, the width selector, and ✕ to remove it — together with its items, and without asking. Nothing changes until you click Done; Discard throws away every change since Edit and brings back the dashboard as it was.

Using the dashboard

  • Values are read once when the page opens. ↻ beside a value reads it again, ↻ in a panel's header reads the whole panel, and ↻ Read all reads everything.
  • Process data values update every second on their own.
  • An editable parameter shows the value the device holds in its editor, and the range the description allows underneath. A value outside it is marked red as you type and Write stays disabled. A list starts at — choose — until the value has been read. After Write the value is read back, so what you see is what the device holds.
  • Execute sends a command; the line underneath says when it was sent and any message the description gives for it.
  • A write-only parameter shows write-only instead of a value.
  • The identification block shows the vendor logo, the device picture, names and IDs, the description's version, the transmission rate, minimum cycle time and SIO support, and the connector with its pins and, where the description gives them, wire colours.

Saving and loading

  1. Save to file downloads the dashboard as iqToolPro-dashboard-<vendor>_<device>.json into the browser's download folder. Keep it, or send it to someone with a device of that type.
  2. Load from file… opens such a file and shows it at once — on this PC or another, in the desktop tool or the browser version.

A dashboard you changed and have not saved says Not saved to a file; closing it then takes a second click. Close dashboard only closes it in iqToolPro — files are never touched.

A file made for another device type can still be loaded: the page names the type it was made for and asks first. Anything in it that this device's description does not have is shown in red as missing — remove those items or leave them.

Not yet

Device events (notifications, warnings, errors) cannot be shown on a dashboard — iqToolPro does not read events from the master yet.

Visualization /visualization

Values plotted and monitored over time.

Needs a description bound to the port — everything here is named and scaled by it.

Pick a parameter from the list (type to filter, or use the caret for the whole catalogue), choose Text or Graphic, and press Add. Text tiles show the current value, and become an editor with their own Write button when the parameter is writable. Graphic tiles draw a curve.

Operation time sets the window — a duration and a unit — and Start / Stop control sampling. The line underneath shows the window, the achieved cycle time, and how many cycles have run.

Each chart carries its own scale selector and an Auto-fit tick. Left alone the axis uses the range the description declares, printed beneath the chart; Auto-fit scales to the data actually arriving.

Each added parameter costs one request per cycle, so the cycle time grows as you add more. Sampling stops when you leave the page.

Export CSV, beside Start / Stop, saves what the window holds as a CSV file: one row per cycle, one column per parameter on the page, headed with its name and unit. Every row starts with the clock time and Elapsed since sampling start [ms]; all parameters read in the same cycle share that time, and a read that failed leaves its cell empty. Numbers use a decimal point and columns are separated by commas, which is what Python, MATLAB and most analysis tools expect. Excel set to German opens it in one column on a double-click — use Data → From Text/CSV instead. To keep a longer stretch, set a longer duration before pressing Start.

Visualization with a text tile and a graphic tile
A parameter as text, the process value as a curve, ten seconds after adding them. The cycle is 115 ms because the parameter costs a request of its own every cycle. The axis runs 0…65535 because that is what the description declares — the trace sits near the bottom, which is what Auto-fit is for. Export CSV is beside Stop.
On a legacy master

The page works in full. Process data and parameters are both read with services a legacy master provides.

Validation /validation

Checks a connected device against its own description, and reports every check of a parameter on that parameter's one line.

The checks are split into tabs, one per kind of testing: Parameters and Data Storage (described at the end of this section). The panel above the tabs is shared: the port number, Start validation, the case count, the result badges and the progress bar always refer to the open tab, and each tab keeps its own results when you switch away. Tabs cannot be switched while a run is in progress.

It needs three things: a connected master, the port in Operate, and an IODD bound to that port. Without any of them the page says which one is missing rather than starting.

This page writes to the device Each write test reads the parameter, writes a value the description permits, reads it back, then writes the original value back and confirms it. Before you press Start validation the table already lists every case the run will perform — including everything it will skip and why — so you can see exactly which parameters will be written before anything is.

Five things are never written, whatever the description says about them: Direct Parameter pages 1 and 2 (index 0 and 1), SystemCommand (index 2), DS_Command (index 3, where a write would start a data storage upload or download) and DeviceAccessLocks (index 12). Write-only parameters and system commands are listed but never touched — a write-only parameter cannot be read back, so there would be no way to put the original value back.

Every run leaves the parameters as it found them On every tab, the first row, Before the test · Read all parameters, reads every read-write parameter the description declares. The last row, After the test · Write all parameters back, reads each one again and writes back any the test changed, then confirms it. Open either row for one line per parameter — ✓ written back, – unchanged, or ✗ NOT written back with the reason. The write-back also runs when a check fails or you press Cancel. If the device does not answer when the parameters are read first, the test does not run at all: nothing is tested that could not be put back.

The table has four sections:

SectionWhat it holds
Identity VendorID and DeviceID from the port, and VendorName read from the device, against the description
Parameters Every parameter of the description, one row each, with a result per check in the columns below
Data storage DataStorageIndex read from the device, and the parameters it saves
System commands Listed for completeness, never executed

A parameter row has three result columns:

ColumnWhat it does
Read Reads the parameter. A text parameter that answers longer than declared — or, when the description fixes its length exactly, shorter — is a warning
Write Writes a permitted value to a read-write parameter, reads it back, restores the original. A write-only parameter shows skipped: it is never touched
Out of range Writes a value the description forbids and expects the device to refuse it. A text parameter is sent one character too long — and, when the description fixes its length exactly, one character too short — and the device should refuse it on length

A dash means the parameter has no such check: a read-only parameter has nothing to write. A run takes the parameters one at a time — read, write, out of range, then the next.

Results are pass, warning, fail or skipped. A warning is a difference that is not a defect — a device that does not implement an optional parameter, a vendor name written “SICK AG” where the description says “SICK”, or a value the device holds that its own description does not permit. A fail is a real disagreement: an identity that does not match, a value that reads back differently from what was written, or a forbidden value the device accepted.

Reading the table. Each parameter is one line: its name, a result in each column, and the single most useful piece of information — its value when everything passed, the most serious reason when something did not. Click a row to open it. An open row lists each check in turn with its result and everything it did in the order it happened: what was read and how many octets came back, or the before / wrote / read back / after of a write test. Opening a row closes whichever row was open before, so the table stays short.

Validation after a run, with the warned row open
A finished run: 71 passed, 1 warning. The open row is the warning — Direct Parameter page 2 answered differently on each read, and both reads are shown. Report (PDF) beside Start saves all of it.

A parameter addressed by subindex — the Direct Parameter pages, Device Access Locks, an array, Data Storage — is one row until you open it, and then shows its subindexes underneath, each with its own columns, tinted as one block. Its own line shows the octets it occupies (00:40:40:1B:…) rather than a decoded value, because the subindexes are what carry the values. While such a row is closed each column shows the worst result inside it, so a failure can never hide inside a folded parameter.

A row is hidden only when every check in it was skipped; the Show skipped switch brings those back. On a typical device many checks are skipped, and each says why.

Whole against parts. When a parameter has subindexes and the device offers them separately, the run reads each one on its own and compares it with the same field taken out of the whole-parameter read. These are two different services on the device, and one that answers them differently has a fault neither read shows alone. If the parameter simply comes back different every time it is read, the run says that instead — a value that will not sit still cannot be compared with itself.

Data storage is read from the device, not from the master: DS_Command, State_Property, Data_Storage_Size, Parameter_Checksum, and the Index_List of parameters the device wants saved, each named from the description. The section is skipped when the description does not declare data storage. What the master holds is a different thing: it lives on the Data Storage page, and the Data Storage tab tests it.

An open row has a Rerun beside each check, to repeat that check alone, and Rerun all to repeat every check of the parameter — for a parameter with subindexes, of its subindexes too. Cancel stops the run between checks; the check in flight always finishes putting its original value back first.

If a restore ever fails A red banner stays at the top of the page naming the parameter and both values, and the run is recorded in Logs. That is the one outcome worth acting on immediately.

Many cases are skipped on a typical device, and the reason is always given. Most often it is “the description permits every value the type can hold, so none is forbidden” — there is simply no out-of-range value to send.

Keeping and reporting results. A run's results stay on the page — for each port and tab — when you visit other pages, and when the device drops out: an unplugged device, a port that leaves Operate, or a description released because of that leaves them as they are, with Rerun off until the device is back. They are cleared, with a note saying why, when a different description is bound or a device with another VendorID or DeviceID appears on the port — and by the next Start validation.

Report (PDF) saves the open tab's run as a PDF: the master, port, device, description and run times, the summary, then every failed and every warned check in full — its message, what passed over the wire step by step, expected against actual, the device's error code — and every other check on one line. The report is printed with Microsoft Edge, which Windows includes.

The Data Storage tab

Tests data storage through the master: whether the master's copy follows the device when the port is in Backup + Restore, and whether the master puts the device back when the port is in Restore.

This tab reconfigures the port and writes to the device Step 1 sets the port to AUTOSTART if it is not already, so the tab can start from any port mode. The parameters it works on are the ones the device itself lists for data storage (its Index_List).

The table shows the test's seven steps. Click a step to open it: its substeps are listed underneath, each with its own result. Every substep runs in order, and a substep that fails stops the test — the substeps after it show skipped with the reason. Only Start validation runs the test; there is no Rerun.

StepSubsteps
1 · Check port configuration 1.1 Check if port mode in port configuration is set to AUTOSTART
1.2 If not, set port mode to AUTOSTART (with No device check)
1.3 Wait until port status reaches OPERATE
2 · Switch the port to Backup + Restore 2.1 Remember current Device and Vendor ID
2.2 Set port mode MANUAL, Validation&Backup Type compatible Device V1.1, Backup + Restore, saved Vendor and Device ID
2.3 Wait until port status reaches OPERATE
3 · Compare Data Storage in master with the device 3.1 Read Data Storage from master
3.2 Read all data storage parameter values from device
3.3 Compare: quantity of parameters and values are the same
4 · Change the parameters and check the master follows 4.1 Change all data storage parameters on device and validate they are written correctly
4.2 Send system command ParamDownloadStore (0x05)
4.3 Wait 5 seconds
4.4 Read Data Storage from master
4.5 Compare the new values with Data Storage in master
5 · Remember ORIGINALS and switch the port to Restore 5.1 Remember all data storage parameter values as ORIGINALS
5.2 Set port mode MANUAL, Validation&Backup Type compatible Device V1.1, Restore
5.3 Wait until port status reaches OPERATE
6 · Check the device and the master hold ORIGINALS 6.1 Read Data Storage from master
6.2 Read all data storage parameter values from device
6.3 Compare with ORIGINALS: they should be the same
7 · Change without validating and check ORIGINALS come back 7.1 Change all data storage parameters on device, without validation
7.2 Send system command ParamDownloadStore (0x05)
7.3 Wait 5 seconds
7.4 Read Data Storage from master
7.5 Read all data storage parameter values from device
7.6 Compare with ORIGINALS: they should be the same
7.7 Set port mode back to AUTOSTART

Changing a parameter does not by itself start data storage: the device has to be told the change is complete. That is what the system command ParamDownloadStore does, so it follows every change of the parameters, and the 5-second wait starts after it.

7.7 always runs once step 2 has switched the port to MANUAL — after the last substep, after a substep that failed, and when you press Cancel. If it does not succeed, the red banner appears; check the port on the Port page. The parameters are put back too — by the After the test row that ends every run.

A step's result combines its substeps: fail or warning when one of them is, skipped when some did not run, pass when all passed. Click a substep for what it did — the port configuration it wrote, each port status change with its time, the octets it read. The compare and change substeps list one line per parameter under themselves, starting with ✓ or ✗. A parameter the tab cannot change (not in the description, never written, or with nothing writable in it) is named with the reason and makes that substep a warning.

On a legacy master

The Parameters tab works in full — it reads and writes the device one parameter at a time.

The Data Storage tab does not: every step of it compares the master's copy of the data storage object against the device, and a legacy master cannot hand that copy over.

Events — not implemented /events

Intended for the diagnostic events a device and master raise.

This page is not implemented

It opens, a port can be chosen and Start Polling can be pressed, but no events are ever collected — the polling is disabled in the code. This is not a master limitation: the list stays empty on a G06 master and a legacy master alike, however much the device reports.

Nothing on the page is harmful; it simply does nothing. The columns are in place for when it is implemented: timestamp, qualifier and code, a description, and badges for type, mode and source.

The Events page
The page as it stands. The list is empty because the page is not implemented, not because the device has raised nothing.

Logs /logs

What the tool itself did.

Connection attempts, IODD downloads and cache hits, failed reads and writes, and unexpected errors. Entries carry a timestamp and a level, and anything with a stack trace has a details link.

The Logs page
Connection attempts, IODD downloads and cache hits, in order, with a level on each.
Look here first

This is the right page when something does not behave, and the right thing to send with a support request.

The log file. The desktop tool also writes every entry to a file in the log folder beside the program, one file per day (iqToolPro-2026-10-07.log), kept 14 days. Each run starts with the tool's version and the machine, and each connect names the master that answered. An error that repeats unchanged — a page polling a master that stopped answering logs one every second — is written once, followed by how often it came again. Clear empties the list on the page; the file keeps everything.

  • Save log… downloads today's file — every run of the day, not only this one. Send that file with a support request.
  • Open log folder opens the folder in Explorer, for earlier days.

If the folder cannot be written — the tool installed where a user may not write, such as Program Files — the page says so and the log is kept on the page only. In the browser version there is no file: Save log… downloads what the page holds since the tab was opened.

On a legacy master

The page works in full. It records what the tool did and never talks to the master itself.

iqToolPro in the browser

The same pages in a web browser, without installing anything.

At https://harleyincorp.bitbucket.io/app/. Differences from the desktop tool:

  • Microsoft Edge or Google Chrome only. They are the browsers that can use a serial port (Web Serial); other browsers show a notice.
  • Connect opens the browser's own list of serial ports — choose the IO-Link master there. Only an SMI iqLink can be used; a legacy iqLink cannot.
  • IODDs are not downloaded from IODDfinder. Load the device's IODD once on IODD with Load .zip / .xml; the browser keeps it and binds it on its own the next time that device type is connected.
  • Report opens the browser's print dialog; choose Save as PDF to get the file.
  • What the browser keeps (uploaded IODDs) belongs to that browser on that PC, and is gone if the site's data is cleared.
Part three

Reference

3.1Where things are kept

WhatWhere
Downloaded and uploaded IODDs cashed_iodd, beside the executable — or %LOCALAPPDATA%\iqToolPro\cashed_iodd if that folder is read-only
Local IODD library Documents\IODDs by default; Iodd:LibraryRoot in appsettings.json
Dashboards Nowhere on their own — only the files you save with Save to file
Settings appsettings.json, beside the executable
Logs In memory only — cleared when the tool closes

3.2Settings worth knowing

All under Iodd in appsettings.json.

SettingMeaning
LibraryRootFolder searched by Match from device. Blank means Documents\IODDs
CacheFolderWhere downloads are kept. Blank uses the default above
AutoDownloadfalse stops the tool reaching the internet on its own, and stops automatic binding entirely
AutoBindPortCountHow many ports are watched for automatic binding
FinderTimeoutSecondsHow long to wait for IODDfinder before falling back to the cache

Urls, at the top level, sets the address. Change it if port 5291 is already in use.

3.3Port quality bits

Shown on the Port page.

BitNameMeaning
7PQ0 = process data valid, 1 = invalid
6DevErrAn error or warning is present on the device or port
5DevComDevice detected and in OPERATE
4–0—Reserved

3.4Data Storage object layout

A 12-byte big-endian header, then the stored parameters.

FieldType
Parameter Checksumuint32
Vendor IDuint16
Device IDuint32
Function IDuint16

Each entry that follows: Index (uint16), Subindex (uint8), Length (uint8), then that many data bytes.

3.5How a description is chosen

  1. The port reaches OPERATE and reports Vendor ID and Device ID.
  2. IODDfinder is asked for that identity, at the IO-Link revision the port reports. A hit is bound and cached.
  3. If the portal has nothing, or cannot be reached, the cache is tried.
  4. If neither has it, no description is bound.

The local library is not part of this and is only reached through Match from device. Revisions are never substituted: a description written for one IO-Link revision is not bound to a port reporting another, because the revisions differ in what a device supports at all.

3.6Legacy master limits

The tool works with two kinds of master. A G06 (SMI) master speaks the standard SMI services, and this manual is written around one. A legacy iqInterface / iqLink master speaks an older protocol with no equivalent for some of them. The Connections page names which answered.

PageOn a legacy master
ConnectionsWorks
PortWorks — configuration, status and all three power commands
Process DataIO-Link mode works, but Process Data Out shows the last value this tool sent rather than a device readback. DI C/Q and DO C/Q are unavailable
IODDWorks
Device AccessWorks
Data StorageUnavailable — the whole page
VisualizationWorks
ValidationParameters tab works. Data Storage tab unavailable
EventsNot implemented, on either kind of master
LogsWorks — it never talks to the master

Two services account for every gap above: the pair that reads and writes the master's data storage object, and the C/Q input and output services. There is also no parameter-batch operation in the legacy protocol, but no page in the tool uses one on any master, so nothing you can see depends on it.

Data Storage on a legacy master
The page says so rather than failing quietly.

3.7When something goes wrong

SymptomWhere to look
No master foundMaster powered? Driver installed? Another program holding the port? Then Logs
Port never reaches OPERATEPort — Port Mode may be Deactivated, or validation may be rejecting the device
Process data is hex with no namesNo description bound. IODD — match, or load a file
A page says no IODD is boundCorrect after a device swap if the new device has none published. Load a file
A write is refused before it is sentThe value is outside what the description allows; the grey line under the box states the limit
A write is refused by the deviceLogs — the device's own error code is recorded there
Values are not updatingOn Visualization, sampling may be stopped; elsewhere, check the connection

When you report a problem, quote the version shown beside iqToolPro at the top of the menu, for example 1.0.0.2. Hovering over it shows the build it came from.