ENTTEC publishes a TwinCAT 3 library, SplayBeckhoff, that lets a Beckhoff PLC control an S-PLAY show controller (SKU 70092) directly from Structured Text. This article explains what the library does, how the two systems talk to each other, and what you should verify before committing a project to it.
Why put a PLC in front of an S-PLAY?
On many commercial sites, a Beckhoff PLC is already the brain of the building: it runs the schedules, reads the occupancy and daylight sensors, tracks the operating mode (open, closed, cleaning, alarm), and drives HVAC and blinds. Recreating that logic inside the S-PLAY's own triggers and schedules means maintaining two copies of the site logic that will eventually drift apart. This integration resolves the split cleanly: the PLC stays the single source of truth for site state, and the S-PLAY becomes a network-attached lighting playback engine that the PLC commands. When the building enters "evening" mode, the same PLC program that dims the corridors can start the matching S-PLAY playlist.
If you know TwinCAT but not entertainment lighting, here is the lighting side in one paragraph. Fixtures are controlled by DMX, a stream of 8-bit channel values grouped into universes of 512 channels, usually carried over Ethernet as Art-Net or sACN. The S-PLAY (SKU 70092, currently sold as the S-PLAY SP1-1) is a standalone controller that stores lighting states called cues, sequences them into playlists, and plays them out across up to 32 universes. A lighting programmer records the looks once, in the S-PLAY's built-in web UI; after that, "control the lighting" reduces to "tell the S-PLAY which playlist to run", which is exactly what this library does. If there is no PLC on site, the S-PLAY's built-in schedules and triggers (see An Overview of S-Play Automation) are usually all you need.
How it works
The integration runs over plain Ethernet using HTTP and JSON, not a fieldbus. There is no EtherCAT, ADS, or Modbus mapping involved. The S-PLAY exposes an HTTP API: JSON commands POSTed to http://<s-play-ip>/api, documented in the SplayApi repository and in our S-Play API article. The SplayBeckhoff repository wraps that API in a single TwinCAT function block, FB_SPLAY, so PLC code calls methods like SPLAY.PLAY(nPlaylistId := 1) instead of hand-building HTTP requests.
FB_SPLAY is built on two standard Beckhoff libraries, which you pass in as inputs: FB_IotHttpClient from Tc3_IotBase handles the HTTP transport (the README links its documentation under Beckhoff TF6760, TC3 IoT HTTPS/REST), and FB_JsonDomParser from Tc3_JsonXml builds and parses the JSON. Responses arrive on the block's jsonRX output, which you can dump to a string with fbJson.CopyDocument() or walk node by node with fbJson.FindMember() and GetString().
One thing to be clear about: the library is published compiled-only. The repository contains SPLAY_API_v1.0.0.1.compiled-library plus a complete TwinCAT example solution, but no Structured Text source for the library itself.
What you need
| Item | Detail |
|---|---|
| S-PLAY | SKU 70092, running S-Play software v2.2 or later, on a static IP reachable from the PLC on port 80 |
| Beckhoff TwinCAT 3 XAE | The example project file records TwinCAT 3.1 build 4024.47, targeting TwinCAT RT x64 |
| SPLAY_API library | SPLAY_API_v1.0.0.1.compiled-library from the root of the SplayBeckhoff repository |
| Tc3_JsonXml | Beckhoff JSON library; the example pins v3.3.19.0 |
| Tc3_IotBase | Beckhoff HTTP client library; the example pins v3.1.19.0 (plus tc3_iotfunctions 3.3.1.0) |
| Structured Text knowledge | The examples are a CASE-based state machine in a MAIN program |
Cues and playlists are normally authored first in the S-PLAY's own web UI; the PLC then triggers and manages them.
Setup outline
The repository README is the authoritative walkthrough; the outline below only mirrors it.
- Download
SPLAY_API_v1.0.0.1.compiled-libraryfrom the repository root. - In TwinCAT, open the References folder, choose Library repository, then Install, and select the
.compiled-libraryfile. Restart TwinCAT afterwards; the README explicitly warns that the restart is required. - Make sure Tc3_JsonXml and Tc3_IotBase are installed and referenced.
- Prepare the S-PLAY: record cues and build playlists in its web UI, set a static IP, and confirm the software version is at least v2.2.
- In your PLC program, declare
fbJson : FB_JsonDomParser, anFB_IotHttpClientconfigured with the S-PLAY's IP (the example usessHostName := '192.168.0.10',nHostPort := 80,bKeepAlive := TRUE, a 10 second connection timeout), andSPLAY : FB_SPLAYconstructed from both. - Call the API methods and read replies via the JSON parser.
- Open the EXAMPLES solution's
MAIN.TcPOUfor full working patterns: a five-state CASE machine covering device info, playlist creation, cue saving, playback, and reading a cue back.
What you can control from the PLC
FB_SPLAY's methods follow the official S-Play HTTP API command names. The example project demonstrates five of them:
| Method | What it does |
|---|---|
| GET_INFO | Read device and system information |
| UPDATE_PLAYLIST | Create or update a playlist from a JSON string |
| SAVE_CUE | Create or save a cue, including frame data |
| PLAY(nPlaylistId) | Start playback of a playlist |
| GET_CUE(nCueId) | Read a cue back from the device |
The underlying HTTP API is much broader, covering playlist transport (play, pause, stop, including all-playlists variants), playlist and cue management, cue-level playback, master and playlist intensity, DMX frame capture, triggers and events, schedules, and device settings.
The README lists commands that are not implemented in the Beckhoff library: GET_PLAYLIST_INTENSITY, SET_TRACK_INTENSITY, GET_TRACK_INTENSITY, UPDATE_STORAGE_PATH, UPDATE_SCHEDULE, DELETE_SCHEDULE, ENABLE_SCHEDULE, SET TIME, and REFRESH_SETTING. Note that schedule management is on that list, which fits the architecture: if the PLC is the site brain, schedules live in the PLC, not the S-PLAY. Because only the compiled library is published, the complete method list beyond the five demonstrated examples cannot be confirmed from source; treat the demonstrated set plus the stated exclusions as the established surface.
There is also a stated buffer limitation: input buffers are limited to 3 kB, and the output buffer is user-sized (the example uses STRING(10000)). Some responses need large buffers, so size accordingly and test with your real payloads.
Scope, licensing, and what to verify before you commit
The repository is best treated as an integration example and library, not a supported product. Points a buyer should check:
- No licence is stated. Neither SplayBeckhoff nor SplayApi carries a LICENSE file or a licence statement in the README, so usage and redistribution terms are legally unstated. If that matters for your contract, raise it with ENTTEC before building on it.
- Support path. The README's only support pointer is to the official S-Play API documentation (the SplayApi repository). There is no issue-tracker guidance or support contact in the repo. The repository was created in January 2024 and last pushed February 2024, with v1.0.0.1 as the stated latest version and no releases or tags.
- TF6760 licensing. The README links the HTTP client documentation under Beckhoff TF6760 but never discusses whether a paid TF6760 runtime licence is required on the target PLC. The example project ships a trial licence file. Confirm licensing with your Beckhoff supplier.
- Firmware compatibility. The SplayApi documentation requires S-Play software v2.2 or later; compatibility with current S-PLAY firmware (v3.2.1 at time of writing) and with the S-PLAY MINI is not stated anywhere in the repo. Test against your actual firmware before commissioning.
- Authentication and TLS. The S-Play API includes login and auth-token commands, but nothing documents whether
FB_SPLAYsupports authentication. The examples use plain HTTP on port 80; TLS support is unverified. Keep the PLC and S-PLAY on a trusted control network.
If the library's gaps rule it out, everything it does is plain HTTP JSON, so you can drive the same API directly with your own FB_IotHttpClient code.
Related articles
- S-Play API, the HTTP API this library wraps
- Triggers, for automation handled on the S-PLAY itself
- An Overview of S-Play Automation
- eDMX (Art-Net / sACN): Sending using a PLC, for driving DMX output directly from a PLC without an S-PLAY