Monitoring and Triggering Siemens LOGO! Network Inputs via LWE

Monitoring and Triggering Siemens LOGO! Network Inputs via LWE Web Server

This reference covers a recurring field problem with the Siemens LOGO! 8 family: the on-board Extended Web Server (EWS) and the LOGO! Web Editor (LWE) tool inside LOGO! Soft Comfort (LSC) make it trivial to expose local digital value objects (DVOs) as web switches, but they do not expose network inputs (NI) or network outputs (NQ) directly. When the program sits on a master LOGO! 8.FS4 and the physical I/O lives on a slave LOGO! 0BA8 Standard, the engineer must bridge those network tags into local DVOs before LWE will display them or accept a write-back command.

The article shows the canonical way to do that: mirror each NI into a local marker (or vice versa) inside the LSC program, bind the marker to a DVO in LWE, and use a LOW block to convert a web-button press into a one-cycle pulse that is then routed back to an NQ on the slave. A parking-barrier (parking arm) application is used as the worked example.

1. Problem Statement

Two distinct sub-problems are usually encountered together when an installer tries to extend a master/slave LOGO! 8 setup with a browser-based HMI:

1. Display problem: A network input coming from a slave LOGO! (e.g. the status of a barrier-up limit switch wired to slave I1) must appear as a status indicator on the customized web page hosted by the master.
2. Trigger problem: An operator must be able to push a button on the web page to drive a network output to the slave (e.g. "raise barrier" or "lower barrier"). The press should be edge-triggered (one scan), not latched.

The Extended Web Server and LWE only bind to DVOs that exist in the local program memory of the device hosting the web page. NI and NQ tags are communication objects, not local DVOs, so binding them directly produces no widget at all - which is what most newcomers experience.

2. Prerequisites

The LOGO! system manual for 0BA8 (Siemens document A5E33039794-AC) and the LOGO! Soft Comfort online help (Help > Contents > "Network Projects") are the two mandatory references during setup. Both are reachable from support.industry.siemens.com by searching the article number.

3. LOGO! Network Architecture

LOGO! 8 uses Ethernet S7-style communication between master and slave units. The topology in scope here is a single-master/multiple-slave star on a shared Ethernet segment:

The master is the only device that runs the user program. Each slave reports its physical inputs as network inputs on the master and accepts network outputs from the master back to its physical outputs. The slave's own program is allowed only for local intelligence (e.g. a debounce filter) - it cannot host the application logic.

The two key counts to verify in the master LSC project (Tools > Network > Network Project) are:

4. Configuring Network I/O in LOGO! Soft Comfort

Network I/O in LSC is configured under Tools > Network > Ethernet Connections or, when using the Network Project wizard, automatically on slave insertion. For each slave you define a node with its IP address and assign which NIs on the master receive that slave's physical inputs (and vice versa for NQs).

For the barrier example, define:

• Slave A NI1 <- physical I1 on Slave A (the "arm-up" limit contact). Wire Slave A I1 directly to NI1 in the slave's local program, or have the master treat NI1 as an input that originated at Slave A.
• Master NQ1 -> physical Q1 on Slave A (the "raise" coil). The master writes NQ1; Slave A reads NQ1 and drives Q1.
• Master NQ2 -> physical Q2 on Slave A (the "lower" coil).

In the master program, NI1, NQ1, NQ2 are first-class operands - they appear in the constant/operand picker exactly like I1, Q1, Q2 do on a stand-alone LOGO!.

5. Why Network Inputs Cannot Be Bound Directly in LWE

The Extended Web Server and the LWE customization layer render only what exists as a DVO in the local program memory of the device serving the page. A network input (NI) is a logical placeholder for data arriving via the S7 transport; it is not a DVO with a user-assigned name. LWE has no mechanism to list NI/NQ tags in its operand picker.

Workaround: bring the NI into a local marker. The cleanest pattern uses a single negated edge with single-shot (LOW block) or a direct pass-through marker:

+--[ NI1 ]------+-------( M1 )
                |
                +-------( web status bit "BarrierUp" )

M1 is now a DVO. Open LWE, add a digital value object named BarrierUp, point it at M1, and the web page will render it as a read-only indicator (LED). On the next cycle, when Slave A's I1 changes, the master NI1 changes, M1 follows, and the web page updates within one scan.

6. Web Server Button vs Switch Behavior

This is the most-misunderstood part of LWE and is the source of the second half of the field question. The LWE document model treats every digital value object as either a dynamic signal (a button press) or a static signal (a switch). The Extended Web Server distinguishes them by widget type at render time:

For a button widget the web server only emits a 1 while the operator holds it. The moment they release, the web server writes 0. If you wire that DVO straight into a network output, the network output will be 1 for the duration of the press and 0 the moment they release - which is usually too short for the LOGO! scan to register a command.

7. The LOW Block in Detail

The LOW block (LSC block library > Special Functions > Miscellaneous > Edge-triggered single-shot) is a positive-edge-triggered one-shot. When its input Trg transitions from 0 to 1, the output Q goes high for exactly one program cycle and then returns to 0, regardless of how long Trg stays high.

Parameters (per the LSC FBD inspector):

For the barrier, the master program needs two LOW blocks:

+--[ DVO "BtnRaise" ]--(Trg)--(LOW)--(Q)--+( NQ1 to Slave A )
                                              |
                                              +--( M2 auxiliary marker, optional )

