Why does the STX8092 reject Visual.NET DAQ commands?

On the reported CUBE STX8092 D1, changing the example’s device identifier to STX8092 does not enable DAQ: this variant supports PLC mode only, so a DAQ command returns ErrorCmdUnsopportedInPLC. Use the PLC-mode UDP path for the D1, and treat PC-to-PLC and PLC-to-PC communication as separate paths with separate checks.

Confirm the STX8092 suffix before changing code

The model identifier in the .NET constructor selects how the library addresses the PLC; it does not change the hardware variant’s supported operating modes. Replacing STX8081 with STX8092 can correct a model selection, but it cannot make a PLC-only D1 accept DAQ commands. The returned error identifies an unsupported command in PLC mode, not a failed Windows build or a counter-format problem.

STX8092 suffix	Mode information	Action
C1, C2, D1, or D2	PLC mode only	Use the PLC-mode communication method rather than the DAQ sample.
A1 or A2	DAQ-capable variant	Select DAQ mode in the PLC configuration and restart before using DAQ commands.
Suffix not confirmed	Mode capability is not yet identified	Read the full model suffix from the PLC label or product documentation before choosing the software path.

Do not spend the shift repeatedly editing the constructor, recompiling the same DAQ example, or changing the PLC IP to clear this particular error. Those steps do not change the D1’s mode capability.

Pass check: Record the complete model suffix and match it to the mode in the table. For a D1, proceed with PLC mode; for an A1 or A2, configure and verify DAQ mode before testing the DAQ application.

Choose a communication path the hardware supports

For a confirmed D1, keep the controller in PLC mode and use the UDP data-transfer approach described in Application Note AN001. The note includes examples for sending data from the PC to the PLC and from the PLC to the PC. A successful PC-to-PLC test proves only that direction; it does not prove that the PLC can reach the PC’s receive port or that Windows allows the application to receive packets.

For an A1 or A2 that needs the DAQ example, select the mode in StxLadder rather than trying another device identifier:

1. Open the PLC configuration in StxLadder and navigate to PLC > Configure PLC > Other.
2. Select DAQ mode, apply the configuration, and restart the PLC.
3. After the restart, run the DAQ example against the correctly identified model.

A PLC-only unit has no DAQ-mode setting that will turn it into an A1 or A2. If the application must use DAQ-specific commands, the hardware suffix is the decision point; otherwise, keep the D1 in PLC mode and continue with UDP.

Pass check: Confirm that the selected software path matches the suffix and the PLC’s current mode. A D1 should be tested with a PLC-mode example; an A1 or A2 should report the intended DAQ configuration after its restart.

Point PLC transmissions at the PC address

The PLC’s UDP transmit example must target the PC’s local network address. In the sample, 192.168.1.81 is used as the PLC address in the .NET constructor, while 192.168.1.15 is an example PC address in the PLC’s transmit call. They serve different roles. Do not copy the example PC address unless that is actually the address assigned to the PC running the receiver.

The example call has this form:

UdpSend(192,168,1,15, 4980, 5, Data, false)

In the PLC project’s Udp_Tx example, replace the destination address with the PC’s current local IP. Keep the destination port and payload definition aligned with the receiver call. For the illustrated receiver, the call is PioBoard.Cmd.Udp.Receive(4980, 5, Packet); the PLC and PC must agree on the port and the expected data length. The sample’s 5 argument must match the data payload used by that sample; do not change one side’s length without changing and checking the other side.

1. Read the PC address from the network adapter in use for the PLC connection.
2. Set that address in the PLC’s UDP transmit project, not the PLC address.
3. Load the PLC’s Udp_Tx example and run the matching PC receive application.
4. Confirm the receive call returns success before interpreting the packet contents.

A connection that sends PC data into the PLC can still fail in the reverse direction: the transmit destination, listening port, and inbound firewall rule are independent checks.

Pass check: The PLC’s configured destination equals the PC’s current local IP, and the PC receiver reports a successful packet on the configured port with the expected length.

Allow the Windows application to receive UDP

If the PLC’s PC destination and receive port are correct but the PC gets no packet, check the Windows firewall before rewriting the PLC program. The sample application may prompt for network access on first launch. If a previous run was blocked, Windows may already have a blocked rule for the program, so launching it again may not produce a fresh prompt.

