bytes at serial port

[srt]

yes, i think i use the "bytes at serial port", but the problem is when i use it in debug model( test step by step) it ia has 450 bytes and if i run in normaly status, it only has 150 bytes, so, how can i run it properly in normally way.

[srt]

thanks, now i can take what i want, but still have two problems.

1) when the vi finish, there are always one error message(1073807253 a framing error occured in data transfer) in normally run, when run in debug model, step by step, sometimes, it can pass and no error message, but has a warning message-(1073676294, the number of bytes transferd is equal to the requested input count. more data might be available.

2) if i  the certian number set up in loop is not suitable, for example, i set up 150, but maybe 390 will be good, when i run it, it didn't display the toally string i want to get in the windows ( that's fine, because i the number is not good) and i run it again, the dispaly in the windowns not from the beginning, it start from the last dispay and finish that and then loop from the beginning.

 I also double check when i use tera pro to dispay the string and no problem, when i reboot the test equipment, it can start from the beginning.

many thanks all help.

[LV_Pro]

That is the problem with using the "bytes at port" comparison with a lower number than the expected length, if the bytes haven't all come in when you read them you will have some come in after the read and be in the serial port buffer, waiting for your next read. The warning message that you have "read all the bytes, but there might be more" is normal. It is a warning and can, in this instance, be ignored. It sounds like your instrument "talks slowly" if, when you have 300+ bytes at port and you initiate the read all of the expected bytes haven't arrived. You probably want to increase the delay before the "waiting for bytes at port" loop starts. As for the framing error message it usually means that your comm port settings aren't right, like baud rate or parity. Look here for more info:     http://digital.ni.com/public.nsf/websearch/13a20c0f9df265fb86256fc60066d9c2   

P.M.

Message Edited by LV_Pro on 10-01-2005 09:41 AM

[srt]

thanks, but i think the setup in serial communication( eg. the rates, bits and so on) should be right cos it sometime work only warning message display.

and does have some way to clear the serial buffer in order to catch the data from the beginning?

[Ben]

Do not ignore the passage "If your settings match your devices settings, and you are still receiving a framing error, you may be experiencing noise on your serial line."

If it does the same thing in another software package I suspect a less than ideal I/O connection. Bad or floating ground.

The follwing is based on how things used to work.

The UART needs to be able to frame the characters transmitted across the line. Framing is the process of identifying the start bit the data the parity the stop bits. If you have a bad conncetion the UART will usually run into trouble with the start or stop bits. Since the frame can not be defined the data contained in the character cannot be assured.

Again back in the day...

You were not allowed to run a serial cabel more than 50 feet. Long lines, forescent lights, bad cable would degrade the start and stop bits.

Do not so quickly rule out bad rate settings. The comm chips being used these days are amazing in their ability to pull out data. I have seen baud rates set at double or half the correct setting give correct data with only occational framing errors. I believe this is because they are always over-sampling the lines to cancel the effect of bad signals. Chips I looked at 5 years ago were sampling at 10 the required rates unless you flipped bits to over-ride.

Trying to help,

Ben

[Ray.R]

---

@LV_Pro wrote:
That is the problem with using the "bytes at port" comparison with a lower number than the expected length, if the bytes haven't all come in when you read them you will have some come in after the read and be in the serial port buffer, waiting for your next read.

---

I think what LV_Pro is saying is the same as what I was saying or trying to say.  Setting a fixed number of bytes to read can play tricks on you.  Do not expect that the same number of bytes will be available to read at the port.  That is a mistake that often occurs because you are expecting to read a certain message as a response to a command.  Although you expect that message, it may not necessarily show up (because of an error) or it may take longer than expected for all the reasons posted so far in this thread. 

That I why I suggested reading the number of bytes available to be read at the port before actually reading the port.

I agree with Ben.  The framing error usially occurs for 2 reasons:  1) setting & 2) integrity of connection (cable?).

JLV