Return to Data Core

Using AI to Build a PTZOptics G3 Crestron SIMPL# Module

2026-05-24
Dark technical thumbnail showing a SIMPL# module, SIMPL+ wrapper, AV rack, and PTZ camera control path

Using AI to Build a PTZOptics G3 Crestron SIMPL# Module

This week was a good win: we generated a working Crestron SIMPL# module and SIMPL+ wrapper for PTZOptics G3 camera control in a mostly automated workflow.

The useful part was not just that the module compiled. It was that the workflow moved from documentation, to driver source, to SIMPL+ wrapper, to Crestron compiler validation, to onsite adjustment without turning into a long manual rebuild cycle.

The final 3-Series build compiled cleanly:

Total Error(s): 0
Total Warning(s): 0

And the same Visual Studio 2008-based approach gave us a path that compiled cleanly for both 3-Series and 4-Series targets. That matters because the first modern-toolchain path looked promising, but it did not cover the older processor target the way we needed.

The Goal

The goal was straightforward: create a reusable Crestron SIMPL Windows module for PTZOptics G3 cameras.

The camera side used PTZOptics HTTP-CGI commands. The Crestron side needed:

  • A SIMPL# driver for the HTTP control logic
  • A SIMPL+ wrapper for SIMPL Windows signals
  • A compiled .clz library
  • A compiled .ush module output
  • Clean 3-Series compiler validation
  • A practical onsite path for camera movement, zoom, presets, and auto-tracking behavior

The module exposes the control surface you would expect for a real room or production deployment:

  • Pan and tilt: up, down, left, right, diagonals, and stop
  • Zoom: zoom in, zoom out, and zoom stop
  • Presets: recall and save presets 1-5
  • Auto tracking: on, off, and toggle
  • Polling: device configuration query
  • Feedback: connected, busy, auth required, auth failed, command error, auto tracking, active preset, last status, and last response

The core HTTP-CGI command pattern is simple:

GET /cgi-bin/ptzctrl.cgi?ptzcmd&left&{panSpeed}&{tiltSpeed} HTTP/1.0
Host: {camera}
Connection: close

The value was in wrapping that control path cleanly for Crestron and proving the build through the right compiler chain.

The Automated Workflow

The workflow was intentionally tight:

  1. Read the PTZOptics G3 HTTP-CGI documentation.
  2. Generate the SIMPL# driver methods for pan, tilt, zoom, presets, polling, and tracking.
  3. Generate the SIMPL+ wrapper signals and method calls.
  4. Compile the SIMPL# library.
  5. Copy the generated .clz beside the SIMPL+ wrapper.
  6. Compile the wrapper with the Crestron SIMPL+ compiler.
  7. Read the compiler result and adjust the module until the output was clean.

This is where AI helped most. It did not just draft code and stop. It helped keep the source, wrapper, library name, compiler target, and build notes aligned.

The wrapper references the SIMPL# library like this:

#USER_SIMPLSHARP_LIBRARY "PTZOpticsG3Driver"

So the compiled library has to stay named:

PTZOpticsG3Driver.clz

That filename alignment is one of those small Crestron details that can waste time if it is not documented.

What We Learned About VS2022 vs VS2008

One of the useful discoveries was the toolchain boundary.

The Visual Studio 2022 path could generate a module that compiled for 4-Series. That part worked. We also found a GitHub approach that appeared to offer a way to make a modern VS2022 workflow compile for both 3-Series and 4-Series.

In practice, that approach did not work the way it was intended for this SIMPL# library and SIMPL+ wrapper path. The modern output still did not give us the 3-Series-compatible result we needed.

The working path was the older Crestron SIMPL# workflow:

  • Visual Studio 2008 Professional
  • Visual Studio 2008 SP1
  • Crestron SIMPL# Components Program 2.000.0058.01
  • SIMPL Windows and SPlusCC.exe
  • Include4.dat Version 2.21.252

Using the VS2008 Crestron SIMPL# plugin, the module compiled cleanly for the older 3-Series target and also gave us a clean 4-Series path.

That was the real unlock. The code generation was fast, but the right Crestron-era packaging toolchain made the module usable.

Why The Driver Uses Crestron Sockets

The final 3-Series driver uses:

Crestron.SimplSharp.CrestronSockets.TCPClient

