Fix a trace AccessViolation in the CODESYS simulator

What the two log entries say

Log in to the simulated application, open the PLC log, and note what is already there so the new lines stand out. Press the trace start button once. Two entries appear together:

SOURCEPOSITION App= [Sim.Device.Application] area=0, offset=1206309
EXCEPTION [AccessViolation] occurred: App= [Sim.Device.Application] , Task= [VISU_TASK]

Four fields carry the diagnosis:

• App names the application whose loaded image faulted.
• Task names the task running at the fault, here VISU_TASK, the visualization task. Your trace samples on Main Task; the button action that starts the trace executes as visualization work, so the fault sits on that path.
• AccessViolation marks an invalid memory access inside the running image.
• area and offset locate the failing instruction in this build of the application. A recompile moves them, so read the pair from the download you are testing.

Permissions are the wrong track. A rights problem stops the login or the download, and this fault happens after both, in one task at one offset.

Symptoms and what each points to

• Program Loaded - Exception appears when you press start. Compile and download succeeded; the loaded image faulted at runtime. The PLC log is the place to look.
• The exception line names Task= [VISU_TASK]. The fault is on the visualization path. Sampling still runs on Main Task; the start action is the visualization part.
• The WebVisu example also fails in simulation. The simulator has no web server to serve it from.
• The trend example also fails in simulation. Trend storage needs the SQLite database, and the simulator supplies none.
• The same download runs on the physical controller. Application, libraries and device configuration are sound; the fault is specific to the simulation runtime.
• C0315 shows during the build. A string-length warning, handled on its own track below.

Checks, in order

1. Log in and open the PLC log. Note the entries already present.
2. Press the trace start button once. Copy both new lines in full, with App, Task, area and offset.
3. Right-click the SOURCEPOSITION line and choose the jump to the source position. You land either on a line of IEC code or inside a compiled library.
4. Record the landing point. In your code, read the references and the calls on that line. In a library, record the name and version for the report.
5. Press start again. The same area and offset point to one fault at one location; a different offset each press gives you a new pair, one jump each.
6. Switch the device to Control Win, download, and press the same button. A clean log there closes the case.

What the simulator leaves out

Three missing services explain the other failures, and none of them covers the trace fault:

• Web visualization. The simulator contains no web server, so a WebVisu project has nothing to serve from. On real hardware without one, put the HMI on a PC when the controller has no web server. Where a visualization is served at all is decided by the visualization manager and web visualization settings.
• Trend storage. Trends write to an SQLite database and the simulator supplies none. On a runtime that has it, showing the full test duration on a live trend chart is a display setting. A trace holds its samples in memory, so this gap leaves the trace exception unexplained.
• I/O handling. The simulator has no IOManager. Logic tests are fine there; I/O configuration waits for a runtime with one.
• The trace start. A trace start is meant to run in simulation. When it faults in VISU_TASK, the defect is in the simulator's visualization path, and the useful output is a bug report with the log pair and the reduced project.

Scenario: one background, one trace element, two buttons

Build the smallest project that still presses the failing button. The help file program is enough:

PROGRAM PLC_PRG
VAR
    bStart : BOOL;
    bStop  : BOOL;
    iHugo  : INT;
END_VAR
iHugo := iHugo + 1;

One counter gaining 1 each cycle gives the trace a moving signal with no I/O. Put one trace element and two buttons on a background, set the trace variable to PLC_PRG.iHugo, set the trace task to Main Task, and wire the buttons to the help file start and stop actions. When a button needs to do more, you can call a method from an HMI button with ST code.

Set Main Task to 20 ms for the test. The counter gains 50 per second (1000 ms ÷ 20 ms = 50), and a trace of 500 samples covers 10 s (500 ÷ 50 per s = 10 s).

Now reproduce. Run in simulation without touching the buttons and the log stays quiet. Press start: the IDE header flips to Program Loaded - Exception, and the log gains the pair; in the case build it read area=0, offset=1206309. Right-click the SOURCEPOSITION line and the jump lands on the button action's path. Switch the device to Control Win, download, press start: the counter climbs at 50 per second, the trace fills 500 points in 10 s, and the log stays clean. That contrast is the diagnosis. The project is sound; the simulator's visualization path faulted.

The C0315 string warning

The build printed C0315: a string variable named pszName is too short for the value assigned to it. Open the complete message and use its jump to the code position.

• The position is your declaration: widen the STRING type or assign a shorter value.
• The position is in a library: leave the library alone and record the warning text and library version for the report.
• The message names generated code: note it and move on. The load completed with the warning present, so it blocks nothing at download time.

Keep C0315 on its own track. It is a compile-time item; the crash lives in VISU_TASK at runtime.

The fix and the report

Keep the simulator for logic that needs no visualization, no trend database and no I/O. Everything visual moves to Control Win:

1. Change the project's device to Control Win. Application, libraries and trace configuration stay as they are. Control Win is a soft PLC runtime on the same PC, and if a project stays on one, finding a soft PLC runtime cycle time limit with a load sweep sets its ceiling.
2. Download, log in, press the trace start button. The trace fills and no exception pair appears. That is the check that the fix holds.
3. To run on the physical controller, change the device again and run the device update. The application does not change.
4. Send the bug report: both log lines in full, the reduced project, the CODESYS version, here 3.5 SP5 patch 1 on a 32-bit Windows virtual machine, and the library the jump landed in.

The fault in this case survived a full reinstall of the development platform, so put that step away. If the visualization window on Control Win opens grey and reports a client timeout, that is a follow-on runtime issue with its own fix in Control Win Visu_PRG client timeout after a switch.

Recommendation: Confirm the fault from the log pair before changing anything, then test every trace, trend and visualization element on Control Win or the physical controller. Use the simulator for pure logic, and send the log pair with the reduced project so the trace-start fault reaches the vendor's bug tracker.

Questions