Join 306,822 VB.NET Programmers for FREE! Get instant access to thousands of VB.NET experts, tutorials, code snippets, and more! There are 1,757 people online right now. Registration is fast and FREE... Join Now!
My VB.net application is used to display a combination of Ascii characters and numeric data sent from an embedded micro controller. Each block of data received consists of 16 chars Ascii followed by 16 bytes of numeric values. Whenever the program encounters a Hex 1a value (dec 26, Asc SUB) in the numeric block it appears to "crash" for about 10 seconds then recovers. No exceptions are thrown by the de-bugger though. Note that the "1a" value at this point is being processed as a byte value, not an ascii char. Software uses "Windows -1252" unicode char ecoding. Hardware path is: Micro-controller (HCS12X) - FT232 (FTDI USB to "COM3")- VB.net via normal serialport type software. Note that all other data values display perfectly with this one exception. Any ideas greatly appreciated.
Hex 0x1a is the Unix EOF character - ^Z. There is probably a configuration field you are yet missing in the serial port control - I know way back (VB 1 or 2)I had trouble with XOn/XOff (0x13/0x11, ^s/^q) flow control characters appearing in the data.
Hex 0x1a is the Unix EOF character - ^Z. There is probably a configuration field you are yet missing in the serial port control - I know way back (VB 1 or 2)I had trouble with XOn/XOff (0x13/0x11, ^s/^q) flow control characters appearing in the data.
Thanks for the reply Mark. Is the "configuration field' you mention accessed via the SerialPort properties box or some other mechanism?
i have read the first post from RDR... I have exactly the same problem and the same hardware configuration...
i use a microcontroller, a USB to serial cable (with FTDI chip) and a c# application to read data... the problem is with the 0x1a / 26 / EOF char...in a 800 byte stream...
encoding checked...i have change the encoding with alle the standards (try UNICODE,UT8 etc...) and all the internet suggest encoding (1252 for example) ==> no result...
I use the "readbyte" or the "read with 1 byte"...i try the "read with more byte" too...
it's not so simple guys belive me
or maybe I'm stupid dunno lol
This post has been edited by barby: 26 Aug, 2009 - 12:56 PM
And this is ther is 0x1A: 7E 24 00 00 13 A0 54 1A 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
Maybe if i wait, the missing bytes arrived...
But now my question...my protocoll speed (remember that i have attached a microcontroller) is function of the number of 0x1A in the packet??? Are we crazy???
An alternative solution, can be (like I did in a .Net application) to use an alternative OCX for serial comunication...
As the original poster (RDR) I am following this very closely as I'm still looking for a solution myself. Like barby I have tried all manner of "fixes", none of which are 100% effective. Today I tried reading one byte at a time using a FOR - NEXT loop rather than the serialport.read direct to a byte array. This improved the situation but now I periodically get gross errors in the data like "22,608" rather than say "150". It would appear that the data is always read correctly into the comms buffer (at least) but the error occurs when the buffer is read into a byte array. When the "transfer" encounters the h1A it aborts the read beyond that point. Doing single byte transfers seems to fix that problem but now creates these periodic data errors. Not sure if all this helps but I'm willing to try anything to fix the problem.
Here is section of the code showing the transfer from com buffer and how some of that data is applied.
CODE
If SerialPort1.ReceivedBytesThreshold = 33 Then ' 33 bytes received SerialPort1.Read(sadj, 0, 17) 'this is the ASCII block (as string) For bnum = 0 To 15 SerialPort1.Read(sdata, bnum, 0) 'read the data bytes one at a time Next bnum sadj(0) = " " label1.Text = sadj ' display the text string flags2 = sdata(15) ' define the flags byte If Not flags2 And &H4 Then ' do next if bit = 0 lhighbyte = sdata(0) llowbyte = sdata(1) ' form into 16 bit word lrpm = (lhighbyte * &H100) Or llowbyte 'hex to decimal conversion Label2.Text = (CStr("RPM " & lrpm)) ' display the result
// manage controls to receive Flag_Start = true; }
//============ SERIAL PORT DATA RECEIVE FUNCTION ============// private void serialPort1_DataReceived(object sender, System.IO.Ports.SerialDataReceivedEventArgs e) { if (Flag_Start == true) { if (manage_new_packet() == true) { // ===> OK <=== //
You are correct, the "0" value was a typo as the code listed was a bunch of copy and paste snippets. The receivedbytes.threshold is required for my code to distinguish between two blocks of incoming data packets of different lengths, works fine for that pupose. I'm sure .bytestoread would also work fine.
if (serialPort1.BytesToRead < REQUEST_SIZE) { int Timer_tmp = System.Environment.TickCount; do { //wait... } while (Timer_tmp + 100 > System.Environment.TickCount);
if (serialPort1.BytesToRead < REQUEST_SIZE) { Clear_RX(); return (false); } }
//Read serial port bytes while (serialPort1.BytesToRead != 0) { RX_buff[idx_rx] = (byte)serialPort1.ReadByte(); idx_rx++;
now it works fine, IF there are not too many 0x1A in the packet...
I explain, on 800 byte, if there are about 100 bytes with 0x1A value it works correctly...
If more bytes are 0x1A, the serial go in OVERRUN error:
CODE
//============ SERIAL PORT DATA RECEIVE ERROR ============// private void serialPort1_ErrorReceived(object sender, System.IO.Ports.SerialErrorReceivedEventArgs e) { int dummy;
Good work Barby! I'm out of town for a couple of days but will watch your progress with interest when I return.
RDR
I've to fix some other work in these days! when I come back to the problem and i choose the final solution I will post my code!
my last ideas are two: 1) substitute the serial port component of .Net enviroment with another one (or another dll dunno) 2) try to read the serial data in a separate timer. Now the serial data is read in the serial port receive handler
Has anyone made any more progress on this problem? I have a similar issue when receiving multiple 0x1A byte transmissions. I am using C# with a USB to 485 converter that contains a FT245 chip. Just curious...cause I am very stumped. I am uncertain if it is .NET or the chip with the problem.
Has anyone made any more progress on this problem? I have a similar issue when receiving multiple 0x1A byte transmissions. I am using C# with a USB to 485 converter that contains a FT245 chip. Just curious...cause I am very stumped. I am uncertain if it is .NET or the chip with the problem.
Hi Shell1366. The common factor with all these problems so far appears to be the FTDI chip. I use the FT232RL in my application with vb.net. It seems strange that no one else has (had) a problem with 0x1a when using comms in either C#, VB etc, only those using the FDTI chips.
I just did a quick test using Hyper Terminal to receive a block of text with some embedded 0x1a bytes. Hyper Terminal processed it perfectly fine and just displayed right-pointing arrow characters when it encountered the 1a bytes. A hex view of the text was perfectly correct. Note that HT uses the same virtual comm port (VCP) as my VB app. Not sure what to conclude from all that.
Has anyone tried using the dll's for these chips rather than the VCP's. I'm not sure how to incorporate a dll into VB so would appreciate some advice or comment on that.