I finally had to abandon VB6 and move to Visual Studio. Just downloaded Visual Studio Community and worked my way through some tutorials and now have reconstructed my present project. I have a MSP430f169 microcontroller programmed for data acquisition and a Visual Studio program that displays the immediate values in text boxes and accumulated data in charts.
Now I need to get the data from the micro into the PC for display. I got a USB interface board from Spark Fun and used it with VB6. But I’m stuck in Visual Studio. The code is:
Public Sub USBRcv()
USBPort = New SerialPort()
USBPort.PortName = "COM7"
USBPort.Open()
workString1 = USBPort.ReadLine()
If workString1 = Not (Nothing) Then
txtBoilerT.Text = workString1.Substring(0, 4)
txtFunnelT.Text = workString1.Substring(4, 4)
USBPort.Close()
End If
End Sub
The program runs and displays the charts and text boxes with some initial data but stops where I try to read the USB port. It doesn’t throw an exception. It just stops. The data payload is 32 characters long. I want to parse out the first 8 characters to give me two values.
SerialPort.ReadLine() waits until it gets an EOL sequence, which by default for this object is VBLf or CHR(10). Does your device transmit data with that line ending? If not you’ll need one of the other SerialPort.Read*() varieties. See
I also find this line If workString1 = Not (Nothing) Then
highly suspicious. It might compile but it probably doesn’t do what you think it does.
I’ve not written VB.Net for a living since 2004, but at least back then the best idiom for null comparisons in VB was If not workString1 Is Nothing Then
They later added the IsNot convenience operator so you can now write If workString1 IsNot Nothing Then
Last of all, you issue an .Open() but if you get Nothing back from your ReadLine() you don’t issue a corresponding .Close(). That’s a recipe for problems.
I’d use the try / finally pattern to ensure .Close() is always called. I’m frankly surprised the SerialPort class doesn’t implement IDisposable so you could use the Using syntax shortcut.
IF your device does transmit a reliable line ending but it isn’t VBLf = LineFeed, you can configure your SerialPort object to recognize that ending via the SerialPort.NewLine property.
Last of all, if this is some kind of instrumentation where you intend to read from the device repeatedly over the lifetime of the program execution, you don’t want to be creating and destroying SerialPort objects for each attempted read. Lots of ways for the OS to get unhappy about that.
Instead, make one SerialPort object at program start, open it once, read from it in whatever sort of loop or event triggerer or … then when the program is about to end you can .Close() it followed by letting it deallocate = fall out of scope.
.ReadLine() returns a System.String. That is a sequence of Unicode characters in UTF-8. Does your device transmit data as UTF-8 or does it transmit raw bytes and you’ve fallen into the age-old trap of assuming byte = character and that a string is simply a sequence of bytes? Those are dangerously faulty assumptions for about 20 years now.
If it transmits bytes, use the .Read(byte[], ...) overload to obtain the number of bytes you want. If you do want to end up with Unicode characters you can then convert the byte array into a Unicode string using one of the text encoding methods.