Lighting controller Ethernet not connecting: fix IP and firewall

You power the lighting controller, open its setup utility, and the controller list stays empty. This page walks that fault in the order that clears it fastest: address first, firewall second, cable and controller last. It is written for production and test engineers commissioning a strobe or continuous-light stage over a direct PC-to-controller bench cable or a shared machine network, and it gives the values to type in plus the test that proves each step. Every check uses the controller's own utility and the tools already on the PC: ipconfig, ping, arp and the firewall console. Where the machine-network case behaves differently from the bench, the difference is called out.

Why does my lighting controller not connect over Ethernet?

Two faults account for nearly every failed lighting-controller Ethernet link: the PC and the controller sit on different IP subnets, or the Windows firewall silently drops the controller utility's packets, so run the address and firewall checks in that order before suspecting the cable or the controller.

Work down the causes in probability order and change one thing at a time, so the fix stays provable:

1. Subnet mismatch. The PC adapter and the controller hold addresses in different networks. IP delivers packets only inside one network without a router, so nothing downstream can work until this one is settled.
2. Firewall. Windows Defender Firewall discards unsolicited inbound packets on every profile. The controller's announcements and the utility's discovery replies die silently, and the list stays empty while the link itself is healthy.
3. Duplicate or drifting address. Something else owns the address the utility is dialling, or the controller changed address when a DHCP lease expired.
4. Physical layer. A dead port, an unpowered switch, or the wrong VLAN on a managed switch.
5. The controller itself. A fault state, or a network option that was never fitted.

Cable and controller come last because they fail far less often than configuration, and swapping them first destroys the evidence. The same split governs the controller-to-PLC direction, which the vision controller to PLC: TCP ports and firewall rules article covers; this page stays on the PC-to-controller link. If you are still weighing whether a controllable light stage pays for itself, five reasons to use a machine-vision lighting controller explains what the Ethernet link is actually for. The parts themselves live in the light controllers range.

What IP address should the PC and controller use for a direct link?

For a point-to-point bench link, give both ends static addresses in one private subnet: a PC at 192.168.1.10 with mask 255.255.255.0 against a controller at 192.168.1.100 is the pattern that works on almost every bench.

Wire and set it in this order:

1. Run one Ethernet cable from the PC network card straight to the controller. Gigabit ports auto-negotiate crossover, so a normal patch cable is fine.
2. Leave the controller at its factory address, which its manual states, or at the fixed address your team set at last commissioning; the PC moves to the controller, not the other way round.
3. Set the PC adapter static: IP address 192.168.1.10, subnet mask 255.255.255.0, gateway and DNS left empty, because a two-device link has no router.
4. Move that adapter to the Private network profile, so the firewall rules in a later section behave predictably.
5. Ping the controller address and expect four replies.

The mask does the limiting: 255.255.255.0 is a /24, which leaves 256 - 2 = 254 usable addresses, .1 through .254, far more than a lighting cell needs. Pick both addresses from the private blocks reserved for internal networks by RFC 1918: 10.0.0.0/8, 172.16.0.0/12 and 192.168.0.0/16. The 192.168.x.x habit is the usual bench choice because whoever reads the label next year recognises it. To browse the range by channels, control type and output instead, the light-controller finder does the filtering.

If you are specifying hardware rather than fixing it, this method applies to the models sold with the network option, and the LS-CTL-0264 is the 2-channel, 400 W network-option unit at constant voltage 24 V:

Check whether the PC and controller share one subnet

Compare network addresses, not host addresses: a PC at 192.168.1.20 with mask 255.255.255.0 belongs to network 192.168.1.0, so a controller at 192.168.2.100 sits in a different network and no direct conversation between them will ever start.

A device computes the network address with a bitwise AND of address and mask, one octet at a time:

The AND clears every octet where the mask holds 0: 20 AND 0 = 0, while 168 AND 255 = 168. Two different answers mean two different networks. The fix is symmetrical, move the controller into 192.168.1.x or move the PC into 192.168.2.x, but change one device, not both, then re-ping.

Run ipconfig and read the address beside the adapter the cable is actually plugged into; a laptop with Wi-Fi and Ethernet both live happily answers on the wrong one. On a shared machine network the test is identical, but read the mask first because plant networks are not always /24. Discovery adds a second constraint: most utilities find controllers by broadcasting on the local subnet, the mechanism the GenICam discovery broadcast article unpacks for cameras, and broadcasts do not cross a router. That is why the subnet checks first routine for an undetected GigE camera reads exactly like this section.

Why does the ping fail even though the address looks right?

A failed ping with a correct address usually means the link never came up: check the port LEDs, then run ipconfig and look for a 169.254.x.x address, which means the adapter asked DHCP for a lease, got no answer and fell back to the automatic link-local range 169.254.0.0/16.

Then work the layers:

1. Link LEDs. Both ends of the cable should show a link light. No light means no electrical link: try a known-good cable, then a different switch port, then the other adapter.
2. APIPA. The 169.254.x.x address, a block defined for IPv4 link-local autoconfiguration in RFC 3927, talks to other 169.254 hosts but never to a controller fixed at 192.168.x.x. Replace it with the static pair from the previous section.
3. ARP. Flush the table with arp -d *, ping once, then read arp -a. An entry with a hardware address means the controller answered at layer 2 and the earlier failure was transient; an incomplete entry means nothing lives at that address.
4. Duplicate address. Unplug the controller and ping its address again. A reply now means a second device owns it, and a second controller still at the factory default is the classic culprit.
5. Filtered ICMP. Some plant networks drop ping outright, so silence proves nothing on its own; the firewall test in the next section settles it.

On a Linux bench the same checks are ip addr and ip neigh, and the Linux link-local walkthrough shows those addresses reached by IP there.

Stop the Windows firewall from blocking the controller

Windows firewall blocks unsolicited inbound traffic by default on every profile, so the quickest honest test is to switch the firewall off for one minute, try the utility, and — if discovery suddenly works — switch it straight back on and write one properly scoped rule instead.

The blocked direction is inbound: the utility's commands leave the PC without restriction, and it is the controller's replies and announcements coming back that get discarded.

1. Open Windows Security → Firewall and network protection and note the active profile: Domain, Private or Public. A newly connected adapter often lands on Public, the strictest one.
2. Turn the firewall off for that profile only, run the utility, and confirm discovery works. Turn the firewall straight back on.
3. Open the Windows Defender Firewall with Advanced Security console, create an inbound rule of type Port, and allow the TCP port the utility is configured for; the utility's connection settings show the number. If the controller port is configurable, fix it to one value so the rule stays valid.
4. Scope the rule to the Private profile and, on a plant network, to the local subnet only, so it opens nothing to the rest of the site.

Third-party endpoint suites differ in menus but not in shape: inbound, allow, one port, scoped. Camera networks fail the same way, and the ping works, discovery fails GigE case is the same rule quietly eating broadcast replies.

Why is my controller slow to respond once it does connect?

Windows' delayed-acknowledgement timer adds up to about 200 ms of stall to each small request-and-reply TCP exchange, so eight back-to-back parameter writes can take around 1.6 s of pure waiting even on a healthy link.

The stall is not the controller, the cable or the switch; it is how Windows spaces small TCP writes when each one waits for the previous acknowledgement. Whether it matters is arithmetic: one 1.6 s pass at every product changeover is noise, while the same stall inside a closed-loop lighting control cycle that corrects frame by frame is a fault. Keep timing-sensitive work off the socket:

• Write the whole parameter set once at changeover instead of value by value during production.
• Let per-shot timing come from the trigger input, with the controller firing each strobe from hardware; that is the job lighting controllers for line scan cameras do at line rates, and it leaves Ethernet carrying set-up commands only.
• Keep strobe-to-exposure alignment in the trigger wiring and the camera exposure, where microseconds belong.

When is serial a better bench connection than Ethernet?

If the bench PC cannot join the machine network at all, a serial controller does the same job without the fight — the LS-CTL-0070 runs 4 channels at 200 W from a serial port, and one deliberate serial link beats a contended shared network every time.

Serial has no subnet, no DHCP and no firewall to argue with; the trade is that RS-232 is a point-to-point cable, so one PC talks to one controller and there is nothing to discover or break.

Note what does not travel over either port: the per-shot trigger. The camera or sensor fires each flash through the I/O wiring, and the camera GPIO cable guide walks that side, so parameter-setting speed barely matters at shot time. Choose Ethernet when the utility needs live readback or multi-channel sequencing; choose serial when network policy, not technology, is what keeps the PC off the machine subnet.

Keep the fault from coming back on the machine network

Prevention is three habits: fix the controller's address outside the DHCP pool and record it, keep the vision PC's machine-network adapter on its own static settings, and label the subnet on the enclosure so the next engineer never has to rediscover it.

• Reserve the controller address with IT so no other device can take it, and write it on the enclosure next to the cable entry.
• Give the vision PC machine-network adapter static settings; letting it take a lease from the office DHCP server is how addresses drift between boots.
• Set that adapter to the Private profile before commissioning, so the scoped firewall rule you wrote stays the one that applies.
• Record the utility, its version and its firewall rule in the commissioning checklist; after a PC rebuild they are the first things to vanish.
• After any power cycle, ping once before opening the utility: a silent controller straight after power-on is usually still booting its network stack, not broken.

The decisions in one place. Bench link: static 192.168.1.x pair at /24, Private profile, one inbound port rule. Machine network: reserved static address outside the DHCP pool, scoped rule, subnet labelled on the enclosure. PC barred from the network: serial. Connected but sluggish: batch the set-up writes and move per-shot timing to the trigger line.

If the utility still shows an empty list after the address test and the firewall test, capture one discovery attempt with a packet tool such as Wireshark and read which side stays silent; that split, PC-side or controller-side, is where every remaining case separates. Send the capture with the ipconfig output through the contact page and we will read it with you. The controllers topic page gathers the rest of the controller guides. If this is a new cell rather than a stuck one, start the configurator at the controller step: