Setting a manual timeout in VB.NET - vb.net

I have a vb.net application that interfaces with some external hardware - an array of motor controllers. To do this, I'm using a CANOpen library provided by the hardware supplier. However, the timeouts built into the library are frankly excessive, and cause the application to hang painfully under specific conditions. I'd prefer not to need to edit the library if possible.
What's the most sensible way to design in another, shorter timeout within vb.net? The function in question is a blocking function, so presumably in-thread timers won't help. Is there an elegant solution here?

Give this a try, it's is the best I could come up with so far. I've used background workers just because they are easy to use.
Basically it's a thread within a thread which will at least keep your UI responsive, judging by what you've said you should probably use threading for all the drive comms functions anyway in case a drive loses comms for any reason while the app is running.
This ain't pretty, but it will at least allow you to exit out early before the CAN function itself times out.
Private connected As Boolean
Private Sub bwTryConnect_DoWork(ByVal sender As Object, ByVal e As System.ComponentModel.DoWorkEventArgs) Handles bwTryConnect.DoWork
Dim timeout As Boolean
Dim timeoutCount As Integer
Dim timeoutValue As Integer = 5 ' timeout value
bwConnect.RunWorkerAsync() ' start worker to try connection
While bwConnect.IsBusy And Not timeout
Thread.Sleep(1000) ' wait a second
timeoutCount += 1 ' increment timeout value
If timeoutCount = timeoutValue Then timeout = True ' connection timed out
End While
' connected will be true if the try connection worker completed (connection to drive ok) before the timeout flag was set, otherwise false
connected = Not timeout
End Sub
Private Sub bwConnect_DoWork(ByVal sender As Object, ByVal e As System.ComponentModel.DoWorkEventArgs) Handles bwConnect.DoWork
' use your CAN library function here - either a simple connect command or just try reading an arbitary value from the drive
' if you want to test this, uncomment one of the following lines:
'Thread.Sleep(20000) ' simulate timeout
'Thread.Sleep(2000) ' simulate connect
End Sub
Obviously you then call with bwTryConnect.RunWorkerAsync().

Related

How to properly interact with UI in threading in VB.NET

I'm new to VB.NET threading
As for simple testing I tried the following, which I need to smoothly fill a listbox with values.
But it does not work as I expect, it hangs the interface. Please let me know what I'm doing wrong here.
Thank you.
Imports System.Threading
Public Class Form1
Private Sub Button1_Click(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles Button1.Click
Dim Thr As Threading.Thread
Thr = New Threading.Thread(New Threading.ThreadStart(AddressOf tprocess))
'Thr.SetApartmentState(ApartmentState.STA)
Thr.IsBackground = True
Thr.Start()
End Sub
Private Delegate Sub DoStuffDelegate()
Private Sub tprocess()
Dim i As Integer
For i = 0 To 20000
If Me.InvokeRequired Then
Me.Invoke(New DoStuffDelegate(AddressOf tprocess))
Else
ListBox1.Items.Add(i)
End If
Next
End Sub
End Class
When you write code to create a thread then you always have to worry about the kind of bugs that threading can cause. They are very hard to diagnose, the only decent way to address them is to know they exist and to write the code carefully so you know how to avoid them.
The most common threading bugs are threading races, deadlock and firehose bugs. You have the 1st and the 3rd bug in your code. You are complaining about the 3rd. Very quickly: the threading race bug is using Me.InvokeRequired. You have no guarantee that it is still true when the Me.Invoke() statement executes. This goes wrong when the user closes the window while your thread is still running. When you try to fix this problem you'll get to see what the 2nd bug looks like. But you are not there yet.
The firehose bug is the Me.Invoke() call. Very fast, takes less than a microsecond of work for the worker thread, you do it 20000 times at a very high rate. It is however another thread that must actually do the work of adding the item, your UI thread. That is not fast, it not only has to add the item but it also needs to repaint the control. Many microseconds.
While this goes on, your UI thread is burning 100% core, trying to keep up with the relentless rate of invoke requests. Working as hard as it can to add items to the listbox. Something has to give, while it is doing this it is not taking care of the lower priority jobs it has to do. Painting and responding to user input. In effect, your UI looks completely frozen. You can't see it paint anymore and trying to, say, close the window doesn't work. It isn't actually dead, it is hard at work.
Takes a while, probably a few handful of seconds, give or take. Until the worker thread finishes its for() loop and stops slamming the UI thread with invoke requests. And everything turns back to normal.
A firehose bug like this is pretty fundamental. The only way to fix it is to call Invoke() less often or at a lower rate. Note how putting Thread.Sleep(50) after the Invoke() call instantly fixes it. But of course that slows down your worker thread a lot. You call Invoke() less often by using AddRange() instead of Add(), adding (say) 1000 items at a time. Which is the proper fix but now it becomes fairly pointless to still try to update the listbox from the worker thread. Might as well do it with a single AddRange() call. The quickest way.
Try changing:
Thr = New Threading.Thread(New Threading.ThreadStart(AddressOf tprocess))
to this:
Thr = New Threading.Thread(AddressOf tprocess)
ThreadStart will start that thread immediately
I tried the following way. It's almost easy for me to handle. Backgroudworker manages this situation perfectly well.
Private Sub BackgroundWorker1_DoWork(ByVal sender As System.Object, ByVal e As System.ComponentModel.DoWorkEventArgs) Handles BackgroundWorker1.DoWork
Dim i As Integer
For i = 1 To 20000
BackgroundWorker1.ReportProgress((i / 20000) * 100, i)
Threading.Thread.Sleep(1)
Next
End Sub
Private Sub BackgroundWorker1_ProgressChanged(ByVal sender As Object, ByVal e As System.ComponentModel.ProgressChangedEventArgs) Handles BackgroundWorker1.ProgressChanged
ProgressBar1.Value = e.ProgressPercentage
ListBox1.Items.Add(e.UserState)
End Sub
Private Sub BackgroundWorker1_RunWorkerCompleted(ByVal sender As Object, ByVal e As System.ComponentModel.RunWorkerCompletedEventArgs) Handles BackgroundWorker1.RunWorkerCompleted
MsgBox("Complete")
End Sub

Catch Timeout in DownloadFileAsync

I am having a problem with timeouts in my DownloadFileAsync function. I am using VB.NET. According to multiple sources the "DownloadFileCompleted" event should be raised when the connection to the server while downloading is lost and the error flag should be set. Nothing of this is happening. I am trying this through starting the download and then simply stopping my internet connection through disabling WLAN.
Private Sub DownloadMod_DownloadFileCompleted(ByVal sender As Object, ByVal e As System.ComponentModel.AsyncCompletedEventArgs) Handles DownloadMod.DownloadFileCompleted
MsgBox("Test1")
If e.Error IsNot Nothing Then
MsgBox("Test2")
End If
End Sub
Neither the test1 nor the test2 message box is appearing after loosing connection. I read that the standard timeout is 100 s, so I always waited 2 minutes to make sure, but nothing is happening.
This is how I start the download:
DownloadMod.DownloadFileAsync(New System.Uri("http://linktothefile.com/downloadfile.txt"), System.AppDomain.CurrentDomain.BaseDirectory & "Downloads\downloadfile.txt", Stopwatch.StartNew)
The stopwatch is in there for calculation of the download speed.
Downloadmod is defined like this:
Private WithEvents DownloadMod As New Net.WebClient
I would appreciate if someone could help me with this problem.
Turin

AcessViolationException was unhandled VB.net

So I have this form that loads a page, and after the page is loaded I want to insert the source into RichTextBox1.Text
However after the page load the program crashes(?) and gives me this error
"An unhandled exception of type 'System.AccessViolationException' occurred in Awesomium.Windows.Forms.dll
Additional information: Attempted to read or write protected memory. This is often an indication that other memory is corrupt."
This is my code and it is worth mentioning that I am using awesomium for this!
Public Class Form1
Dim Thread As System.Threading.Thread
Dim html_source_code As String = ""
Private Sub Form1_Load(sender As Object, e As EventArgs) Handles MyBase.Load
Control.CheckForIllegalCrossThreadCalls = False
Thread = New System.Threading.Thread(AddressOf Load_Page)
Thread.Start()
End Sub
Private Sub Load_Page()
While html_source_code = ""
If WebControl1.IsDocumentReady Then
html_source_code = WebControl1.ExecuteJavascriptWithResult("document.documentElement.outerHTML").ToString()
RichTextBox1.Text = html_source_code
End If
End While
End Sub
Private Sub Button1_Click(sender As Object, e As EventArgs) Handles Button1.Click
Thread = New System.Threading.Thread(AddressOf Load_Page)
Thread.Start()
End Sub
End Class
Thanks in advance!
Here is your first clue...
Control.CheckForIllegalCrossThreadCalls = False
This is a pretty obvious red flag. You should never use this except perhaps for very specific debugging purposes, and for very good reason. Given that the remainder of your code is full of illegal cross thread calls, it's no wonder your program is crashing.
Every single line of code you have written that is executed in a worker thread is touching UI components. You cannot do this. See this post for examples : Cross-thread operation not valid
UI controls are continuously operated on by the main thread of your application. The main thread must be able to access them to handle their associated events, draw them to the screen, etc. If another thread is modifying their contents while the main thread is attempting to read or write to them then bad things happen.
Consider a text box that the main thread is attempting to draw to the screen. It obtains a reference to the location of the string that contains the textbox's text and, in the middle of reading the string, another thread modifies the string, invalidating the reference that the main thread is using. When the main thread tries to read, its existing reference now points to an invalid memory location and, voila, access violation.
In almost all circumstances you should never, ever set CheckForIllegalCrossThreadCalls to False. Leaving it set True will raise an exception, but it gives you the opportunity to see where the problematic code is and allows you to correct it. Setting it False simply hides the illegal call, which may or may not fail, and your application will be vulnerable to random, buggy failures when those illegal calls end up causing problems. Suggest you do some reading about how to write multithreaded .NET applications. A good start would be here : StackOverflow Search.
See also : How to: Make Thread-Safe Calls to Windows Forms Controls

How to make a very simple asynchronous method call in vb.net

I just have a simple vb.net website that need to call a Sub that performs a very long task that works with syncing up some directories in the filesystem (details not important).
When I call the method, it eventually times out on the website waiting for the sub routine to complete. However, even though the website times out, the routine eventually completes it's task and all the directories end up as they should.
I want to just prevent the timeout so I'd like to just call the Sub asynchronously. I do not need (or even want) and callback/confirmation that it ran successfully.
So, how can I call my method asynchronously inside a website using VB.net?
If you need to some code:
Protected Sub Page_Load(ByVal sender As Object, ByVal e As System.EventArgs) Handles Me.Load
Call DoAsyncWork()
End Sub
Protected Sub DoAsyncWork()
Dim ID As String = ParentAccountID
Dim ParentDirectory As String = ConfigurationManager.AppSettings("AcctDataDirectory")
Dim account As New Account()
Dim accts As IEnumerable(Of Account) = account.GetAccounts(ID)
For Each f As String In My.Computer.FileSystem.GetFiles(ParentDirectory)
If f.EndsWith(".txt") Then
Dim LastSlashIndex As Integer = f.LastIndexOf("\")
Dim newFilePath As String = f.Insert(LastSlashIndex, "\Templates")
My.Computer.FileSystem.CopyFile(f, newFilePath)
End If
Next
For Each acct As Account In accts
If acct.ID <> ID Then
Dim ChildDirectory As String = ConfigurationManager.AppSettings("AcctDataDirectory") & acct.ID
If My.Computer.FileSystem.DirectoryExists(ChildDirectory) = False Then
IO.Directory.CreateDirectory(ChildDirectory)
End If
My.Computer.FileSystem.DeleteDirectory(ChildDirectory, FileIO.DeleteDirectoryOption.DeleteAllContents)
My.Computer.FileSystem.CopyDirectory(ParentDirectory, ChildDirectory, True)
Else
End If
Next
End Sub
I wouldn't recommend using the Thread class unless you need a lot more control over the thread, as creating and tearing down threads is expensive. Instead, I would recommend using a ThreadPool thread. See this for a good read.
You can execute your method on a ThreadPool thread like this:
System.Threading.ThreadPool.QueueUserWorkItem(AddressOf DoAsyncWork)
You'll also need to change your method signature to...
Protected Sub DoAsyncWork(state As Object) 'even if you don't use the state object
Finally, also be aware that unhandled exceptions in other threads will kill IIS. See this article (old but still relevant; not sure about the solutions though since I don't reaslly use ASP.NET).
You could do this with a simple thread:
Add :
Imports System.Threading
And wherever you want it to run :
Dim t As New Thread(New ThreadStart(AddressOf DoAsyncWork))
t.Priority = Threading.ThreadPriority.Normal
t.Start()
The call to t.Start() returns immediately and the new thread runs DoAsyncWork in the background until it completes. You would have to make sure that everything in that call was thread-safe but at first glance it generally seems to be so already.
I also was looking for information on Asynchronous programming in VB. In addition to this thread, I also found the following: beginning with Visual Studio 2012 and .Net Framework 4.5, VB was given two new keywords to make a method asynchronous right in the declaration, without using Thread or Threadpool. The new keywords are "Async" and "Await". You may refer to the following links if you wish:
http://msdn.microsoft.com/library/hh191443%28vs.110%29.aspx
https://msdn.microsoft.com/en-us/library/hh191564%28v=vs.110%29.aspx
This is an older thread, but I figured I'd add to it anyway as I recently needed to address this. If you want to use the ThreadPool to call a method with parameters, you can modify #Timiz0r's example as such:
System.Threading.ThreadPool.QueueUserWorkItem(Sub() MethodName( param1, param2, ...))

Console CTRL-C handling when using serial port fails

Using VB.Net I've added a CTRL-C handler:
AddHandler Console.CancelKeyPress, AddressOf QuitHandler
Which does the following:
Private Sub QuitHandler(ByVal sender As Object, ByVal args As ConsoleCancelEventArgs)
Console.WriteLine("Quitting...")
args.Cancel = True
Quit = True
End Sub
I then have a main loop which just runs until Quit=True.
This all works until I start reading from the serial port:
Private Sub port_DataReceived(ByVal sender As Object, ByVal e As System.IO.Ports.SerialDataReceivedEventArgs) Handles Port.DataReceived
at which point the CTRL-C handler gets ignored for about 30secs at which point the console app just terminates without going through the cleanup code.
Why?
I don't know VB, but my guess would be that you're attempting to read data from the serial port that isn't there (err, the port is there, the data isn't); as a result, your program is blocking ("hanging") until the read attempt times out after 30 seconds.
If I'm correct, you need some way to poll your serial input without blocking, or (better) to get an asynchronous sub called when data actually appears.
You should make sure to understand how Timeouts work, since you are reading serial port on pooling. Your serial thread will always be running and trying to read something.
A best approuch would be to read data just when its availiable, then your serial thread would have time to breath.
You can also try to use DoEvents.