1. Run the receiver application. If Windows asks whether it may access the network, allow access for the network on which the PC and PLC communicate.
2. If no prompt appears and the sample still receives nothing, open Control Panel > System and Security > Windows Firewall > Allow an app or feature through Windows Firewall.
3. Select Change settings. If Windows requests administrator credentials, have an authorized administrator make the change.
4. For the sample, remove stale or blocked duplicate entries named Prueba2, then accept the change and launch the application again. When prompted, allow it.
5. For a different receiver, authorize the actual application being run rather than assuming a rule for Prueba2 covers it.

Do not use a PC-to-PLC success as a substitute for this check. A PC can transmit while its firewall still blocks an application’s inbound receive traffic.

Pass check: With the PLC transmit example running, the PC application receives a packet. If packets arrive only after correcting the firewall rule, retain the application-specific allow rule rather than turning off the firewall as a workaround.

Validate the PLC I/O example before judging the display

The STX8092 monitoring example has a PLC-side function as well as a .NET display. The described version reports the state of 12 digital inputs and 12 digital outputs. Its sample logic activates the corresponding DOUT when a DIN turns on and keeps that output on for several additional seconds after the DIN turns off. That delayed output behavior belongs to the example logic; do not mistake it for a display delay or assume it matches the required machine sequence.

Test the PLC logic and the PC display as separate stages:

1. Load the matching PLC program and run the C# monitor on the PC.
2. Choose Activate in the application.
3. Apply a high level to a DIN and check the Entradas view for that input.
4. Check the corresponding DOUT in Salidas, then observe the Log view.
5. Remove the input and account for the example’s several-second output hold behavior.

The example actively drives outputs. Confirm its DIN-to-DOUT mapping and delayed deactivation behavior against the intended test setup before using it on connected machine outputs.

Pass check: A change at a tested DIN appears in the input display, the corresponding output follows the sample logic, and the log records the monitor’s reported state. If the PLC-side output works but the screen does not change, continue with the PC receive and UI-thread checks rather than altering the I/O logic.

Update .NET controls on the UI thread

The monitor’s listener runs in a background task, while labels and other window controls belong to the UI thread that created them. Writing directly to a label from the listener can trigger a cross-thread control exception in Visual Studio’s Debug run. The sample’s Release executable was reported to work, but that is a quick test path, not a safe design fix: changing build configuration does not make cross-thread control access correct.

1. Use the Debug build to expose exceptions while inspecting the listener and its UI updates.
2. For a temporary demonstration check, build the Release executable through Debug > Build Solution and run the generated file in the project’s bin\Release folder, as in the sample workflow.
3. For a maintained application, marshal label, list, and other control updates back to the UI thread using the application’s UI invocation mechanism or a delegate-based handoff.
4. Keep packet reception and parsing in the background worker, but pass parsed values to the UI for display rather than updating controls directly from the receiver.

Release mode can help distinguish a debugger-reported cross-thread access from a PLC communication failure. It does not prove the receive loop is thread-safe, and it should not be used to dismiss errors that occur during production operation.

Pass check: In the Debug build, receive a packet and update the display without a cross-thread exception. Confirm that the displayed value changes for a known input or test value, then check the Release executable separately if it is part of the deployment workflow.

Bound the polling loop and retained display history

The reported monitor polls a PLC Boolean once per second; the PLC sets the bit and the PC resets it after detecting True. A delayed System.StackOverflowException is not explained simply by a finite loop running many times. Stack overflow means the call stack has been exhausted, commonly by recursion or repeated calls that do not return. By contrast, adding every cycle to a ListBox retains more UI items over time and consumes memory; it is a separate growth path to test.

The packet-reading code also contained a redundant loop: it iterated over packet positions but assigned the same byte, Packet(4), on every iteration. If the program needs only that byte, read it once after a successful receive rather than looping across the packet:

If PioBoard.Cmd.Udp.Receive(4980, 5, Packet) = UdpReceiveStat.Success Then
    dataInt = Packet(4)
    lblBitCiclo.Text = dataInt
End If

