A library that stops at the same elapsed time after every boot is running its demo window, not failing. Buy the license for the exact library item and version, activate it against the connected controller's identity, transfer it with the programming tool online, restart the runtime, and sign off only after a cold-boot poll runs 90 minutes with zero timeouts.
A library that answers every request and then stops at the same elapsed time after every boot is not a Modbus fault. It is the library's demo timer. The vendor's store listings state the terms for its Modbus libraries: 30 minutes without functional limitations, demo, until a license is purchased. Buying the license is stage one of four. The license still has to be activated against the controller's own identity, transferred into the controller with the programming tool online, and read by the runtime at startup. This article follows the license along that path: what the 30-minute signature tells you, whether the Modbus path needs a check, where the license must physically sit, how to activate and transfer it, and the cold-boot poll that signs the fix off.
Why does the library stop at exactly 30 minutes?
A stop at the same elapsed time after every boot is the demo window of a licensed library: its store listing runs the demo at 30 minutes, and the protected functionality stops when that window expires.
Licensed function-block libraries are sold with a demo window so you can build and bench-test before you buy. Two timers exist, pointing at two different missing licenses:
- One library goes silent at a fixed elapsed time. The vendor's store listing for its Modbus libraries states the terms: full function in demo until you purchase the license.
- The whole runtime exits at a fixed elapsed time. The vendor's application-based license how-to states that an unlicensed soft PLC runs in demo mode and exits automatically after 2 hours of running time.
Symptoms and what each points to:
- Answers every request, then goes silent at the same elapsed time after every boot: the demo timer.
- Orange flag beside the library in the project: the tool marks the library unlicensed, so the fix is a license, not a network change.
- Recovery only by restart: the reboot restarted the window, which is why restarting appears to fix it.
- Timeouts at drifting intervals, or a link drop before any fixed time: a different cause. The article on why a TCP client stops after hours and the one on finding a soft runtime's cycle time limit with a load sweep cover that path.
Check before moving on: write down the boot time and the time the master logs its first timeout. The same number of minutes after every boot confirms the demo timer; a number that moves means keep looking.
Does the Modbus path need a check first?
Your slave already answered every request right up to the timer's expiry, so the cable, switch, IP settings and TCP session all pass until the license question opens; walk the path once anyway so the license install is the only variable you change.
| Hop | What to check |
|---|---|
| Master port and cable | Link LED lit, speed and duplex negotiated, no error counters rising |
| Switch | Master and PLC on the same subnet, no port security blocking the PLC's MAC address |
| PLC Ethernet port | IP address and mask inside the master's subnet; a ping answers |
| TCP session | The master connects to the slave's configured port; Modbus TCP's default is 502 |
| Slave library | Registers map to the intended variables; a read returns live values |
Expect a clean sheet, because the slave already passed every hop until the timer expired. If a hop fails while you are working on the license, fix it separately and rerun the proof at the end of this article on the clean path.
Where must the license physically end up?
The license has to live on the controller or on a dongle the controller reads; a purchase that stays in the vendor account, or an activation made against the engineering PC, never reaches the runtime, and the library keeps running in demo mode.
Four stages sit between the purchase and a flag that stays clear:
| Stage | What holds the license | What tells you it worked |
|---|---|---|
| 1. Purchase | The vendor account and order record | The order names the exact library item and version |
| 2. Activation | A software container on the controller, or a dongle | Activation completes against the connected controller's identity |
| 3. Transfer | The controller's runtime | The license view, with the tool online, shows the entry on the device |
| 4. Runtime check | The running application | The flag beside the library is gone |
The vendor's licensing FAQ draws the line between the two containers: standard software container licenses are bound to the device, while a dongle license is activated on the dongle and can move from one device to another.
A purchase that ends the day in the account, or an activation made against the engineering PC, is stage one done and stage two skipped. The runtime finds no license on the device, so the demo window stays live and the stop repeats at the same elapsed time.
Check before moving on: with the tool online, the license view shows the entry as present on the connected device, not only in the local list.
Why is the flag still orange after you bought the license?
A purchase completes stage one only; the flag stays orange when the licensed item, the version or the device identity used at activation does not match the library and controller in your project, so the runtime keeps treating the library as unlicensed.
Three mismatches keep the flag orange after a correct purchase:
- Wrong item. A license for a different library in the vendor's range leaves this library unlicensed. Open the project's library list, read the library's exact name and version as the project references them, and hold the order record beside it.
- Wrong device identity. A license activated for a different controller, or for a unit that was later replaced, does not apply to the machine in front of you. The article on fixing a PLC runtime device mismatch safely covers the same comparison on the runtime side.
- Wrong route. Some controllers accept store purchases directly and some take licenses only through the controller vendor's own channel; the runtime build on the controller decides which. If you cannot tell, the controller vendor's documentation names the route for your version.
Check before moving on: the item name and version on the order match the project's library entry, and the identity used at activation is the controller now connected to the tool.
How do you activate and transfer the license to the PLC?
Activation binds the license to the identity of the connected controller and transfer writes it into the controller; do both with the programming tool online, then restart the runtime so it reads the license at startup.
Menu names move between tool versions; the sequence does not:
- Read the library's exact name and version in the project, and hold the order record beside it.
- Connect the programming tool to the controller and open its license view; the tool's documentation names the view for your version.
- Find the purchased entry and confirm it names your library.
- Activate it against the identity of the connected controller, into the container the order specifies: a software container on the controller or a dongle.
- Transfer the license to the controller while the tool is online.
- Restart the runtime so it reads the license at startup, and re-download the application if the tool asks.
- Open the project's library list again and confirm the flag beside the library is no longer orange.
Check before moving on: the license view shows the entry present on the device after the restart.
Worked example: how long do you run the poll before trusting the fix?
Run one cold-boot poll for 90 minutes, the 30-minute demo window plus a margin of twice that, then power-cycle and poll through another 30-minute boundary; two polling hours with zero timeouts cover both the license read at startup and its persistence.
Scenario. The PLC boots unlicensed at 08:00 and the master polls the slave every 500 ms, which is 2 requests per second, with timeout logging on. You install the license in the morning and want the machine signed off before the afternoon shift.
Signature check, unlicensed. The first timeout lands at 08:00 + 30 min = 08:30. A reboot at 09:00 puts the next one at 09:00 + 30 min = 09:30. The same elapsed window twice confirms the demo timer.
Proof run, licensed. The license is activated, transferred and the runtime restarted at 10:00. The test length is the 30-minute window plus a margin of twice that: 30 min + (2 × 30 min) = 90 min = 5,400 s. At 2 requests per second, the master sends 2 × 5,400 = 10,800 requests and logs zero timeouts with the TCP session unbroken through 10:00 + 90 min = 11:30.
Persistence check. Power-cycle at 11:35, restart the poll, and run through the next 30-minute boundary at 11:35 + 30 min = 12:05. That is another 30 min × 60 s × 2 = 3,600 requests with zero timeouts, and the flag beside the library stays clear without reinstalling anything.
Decision. 10,800 + 3,600 = 14,400 requests across two polling hours, one cold boot and one power cycle, with zero timeouts, means the license is read at startup and persists in the controller. Sign the machine off.
One safety note: if an operator action depends on this slave's data, keep that station down or manually supervised until the proof run passes, because the demo expiry cuts the data mid-shift with no warning.
Recommendation: for any licensed library that stops at a fixed elapsed time, buy the license for the exact library item and version shown in the project, activate it against the connected controller's identity, transfer it with the programming tool online, restart the runtime, and sign the machine off only after a cold-boot poll runs 90 minutes with zero timeouts and a power-cycle leaves the flag clear.
What if the transfer offers no target or fails?
A transfer that offers no target, or that fails with a correct order in hand, means the runtime on the controller is not accepting that license type; stop there and raise it with the controller vendor with the library name, version and order record.
Two causes cover almost every failed transfer. The runtime build on the controller accepts only certain license routes, so a store purchase can be correct and still have no target on a controller whose vendor supplies licenses through its own channel. And the container type on the order can be one the controller cannot hold, for example a dongle order on a controller with no dongle slot. Check the order's container type against what the controller physically has, then raise the case with the controller vendor with four things: the library's exact name and version, the runtime version, the order record, and what the license view reported. Buying a second license before that conversation is money spent twice.
Questions
Can a spare controller be licensed in advance?
Only through a dongle. A license stored on a controller belongs to that device, and the vendor's licensing FAQ states it cannot be transferred to another one. The documented portable case is a dongle license, which can be activated on the dongle and carried from one device to another. Keep the dongle with the spare, and the licensed library starts on the spare without a new purchase. A device-stored license on a failed controller follows the vendor's replacement process.
Is there a license for a short pilot line?
Yes. The vendor's licensing options include rental and withdrawal alongside permanent licenses, so a rental covers a machine trial or a pilot line where a permanent purchase is not yet approved. A rental binds to the controller or dongle the same way a purchase does, so the activation, transfer and 90-minute proof in this article apply unchanged, and the rental is withdrawn when the trial ends.
Does powering the controller off pause the demo window?
Treat the window as running time. The vendor's how-to describes the soft-PLC demo limit as a runtime of 2 hours, and a window that restarts at every boot counts the controller's running time, not wall-clock time. No listing documents a way to pause the window by powering off, so plan the proof run as one unbroken session.
Planning information, not legal or engineering advice. Rules differ by place: check codes and permits with your local authority and your licensed trades.