Can Productivity2000 Send Raw UDP Messages to BrightSign?

The BrightSign player accepted UDPTEST from Hercules, but in April 2016 the Productivity2000 was reported to lack a programmer-directed raw UDP send function. The key decision is whether the installed controller firmware documents a function that sends an arbitrary datagram; an Ethernet port or EtherNet/IP support alone does not provide one.

Confirm the BrightSign trigger before touching the PLC

Use the PC test as a player-side check. Hercules sent UDPTEST to the player and the video played, so the BrightSign was configured to recognize a UDP trigger under that test setup. It does not prove that a PLC can create the same packet or that the PLC and player can exchange traffic across the production network.

Record the working player address, configured listening port, exact trigger text, and resulting playback. The example strings include a trailing space: UDPTEST and VideoXYZ . Preserve case and spaces. Do not append a line ending or other bytes unless the player configuration expects them. A receiver that compares a configured string may treat an extra character as a different command.

If Hercules no longer triggers playback, fix the BrightSign configuration or network path first. Repeat the test from a PC on the same network segment as the PLC and target the same player address and port. Once the PC test works, leave the player configuration unchanged while testing the PLC path so one variable changes at a time.

Check the installed Productivity2000 send instruction

Read the instruction set and communication documentation for the exact Productivity2000 model and installed firmware. Look for a documented operation that lets the program specify a destination address, destination port, and arbitrary payload bytes. Confirm the feature is supported by the firmware actually running in the rack, not just by a roadmap statement or a description of Ethernet capabilities.

The April 2016 technical answer was that Productivity2000 could use implicit EtherNet/IP messaging, but could not issue unrelated raw UDP messages. The user later reported being told UDP was on the roadmap. A roadmap does not establish that a particular release implemented the feature. For a present-day installation, make the decision from current documentation for the installed firmware and, if needed, an official AutomationDirect support answer tied to that model and revision.

If the instruction list has no documented raw datagram send operation, stop searching for a hidden UDP setting or trying to assemble the message with ordinary ladder logic. A string value in the PLC is not a network send operation. Proceed to the controller or gateway decision below.

Separate EtherNet/IP implicit messaging from raw UDP

Both claims heard in 2016 could sound true because UDP is a transport used by EtherNet/IP implicit messaging. That does not mean the controller exposes a general-purpose UDP socket to the user program. Implicit messaging carries data in the expected EtherNet/IP connection format; the application cannot replace that protocol payload with free text such as VideoXYZ and call it a raw UDP trigger.

Adding an EtherNet/IP I/O connection, changing an I/O assembly, or finding the word UDP in protocol documentation will not create an arbitrary message sender. Those mechanisms solve cyclic controller-to-device I/O exchange. The BrightSign use case needs a datagram whose destination and payload match the player configuration.

Use this branch: if the project requires an EtherNet/IP device connection, configure and validate that connection for its supported device. If the requirement is one-way text sent to a BrightSign IP and port, continue only with a controller or gateway that documents arbitrary UDP transmission.

Prove unicast before testing multicast

Start with one player and its individual IP address. Read the listening port from the BrightSign setup; no port value is specified here. Unicast gives the test a single destination, making it easier to compare the configured receiver with the packet emitted by the sender.

UDP does not provide delivery confirmation to the PLC. A rung going true proves only that the program reached its send logic; it does not prove the player received the datagram or played the file. Use playback plus a packet capture or a capture at the receiving endpoint to separate a sender problem from a network or player problem.

Consider multicast only after the unicast message works. The proposed multicast approach was not demonstrated in the installation. Multicast requires a configured group destination and a receiver that listens for that group; switches and routers must also pass the traffic as designed. Do not treat the absence of a repeat setting in the player as a substitute for selecting the correct destination group and port. Check the player’s multicast support and the network configuration before changing the destination.

Keep the GPIO route as a temporary restore

The installation already used the BrightSign GPIO input to trigger playback. The reported drawbacks were an additional cable, a dry-contact requirement, and GPIO inputs that were not optically isolated. If that path is currently working and remains suitable for operation, retain it as the temporary production restore while validating the UDP design.

Do not assume that any PLC output can drive the BrightSign GPIO directly. Preserve the dry-contact requirement and check the electrical interface and ratings for both devices before changing the wiring. The proposed opto-isolated input board and solid-state relays were a planned redesign, not a tested UDP solution; they do not change whether the PLC can send a raw packet.