Use this only for the single-byte bit value shown. It does not decode a multi-byte counter. Diagnose a delayed failure without changing multiple possible causes at once:

1. Capture the exception details and inspect the call stack for recursion, repeated callback entry, or a path that fails to return.
2. Remove the redundant packet loop and test the same receive behavior.
3. Temporarily disable ListBox1.Items.Add(tm) and repeat the run. If that changes the result, bound or clear retained display history, or move long-term records to the application’s logging path.

The monitor was reported stable after corrections, but the lasting fix is to identify which change matters in the current program. A once-per-second polling interval is not evidence of an infinite recursive loop by itself, and an ever-growing list should not be used as an unlimited cycle history.

Pass check: The receiver continues polling beyond the longest previously observed failure window without a stack exception, and the display or log retains only the history the application is designed to keep.

Transmit counters as four ordered bytes

A packet byte can represent only 0 through 255. Reading a counter’s value from one byte therefore cannot preserve counts above 255. The PLC must split a 32-bit value into four bytes, and Visual Basic must rebuild those same four bytes as one 32-bit integer. The example sends the least-significant byte first.

For two counters, the PLC packet layout is eight data bytes:

new Contador1, Contador2
new Packet[8]

Packet[0] = Contador1 & 0xFF
Packet[1] = (Contador1 >> 8) & 0xFF
Packet[2] = (Contador1 >> 16) & 0xFF
Packet[3] = (Contador1 >> 24) & 0xFF

Packet[4] = Contador2 & 0xFF
Packet[5] = (Contador2 >> 8) & 0xFF
Packet[6] = (Contador2 >> 16) & 0xFF
Packet[7] = (Contador2 >> 24) & 0xFF

Reassemble the values from offsets 0 and 4 in Visual Basic:

Dim Contador1 As Integer = BitConverter.ToInt32(Packet, 0)
Dim Contador2 As Integer = BitConverter.ToInt32(Packet, 4)

The byte order must match at both ends. The shown wire order is low byte first; if the receiving computer’s byte order differs from the format expected by the conversion method, reverse the four bytes before conversion or implement explicit byte assembly. Do not infer a counter from only Packet(1) or Packet(4) once its value needs more than one byte.

Match the actual packet length on the two sides. The earlier Visual Basic sample declares Dim Packet(8) As Byte and calls Receive(4980, 9, Packet), while the two-counter PLC layout above uses indexes 0 through 7, or eight data bytes. In Visual Basic, the number in an array declaration is the upper bound, so Packet(8) provides indexes 0 through 8. Do not treat index 8 as part of either four-byte counter; align the receive length with the payload actually transmitted.

Pass check: Transmit a known counter value above 255, rebuild it from the correct four-byte offset, and compare the PC value with the PLC value. Verify the second counter independently at offset 4 and confirm that both ends agree on the packet length and byte order.

Run the complete STX8092 data path

Commission the chain in sequence so a failure has a clear boundary: PLC mode and model, PLC transmit destination, Windows receive permission, packet parsing, then display or logging. A successful physical input response does not prove that the PC decoded the packet correctly; likewise, a displayed number does not prove that the PLC is transmitting the intended counter bytes.

1. Confirm the full STX8092 suffix. For D1, use PLC mode and the UDP path; do not retry DAQ commands.
2. Load the PLC transmit program and verify that its destination is the PC’s current local address, with the intended port and payload length.
3. Allow the receiver application through Windows Firewall and verify that the receive call succeeds.
4. Change one DIN and check the reported input, corresponding sample output, and log entry.
5. Set a known multi-byte counter value, transmit its four-byte representation, and compare the PC’s decoded value with the PLC value.
6. Run the one-second monitor beyond its prior failure interval. Confirm that polling remains stable and that retained display history does not grow without a limit.

For the planned database application, store the decoded 32-bit value rather than a single packet byte. Keep the sample’s I/O behavior, the UDP payload format, and the database update logic as separate test points so a failure in one does not get misdiagnosed as a DAQ-mode problem.

Pass check: The STX8092 reports the expected input state, the PC receives the intended PLC packet, the counter reconstructs correctly above 255, and the monitor remains stable through the test run.

Answer common STX8092 DAQ and UDP questions