Home/ Questions/Q 3759868
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-05-19T10:23:00+00:00

VB.NET, .NET 4 Hello all, I have an application that controls an industrial system.

  • 0

VB.NET, .NET 4

Hello all,

I have an application that controls an industrial system. It has a GUI which, once a process is started, principally displays the states of various attached devices. It basically works like this:

  • A System.Timers.Timer object is always running. At each Elapsed event, it polls the devices for their current values and invokes controls on the GUI, updating them with the new values.
  • A start button is clicked, a process time Stopwatch object is created and started (Labels on the GUI are now invoked and updated on the System.Timers.Timer’s Elapsed event, in addition to the other work that is taken care of on this event)
  • A new thread is created which runs a Process() subroutine
  • Some Stopwatch objects are created and started (these Stopwatches are periodically restarted during the process via their Restart() method.
  • Some logic is executed on the new Stopwatchs’ Elapsedmilliseconds properties to determine when to do things like write new setpoints to the devices, update the data log, etc…

Here’s my problem: The program occasionally freezes. My ignorant efforts at tracking down the problem have led me to suspect that read/writes to the subset of devices that are RS-232 controlled are the culprits most of the time. However, I occasionally see other strange things upon program freeze, e.g., one of the time Labels whose Text property is determined by a Stopwatch’s Elapsedmilliseconds property sometimes will show an impossible value (e.g., -50 hours or something).

For the RS-232 problems, I suspect something like a read event is being executed at the same time as a write event and this causes a freeze(?). I tried to prevent this by making sure that all communication with an RS-232 device is funneled through a Transmit() subroutine which has the following attribute:

Which, as far as my ignorance permits me to understand, should force one Transmit() execution to finish completely before another one can start. Perhaps another risk is the code getting blocked here if one Transmit() never finishes?

Regarding the Stopwatch trouble, I speculate that the problem is that the Timer is trying to update a GUI Label at the same time that the Stopwatch’s Restart() method is being executed. I’m unsure if this could cause a problem. All I know is that this problem has only occurred at a point in the process when a Restart() call would be made.

I am wondering if I could use a SyncLock or something to lock a Stopwatch while the Label is being updated (or, conversely, while its being restarted)? Or, perhaps I should stop the Timer, restart the Stopwatch, and then start the timer again, like so?:

Timer.Stop
Stopwatch.Restart
Timer.Start

My trepidation regarding how to proceed is due to my complete lack of understanding of how .NET synchronization objects actually work. I’ve tried slapping a few SyncLocks in various places, but I really have no idea if they’re implemented correctly or not. I’m wondering if, having provided all this context, someone really smart might be able to tell me how I’m stupid and how to do this right. I would really appreciate any input. If it would be useful to provide some code snippets, I’d be happy to, I just worry that everything’s so convoluted that it would just detract from what I’m hoping is a conceptual question.

Thanks in advance!
Brian

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    I would consider a shift to a task scheduling framework instead of relying on manual manipulation of timers if your working on anything SCADA related. A simple starting point would be something similar to the hardcodet.Scheduling classes and you can move to something like the beast that is Quartz. Most of these types of frameworks will provide you with a way to pause and resume scheduled actions.

    If I’m working with Modbus, I normally keep a local cache of the register values and make changes to any value fire a change event. This has the benefit of allowing you to implement things like refreshing values manually without interfering with your process scheduling and checking for deadband when evaluating your polled response. This happened to be the side effect of implementing a polled protocol to a subset of the OPC DA interface.

    • 0