LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

stacked sequence in serial communications example by NI

Hello,

In the Basic serial Write and Read example provided by NI, there is a stacked sequence structure with a timer inside it. This stacked sequence is just before Labview reads the data from the COM port.

When I make value of this timer less than 10 ms, the VI is not able to read the data from the COM port.. Only at 10ms or more, the Vi is able to read the data from the COM port.. Why is that happening ?

Another question is, if I update the data values on the COM port, every 100ms, should this delay be 100ms, more than 100ms or less than 100ms ??

thanks,

Bira_pxi

0 Kudos
Message 1 of 12
(3,412 Views)

The wait is there to give the serial instrument time to place the results of the query into the receive buffer of the pc's serial port. A wait is necessary in this example because the VISA Bytes at Serial Port is used. If the instrument has not completed it's transmission, the VISA Bytes at Serial Port will report an incorrect number of bytes to read.

There are numerous other ways to do a serial write;/read. If the instrument sends back a termination character (i.e. CR or LF) at the end of the data, then the VISA Configure Serial Port will be set up for that, no wait is used, the VISA Bytes at Serial Port is not used, and a large number for the bytes to read, can be wired to the VISA Read. With a termination character, the VISA Read will wait until the termination character is detected and then terminate the read. It does not wait until the number of specified bytes is read. the advanced example is setup like this.

You can also eliminate the wait by using a couple of loops. In the first loop, do a VISA Bytes at Serial Port and exit when the number of bytes is greater than 0. In a following loop, have a VISA Bytes at Serial Port and a VISA Read. Exit this loop when the number of bytes is 0.

What you use will be dependent on the type of data being sent and how it's formatted by the instrument. A simple wait may work if the length of the data is very consistent and a termination character is not sent. If the amount of data is inconsistent and there is no termination character, you might want to use the loop approach. What you don't want to do is have to be constantly modifying the wait to accomadate larger amount of data or have a large wait when small amounts are sent. For example, if you wait for 100 msec and the data is available in 10, you are wasting a lot of time if you have a lot of transactions.

Message 2 of 12
(3,405 Views)
Thanks Dennis. I will try them out.
0 Kudos
Message 3 of 12
(3,399 Views)
Hello,

Well I am still using the Basic serial read write example. I am sending 10 bytes of data from my board to Labview every 300ms. The delay inside the stacked sequence structure is set to 400ms. I am getting some framing errors, the frequency of them coming is not very high, like 2 or 3 every 5 mins.

What should I do, to eliminate all these framing errors ? Do i need set up a receive buffer or increase the delay of the stacked sequence structure.? How do I set up the receive buffer ?

Thanks,

bira_pxi
0 Kudos
Message 4 of 12
(3,374 Views)
Hi,

Ok, these are the error messages i am getting.

Error -1073807298 occurred at VISA Read in mcor_digital_interface-2.vi
Possible reason(s):
VISA:  (Hex 0xBFFF003E) Could not perform operation because of I/O error.


Error -1073807253 occurred at VISA Read in mcor_digital_interface-2.vi
Possible reason(s):
VISA:  (Hex 0xBFFF006B) A framing error occurred during transfer.


I stopped labview and now running a serial port monitor software from Eltima Software, and I don't see any hiccups. I wonder f the monitoring software tells about the framing errors or such.


Any help will be appreciated.

Thanks,

birapxi


0 Kudos
Message 5 of 12
(3,365 Views)

Framing errors are an indication that there is a problem at the lowest level of serial communication.  I have only seen this error in VB programs I have written if the serial connection is disconnected in the middle of communication.  Here is a link with a pretty good description.  I would guess that you might have a noisy serial line either through loose connections or EMI.  Could you look at the signal using an oscilloscope to see if anything is unusually (like noisy spikes) in the signal?  I guess the other possibility is that the clock timebase is slightly different.  What is the baud rate for your application?

Search the discussion forum on framing errors.  I discovered this link (actually thru google) that talks about null characters causing framing errors.

0 Kudos
Message 6 of 12
(3,349 Views)
Also, a delay of 400ms is way too high for only 10 bytes of data. If the instrument is constantly sending every 300 ms, you can't possibly keep up.
0 Kudos
Message 7 of 12
(3,337 Views)
Hi Ravens and Dennis,

Thanks for the link to the thread Raven. Dennis, is that thread you mentioned that you think, it is some setting in Windiws XP which is causing this to happen as the VI's created in older versions of windows work perfectly. In my case i don't know, if i am sending a null character as a termination character. I have set the microcprocessor UART settings to be 19200 baud, 8 data bits, no parity, and 1 stop bit. Is the stop bit the one which is causing the framing errors ?

Dennis,  I also tried with different values of the delay, looks like if I go below 350, the VI displays garbled data, and the data read actually flickers, but when I put it to 400 ms, I see that the data values are not lost as well as there is no flickering.

Thanks,

bira_pxi
0 Kudos
Message 8 of 12
(3,311 Views)
Post your VI so we can look at your code.  Framing errors are usually related to the stop bit not occuring when expected.  I wonder if when you do a read, you are opening and closing the com port in every iteration.  That could pinch off some incomplete bytes.
0 Kudos
Message 9 of 12
(3,296 Views)
Hello Raven,

Thanks for looking at my VI.

birapxi
0 Kudos
Message 10 of 12
(3,279 Views)