Instead of leaning on higher-level .NET HTTP behavior, the driver sends raw HTTP/1.0 GET requests to the camera.

That kept the implementation closer to what the 3-Series SIMPL# environment accepts. It also made the behavior easy to inspect: open a socket, send the command, close the connection, read the status, and publish feedback to SIMPL Windows.

For this project, that was the right level of control.

The Onsite Adjustment: Auto-Tracking vs Manual Control

The main onsite lesson was not a failed module. It was a camera behavior detail.

Auto-tracking can take control priority away from manual PTZ movement. When auto-tracking was active, normal camera movement commands did not behave the way they would in a purely manual mode.

The fix was to reissue the control path with auto-tracking turned off before sending the manual camera command.

In practical terms, the onsite lesson was:

  1. If manual PTZ control does not respond as expected, check whether auto-tracking is active.
  2. Send the auto-tracking off command.
  3. Reissue the pan, tilt, zoom, or preset command.
  4. Use feedback such as AutoTrackingOn_Fb, LastStatus_Fb, and LastResponse_Fb to confirm what happened.

That is exactly the kind of small field detail that belongs in the module notes. The code can be right and the camera can still have a mode that changes command behavior.

The module includes direct auto-tracking controls and a fallback preset-style approach:

150 = tracking on
151 = tracking off

That gives the programmer more than one path when firmware behavior or camera settings vary.

Build Validation

The successful build loop was:

  1. Build the SIMPL# driver in the VS2008 Crestron SIMPL# project.
  2. Copy PTZOpticsG3Driver.clz beside PTZOpticsG3Module.usp.
  3. Compile the SIMPL+ wrapper for the target series.

For 3-Series validation:

SPlusCC.exe \rebuild ".\PTZOpticsG3Module.usp" \target series3

Expected result:

Total Error(s): 0
Total Warning(s): 0

The important point is that the build result came from the Crestron compiler, not just from a C# editor saying the source looked valid.

Configuration Notes

For a simple no-auth deployment test, start with:

_CameraHost = 192.168.1.50
_Port = 80
_UseAuthentication = 0
_TimeoutSeconds = 3
_PanSpeed = 10
_TiltSpeed = 10
_ZoomSpeed = 4

Use only the host or IP address for _CameraHost.

Do not include:

http://

A practical test order is:

  1. Pulse _Initialize.
  2. Pulse _Poll.
  3. Watch Connected_Fb, CommandError_Fb, AuthRequired_Fb, LastStatus_Fb, and LastResponse_Fb.
  4. If auto-tracking is enabled, turn it off before manual movement testing.
  5. Test _PanLeft.
  6. Pulse _PanTiltStop.
  7. Test _ZoomIn.
  8. Pulse _ZoomStop.
  9. Recall _Preset1Recall.

That order separates network reachability, camera mode, movement control, zoom control, and preset behavior.

Authentication Notes

The current 3-Series build supports:

  • No HTTP authentication
  • HTTP Basic authentication

Digest authentication is still the caution area. The modern source work could compile in some forms, but it did not produce the 3-Series library result we wanted through this workflow.

If a camera returns HTTP 401 in the field, the practical paths are:

  1. Use no-auth for the control network path where appropriate.
  2. Use Basic authentication if the camera firmware allows it.
  3. Handle Digest outside this exact 3-Series SIMPL# library path if Digest is mandatory.

That is not a mark against the module. It is a boundary worth documenting before someone is onsite with a processor, a camera, and a deadline.

Why This Was A Win

This was a successful automated AV development workflow:

  • We generated the driver and wrapper structure.
  • We validated the command set against PTZOptics G3 HTTP-CGI behavior.
  • We found the practical limit of the VS2022 route for this target.
  • We moved to the VS2008 Crestron SIMPL# path that actually served the 3-Series requirement.
  • We compiled cleanly.
  • We preserved the reusable module pattern.
  • We captured the onsite auto-tracking behavior that affected manual camera control.

That is the workflow I want more AV projects to have: build fast, compile against the real toolchain, test the field behavior, and feed the lesson back into the documentation.

The module itself is useful, but the bigger win is the repeatable pattern. SIMPL# can own the device logic, SIMPL+ can stay as the wrapper, the Crestron compiler can be the build gate, and the field notes can keep the next deployment from relearning the same little details.