LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Serial

Hi everybody, I´m actually working on a serial interface with an acquisition card that i design, it can acquire 4 analog signals in a range of +/- 10 Volts with a 16 bit resolution, the main control is provided with a PIC16F877A and I´m using the USART (Serial Port) of the PIC to transmit and receiving information between the PC and this microcontroller. The cycle of the PIC routine it can be describe as follow:
 
1) The PIC waits until an predefined character is transmitted by the computer
2) Once this byte is transmitted, the PIC converts one by one the 4 analog channels
3) The resulting 8 bytes (remember that the Analog - Digital converter is 16 bit  resolution) are transmitted to the PC
4) The PIC executes a routine to move a servomotor and begins a new conversion or measure (goes to step 2, the step 1 is only to initialize the system)
 
From LabView 8.0 I can transmit without any problem the initialization byte, but the problem is during the reading of the bytes that the PIC transmit, if I choose to do 200 measures I'm expect to receive 1600 bytes (because I transmit 8 bytes per measure) but the read buffer in LabView only receives a fraction of these bytes, I say a fraction because the number of received bytes always is variable. Meanwhile I perform the reception of this 1600 bytes, I´m monitoring the serial port of the DB9 connector with an Oscilloscope and the serial data is effectively transmitted by the PIC.
 
So, if you have an idea that what can be the problem, I´ll aprecciate so much, thanks for the help. I attach an image of my program in LabView so you can examine deeper.
 
I would like to comment something about my process: the serial transmission isn´t really continuous, I transmit 8 bytes from the actual measure but the next 8 bytes from the next measure have to wait until the servo motor routine finishes, this time is aprox 50 milliseconds between these 8 byte blocks of information. If there´s a way to handle this situation using the VISA instruments, please let me know...
 
The parameters of the Serial interface are: Baud Rate: 9600 ; Stop Bits: 1; Data Bits: 8; Parity: None; Flow Control: None. I´m using a USB-RS232 Converter to been able to connect my acquisition card with my laptop.
 
Thanks again...
 
 
 
0 Kudos
Message 1 of 12
(4,147 Views)
I suspect that you are overflowing the buffer.  Use the "VISA Set I/O Buffer Size.vi" to set the buffer size large enough to handle all the data you are expecting.
0 Kudos
Message 2 of 12
(4,140 Views)
Yes, I set the buffer once but if the buffer is overflowed, the number of received bytes will always be the same (I flush the reception buffer every time that the system is initialized), but it varies every time that i begin the system.
 
Thanks for your quick answer, maybe I need to try again setting the buffer size...
0 Kudos
Message 3 of 12
(4,132 Views)
You have wired up the error cluster but you have not used the simple error handler.  You may want to do that and see if any errors are being generated.  You could also experiment with putting a fixed delay between the VISA Write and the VISA Read.  You could then use the "VISA Bytes at serial port.vi" to determine how many bytes to read from the buffer.
0 Kudos
Message 4 of 12
(4,096 Views)


@AleksF wrote:
 
The parameters of the Serial interface are: Baud Rate: 9600 ; Stop Bits: 1; Data Bits: 8; Parity: None; Flow Control: None. I´m using a USB-RS232 Converter to been able to connect my acquisition card with my laptop.
 
Thanks again...
 
 
 


I assume because you have no software flow control you have hardware that controls this? Handshaking/Framing etc  If not then your vi will just read in at 9600Bd  and if you have a 50ms Delay in your servo motor, then your gonna fill your buffer with not a lot.
 
Craig
LabVIEW 2012
0 Kudos
Message 5 of 12
(4,092 Views)

Thanks to Craig and Centerbolt, i appreciate so much your interest in my problem...

Well, in fact I´m assuming that the PIC is providing the flow control because the transmission buffer isn´t empty until the stop bit is transmitted, if I eliminate the routine of the servo motor and the PIC only performs conversions and transmission of the data, I perfectly receive the exact number of bytes that I´m expecting.