+--[ DVO "BtnLower" ]--(Trg)--(LOW)--(Q)--+( NQ2 to Slave A )
                                              |
                                              +--( M3 auxiliary marker, optional )

When the operator presses the "Raise" button in the browser:

1. Browser writes DVO BtnRaise = 1.
2. LOW block sees the 0→1 edge on its Trg input.
3. Q of LOW goes high for exactly one scan of the master (typically 10-50 ms depending on the master cycle time and program length).
4. NQ1 is therefore high for exactly one scan.
5. Slave A receives NQ1 high for one scan and drives Q1 for one scan - enough to latch an output coil on the slave if you also have a self-holding relay pattern on the slave's program.
6. Web server writes DVO BtnRaise = 0 on release. LOW is already back at 0, so nothing further happens.

8. LWE Project Walkthrough

1. In LSC, on the master project, open Tools > LOGO! Web Editor (this launches the LWE tool that ships with LSC).
2. In the LWE tree, expand the master and add a new page, e.g. Barrier.
3. Right-click the page > Add digital value object. Create three objects:
   • BarrierUp - type Indicator, bound to M1.
   • BtnRaise - type Button, bound to M2 (the LOW trigger input).
   • BtnLower - type Button, bound to M3 (the LOW trigger input).
4. Lay out the widgets on the canvas. Recommended: status indicator at the top (green when up, red when down), two buttons below labelled "Raise" and "Lower".
5. Click Save to master project. The LWE XML is bundled into the .lsc file but is not transferred to the LOGO! until the next program download.
6. Download the program to the master via Ethernet (Transfer > PC → LOGO!).

9. Commissioning the Barrier Application

The full master program for the barrier, in FBD-style textual form, looks like this:

// Master program - LOGO! 0BA8.FS4

// --- Display path: slave barrier status -> web indicator
NI1 ---------------+-----------------( M1 )    // BarrierUp
                   |
                   +-----------------( M4 )    // optional: local memory copy

// --- Command path: web button press -> one-cycle pulse -> network output
BtnRaise (M2) -----(Trg)---[ LOW ]---(Q)--------( NQ1 )    // Raise barrier
BtnLower (M3) -----(Trg)---[ LOW ]---(Q)--------( NQ2 )    // Lower barrier

// --- Optional interlock: prevent raise+lower at the same time
M1 --[ NOT ]-- Q1   // barrier must be down before raising

The slave (0BA8 Standard) program is intentionally minimal:

// Slave program - LOGO! 0BA8 Standard

// Hardware input
I1 ---------------------------( NI1 to master )    // BarrierUp feedback

// Network output from master
NQ1 (from master) -------------( Q1 )              // Raise coil (with self-holding if needed)
NQ2 (from master) -------------( Q2 )              // Lower coil

// Local interlock example: Q1 and Q2 mutually exclusive
Q1 --[ NOT ]-- NQ2 input on slave logic
Q2 --[ NOT ]-- NQ1 input on slave logic

10. Verification Steps

After downloading to both devices, verify in this order:

1. Ethernet reachability. From the engineering PC, ping 192.168.0.10 (master) and ping 192.168.0.11 (slave). Both must respond within < 5 ms on a switched network.
2. Web server availability. In a browser, navigate to http://192.168.0.10. The default LOGO! web page must appear with status LEDs for all local I/O.
3. Custom page load. Click the link to the customized page (typically labelled "User Page"). The barrier status indicator must appear.
4. Display direction. Manually drive the barrier up so the limit contact closes. Within one scan the web page indicator must change state. Refresh the page if necessary - the server is stateless for the indicator widget.
5. Command direction - Raise. Press and hold "Raise". The barrier motor contactor should engage for the duration of the press + one scan. Release; the motor should remain engaged only if you have implemented self-holding on the slave.
6. Command direction - Lower. Repeat for "Lower".
7. Interlock. Try to press both buttons simultaneously. Only one output must energize (provided you wired the interlock in the slave program).

11. Troubleshooting Matrix

12. Edge Cases and Field-Proven Caveats

• Scan time asymmetry. The master cycle time depends on program length. If the master program exceeds ~20 ms per scan, the one-cycle pulse from LOW may be too short for the slave to latch a mechanical contactor reliably. In that case, add a pulse-stretching timer (e.g. on-delay of 200 ms) after the LOW output before driving NQ1.
• Browser auto-refresh. The customized web page does not auto-poll; it re-renders only on user interaction or page reload. If you need a continuously updating indicator without a page reload, embed a small JavaScript interval that calls document.location.reload() every 2-3 seconds. LWE supports adding custom HTML/JS via the "HTML object" widget.
• Network redundancy. LOGO! 8 does not support ring redundancy (MRP) or PRP. A single Ethernet cable break drops the slave. For barrier applications where a stuck-open barrier is a safety-of-life issue, wire the master interlock so that loss of communication defaults to "barrier down".
• Firmware mismatch warnings. LSC will warn at download time if master and slave firmware differ. Heed the warning - NI/NQ counts and program size limits differ between FS01, FS02, FS03, and FS04.
• Maximum customized web pages. The 0BA8 master supports up to 20 user-defined web pages, each with up to 20 DVOs. Plan the page count accordingly; if you exceed, the LOGO! will reject the project at download with a size error.
• Source-of-truth for state. Always treat the physical limit switch on the slave as the source of truth. Do not echo the web button state back to the indicator - that creates a feedback loop the operator will misread.