Keep the distinction clear in the maintenance record: GPIO restores the existing trigger path; raw UDP removes the extra trigger wiring only after the PLC or gateway sends the configured message and the player responds. If the GPIO interface is unsuitable or no longer available, do not improvise an electrical substitute from the UDP discussion. Select a documented interface for the hardware.

Choose a controller or gateway with raw UDP output

In the 2016 exchange, Do-more was identified as the AutomationDirect PLC option that could send raw UDP or TCP without using a standard protocol. The named two-instruction approach was STRPRINT and PACKETOUT. Use the installed Do-more instruction help for the exact operands, destination setup, message formatting, and completion handling; those details depend on the actual project configuration.

The Productivity2000 user also considered CompactLogix, based on their understanding that it could send UDP. Treat any replacement choice the same way: confirm that the exact controller, firmware, and programming software provide user-directed arbitrary UDP output. Confirm the needed unicast or multicast mode as well. Do this before buying hardware or migrating a working project.

If keeping the Productivity2000 is the priority, a protocol gateway can provide the missing network function if it accepts a protocol the PLC supports and can emit the required UDP datagram. Document both sides: how the PLC commands the gateway, how the gateway selects the player address and port, and what indication confirms a send attempt or failure. A gateway is useful only if it closes the protocol gap rather than merely forwarding EtherNet/IP I/O.

Separate temporary and permanent decisions. Keep the proven GPIO route for continuity where practical. For the permanent design, choose a raw-UDP-capable controller or a documented gateway, then prove the exact payload and destination on the production network before removing the existing path.

Build a one-shot sender for the configured BrightSign target

For a controller or gateway with documented raw UDP output, configure and test the sender in this order:

1. Set the destination to the BrightSign’s configured IP address and listening port. Start with one player and unicast.
2. Construct the payload to match the player’s configured trigger exactly, including capitalization and any intentional trailing space. Do not add a terminator unless the receiver expects it.
3. Trigger one send on the intended machine event. In PLC logic, use an edge or equivalent one-shot so a rung that remains true does not emit a datagram on every scan.
4. Use the platform’s documented send operation. On Do-more, the 2016 example named STRPRINT and PACKETOUT; check their installed help for valid configuration and status handling.
5. Monitor the send operation’s documented status or error indication, then confirm the player starts the intended video.

Do not add automatic retries until you know how the BrightSign handles duplicate triggers. A repeated UDP message may retrigger or restart playback depending on the player configuration. If the application needs recovery from a missed command, define a retry policy around observed player behavior rather than assuming UDP delivery or acknowledgment.

Verify the datagram reaches the player intact

Test the sender with the player still configured for the known message. Capture traffic at the player or use a switch mirror port or network tap where available. Compare source and destination addresses, destination port, and payload bytes with the configured trigger. A capture on an unrelated switch port may not see unicast traffic between two other ports.

Use the observed result to choose the next check:

• No outbound UDP packet: inspect the PLC or gateway logic, send-operation status, destination configuration, and interface selection.
• Packet leaves the sender but does not reach the player: check addressing, subnet and routing configuration, switch path, and any network filtering between the devices.
• Packet reaches the player but playback does not start: compare the payload byte-for-byte with the configured trigger, then check the selected file and player trigger configuration.
• Playback starts but repeats or restarts: check whether the program sends more than one datagram while the trigger remains active and how the player handles duplicate messages.

After a single-player test passes, repeat with the real machine event and normal scan behavior. Verify the intended video, no unintended retrigger, and recovery after a controller or network restart. Only then remove the temporary GPIO path if the permanent design no longer needs it.

Stop when the Productivity2000 lacks a documented raw send path

If the installed Productivity2000 documentation offers only implicit EtherNet/IP messaging and no arbitrary UDP sender, stop trying to make that connection carry the BrightSign text command. Further changes to the message string, rung logic, or I/O connection cannot supply a missing send function. Restore the validated GPIO path if available, or route the project through a controller or gateway with documented raw UDP support.

Escalate to official AutomationDirect support when the installed model or firmware documentation is unclear, or when a documented send instruction does not produce the expected packet. Provide the controller model, firmware revision, programming software revision, instruction configuration, BrightSign address and listening port, exact payload, and packet-capture result. Stop commissioning if the electrical GPIO interface or network path cannot be verified.

Productivity2000 and BrightSign UDP questions