When the servo routine is executed by the PIC, It doesn´t transmit anything, so I have blocks of 8 bytes at the serial port every 50 ms aprox, I´m a little newbie working with the RS232 protocol but as far as i know, the serial port is configured to receive the data when detects an start bit and validate the byte when the stop bit is detected. So, maybe I´m wrong, but there´s no possible that the buffer fills with garbage during that period of 50 ms.

On the other hand, Do you think that i can solve my problem if the VISA read block is inside of a while loop and stop the loop when the byte count is equal to the number of bytes that I expect?

If you have any comment or hint about this, please let me know and again thanks so much for your answers...

Regards

0 Kudos
Message 6 of 12
(4,052 Views)

AleksF,

You have enabled the termination character on the "VISA Configure Serial Port.vi".  It defaults to enabled with a LF as the character when left unconnected.  Make sure that this is what you really want and make sure your PIC is transmitting the correct termination character back to your LabView program.  Does the data that you do receive make sense?

0 Kudos
Message 7 of 12
(4,033 Views)

Hi Centerbolt, yesterday I had time to work again with the card, as I comment before, when I eliminate the motor routine, all works fine, the data that I´m receiving has sense since I connect a known voltage to each analog channel and thats what I´m receiving on the screen. I attach an image of previous results that i´m obtained with this card and the program that I show you before. This VI isn´t detailed so I apologize for the appearance of the front panel.

The first image shows the behavior of the interface when I connect 3 channels to ground and the last one to a sine wave from a functions generator. The second is a caption of the screen of the oscilloscope showing a 8 byte pack transfered by the PIC, the TTL signal is measured at the output of the PIC and the RS232 signal is measured at the output of the MAX232 which converts the TTL signal to RS232 protocol.

The info in the screens is in spanish so if you have any doubt about it, please let me know. Sorry if my english is not good enough...

I´m going to check the termination character...On saturday I have time to continue with the tests so if I found something I´ll notify you as soon as possible.

Note: the test in the image is with only 200 measures instead of 900, but is the same case for 900 measures (I can receive all if the servo routine is eliminated)

Thanks for all Centerbolt!

 

Download All
0 Kudos
Message 8 of 12
(4,017 Views)

If everything works with the motor not running, that is a good start.  First it means that your PIC is definitely transmitting at the correct BAUD rate and that it is capable of sending all the data.  Second it points to a couple of possible problem areas.

1 - The problem could be timing related.  With the motor routine removed, did the PIC still have a delay between reading the channels?

2 - It looks like you got good data when the motor was not running.  What happens if the motor is running?  Does the data you get make any sense?  If the data received with the motor running makes no sense, the problem could be electical noise created by the motor interfering with the RS-232 communications.  Either way you should verify with your oscilloscope that the signals remain correct when the motor is running.

0 Kudos
Message 9 of 12
(4,010 Views)
When the routine of the servo is removed, there´s no delay between bytes of data, otherwise, the transmission is a continuous stream of RS232 characters, so maybe this is the reason why i have no problem receiving the data.
 
When the routine of the servo is running, I begin to receive the bytes but suddenly the buffer stops to fill, and the reception stops, bytes received indeed corresponds to valid data (It begins to plot the signal, but stops when data is no longer flowing). So, in this case the data is VALID but I think that in some moment of the blank space (when data isn´t transmited by the PIC because the servo routine) the reception is cut off.
 
If I connect the oscilloscope I can see the bytes transmitted by the PIC, even when the VI has finished receiving data. Movement of the servo doesn´t generate visible noise or alterations to the transmitted signal. In fact, I´ve doing several tests and the number of transmitted bytes ever is the same (I check it in the oscilloscope) but the number of received data always varies.
 
So, for this inconvenient, my suspects are on the form in which LabView handle that 'blank space' between blocks...
 
Maybe I can send you some other images of this problem tomorrow, again thanks for your attention and the time spent analyzing my problem.
 
Have an excellent day...!
0 Kudos
Message 10 of 12
(3,997 Views)