Sys_Process_Command2 output in IEC shows nothing: fix it

Why does the visualization show nothing when Sys_Process_Command2 runs?

A blank visualization with a running application means the call produced nothing for it to show: the runtime either refused the command or the call failed before any text was captured. Both cases leave the display untouched, and the list below tells them apart.

Match your case against these before changing anything:

• Nothing ever displayed, from the first call: command authorization, the [SysProcess] entries.
• The shell prints output but the capture stays empty: execution context or the wrong output stream.
• Text arrives but the parsed value stays at 0: conversion.
• The parsed value updates but the display does not: binding.
• The value shows for a while and then freezes: a failed call leaving stale data on screen.

The rest of this article takes the stages in that order.

Which SysProcess configuration entries authorize a shell command?

The [SysProcess] section of the runtime configuration authorizes command execution: Command=AllowAll permits every command, and a numbered entry such as Command.0=shutdown names one specific command. The failing installation carried both lines together, and the display stayed empty until the extra line was removed.

The combination that fails:

[SysProcess]
Command=AllowAll
Command.0=shutdown

The configuration that restored the display:

[SysProcess]
Command=AllowAll

AllowAll means what it says: the runtime executes any command the application sends. The numbered entry was a leftover naming the shutdown command, and with the two lines together the visualization received nothing. Why the runtime ranks the entries is internal to it; the fix that worked is the deletion, and it took one edit.

Two follow-ups decide whether the fix holds:

Load the file the runtime actually reads. Editing a spare copy changes nothing on the controller. Apply the edit through your runtime's documented configuration procedure, restart, and read the startup diagnostics: a configuration error there means the edit never took effect.

Treat AllowAll as a bench setting. It authorizes destructive commands as readily as read-only ones, the shutdown entry in the failing configuration being a live example. Once the display works, name the individual commands your screen calls in the same section, and keep AllowAll for the workbench.

Does the command work outside the runtime?

Run the exact command text in the operating system shell and read its output before you debug anything in the IEC code: a command that prints nothing in the shell prints nothing through the runtime, and no binding change repairs that.

Record three things from the shell: the command text, its output, and its exit status. Keep the record, because you will compare the raw capture against it two stages later.

A passing shell test leaves two context checks:

• The runtime service can run under a different account, working directory and environment from your interactive login. Confirm the executable and any input files exist at absolute paths on the controller, and check the service account's permission to read what the command reads.
• The command can depend on a shell feature: a pipe, redirection or environment expansion. The installed function documentation states whether the call launches a shell or starts the executable directly. If it starts the executable directly, move the pipeline into a script file and call the script instead.

One safety note belongs here. Test with a read-only command whose output you recognize on sight: authorization settings make whatever you configure executable, and the shutdown entry in the failing configuration was a real, authorized command.

What reaches IEC code before you parse it?

Three different things arrive from one call: the execution status, the raw captured text, and your parsed value. Keep them separate in the application, and inspect the raw text before you trust any number.

Read the declaration of Sys_Process_Command2 in the installed library before anything else. Its arguments, its return semantics and its output-buffer capacity are written there, and the declaration on your controller outranks any example copied from another install.

Keep three separate variables: the execution status, the raw captured text, and the parsed value. A return value is a status. Read it as a temperature only where the declaration defines it that way.

Standard output and standard error are separate streams, and a failing command often writes its complaint to standard error while standard output stays empty. The declaration states which stream the capture holds, and that decides whether an empty capture means nothing ran or the text went to the other stream.

Watch one call end to end in the runtime's watch view: the status first, then the raw text, before any conversion. The same empty-capture symptom on the sibling call that launches Python scripts has its own walkthrough at Fix SysProcessExecuteCommand2 not returning Python output.

Why does the screen show a wrong or frozen value?

A wrong number is a parsing fault and a frozen number is a publishing fault: the raw text converted with the wrong scale or unit, or a failed call leaving the last good reading on the screen. The change pattern in the watch view tells you which.

Convert one line by hand before touching the conversion code. CPU information can arrive as descriptive text, and a temperature arrives with a unit, a scale and a line ending of its own. For example, a raw 43500 against an expected 43.5 °C means a factor of 1000 hides in the scale: the parse divides by 1000 and the display reads correctly. Confirm the unit against the interface documentation for your operating system.

Publish with a validity flag. A failed call or a rejected parse sets the flag and marks the displayed value stale; the last good number stays visible with its flag, never silently as current.

The change rule decides the stage:

• Raw text changes, parsed value frozen: the conversion.
• Parsed value changes, display frozen: the binding. The mechanics of putting application values onto a screen are in Display PLC configuration values in a visualization.
• Neither changes: go back to the [SysProcess] entries and the shell test. Formatting cannot repair a call that produces no data.

Example: how often can the screen read the CPU temperature?

Take a monitoring task that calls the command once every 10 s and a logic task that runs every 2 ms: a 50 ms blocking call inside the logic task misses 25 of its cycles, while inside the 10 s task it occupies 0.5 percent of the interval.

Example. A plant screen shows CPU temperature beside the line status. The logic task runs at 2 ms; your task configuration prints the real period, and 2 ms is a common fast setting. The temperature command takes 50 ms on this controller, measured once from the shell; simple read commands usually finish in tens of milliseconds, and yours is the number that counts. Check the installed declaration on whether the call blocks until the command completes, and assume it blocks for this arithmetic.

• Placed in the 2 ms logic task: one call overruns the cycle by 50 - 2 = 48 ms and misses 50 / 2 = 25 task periods. The logic stutters once per read and the watchdog sees a real overload.
• Placed in a monitoring task with a 10 s period: the same call occupies 50 / 10,000 = 0.005 of the interval, 0.5 percent, and the fast logic never waits.

A temperature board gains nothing from faster reads. Call the command once every 10 s in its own task, publish only completed and parsed results, and leave the fast task alone. If you are moving slow work out of the cyclic program, Move cycle-end data transfers out of the CoDeSys program applies the same pattern to data transfers. And if the whole runtime slows down instead of one task, that is a different fault: Runtime process hits 100 percent CPU a minute after startup covers that case.

What order do you check the stages in?

Work the five stages in order: [SysProcess] authorization, the shell test, the raw captured text, the parsed value, the visualization binding. Stop at the first stage that fails, because a fault there explains the whole symptom without work in the stages behind it.

1. Reduce [SysProcess] to the single line Command=AllowAll and reload the runtime configuration by its documented procedure.
2. Run the command in the shell; record its text, output and exit status.
3. Watch the execution status and the raw captured text from one call in the IEC application.
4. Convert one line by hand and confirm the scale and the unit.
5. Check the visualization binding against the parsed variable.

Recommendation: delete the extra entry first: on an installation showing this symptom, reduce [SysProcess] to the single line Command=AllowAll, reload the runtime configuration by its documented procedure, and retest before touching the IEC code. Once the display works, replace AllowAll with named entries for just the commands the screen calls, and keep the read in its own 10 s task so the 2 ms logic never waits on a 50 ms command.

Questions