RS232 Communication

[PIPL]

Thanks

I got your point and i understood that there is nothing to do with Baud Rate in this matter. I think it s not gonna help you if I'm posting my vi because the gauge to which I'm connecting is not available to you.

Anyway my vi is working fine with a value for byte count as 97 and it will be working fine upto a value of 99 and from a value of 100 onwards it will take 10 seconds to take a single set of data from the gauge, as for a value of 97 or 98 it will giving data @ 4 sets per second. Now if I'm asking for a little less data from the gauge then the byte count should also reduced accordingly so that the gauge gives a steady flow of data to my PC.

I think you got my exact problem. !!

[shoneill]

I think if you can post a picture (PNG please) of your block diagram, there's probably enough to see for us to make an educated guess as to what's going on.  There are certain things which are commonly done wrong with RS-232 communications, and often these are clear even without a given instrument.

If you want to post a pic, there's a fair chance we'll be able to come up with some ideas even without the instrument.

Shane.

[PIPL]

Here is the attachment.

[shoneill]

One thing I notice immediately from your picture (there's not actually much to see I admit) is that you're flushing the input buffer after reading the 99 bytes...  Why?

Does your instrument send a termination character (normally linefeed or carriage return)?  If so, this can be the best way to "terminate" a VISA read.

Which version of VISA are you using?

Shane.

[PIPL]

By giving a byte count of 99 and with disabling termination character ( here termnation character is EOF , I'm getting the output as follows

~1 20
0
1
-728
0
8141
-1108
8417
7866
-38
-21
800
175
8232
7483
154
5
2
9
0
801

Here if I'm enabling the termination character it will give the first single ( ~1 20 ) only as input. So termination character should be disabled.
And about flushing the buffer, I'm not much aware of this and it has been added in my vi as recommended by Dennis Knutson through discussion. Actually it has been added to get an ordered output from the instrument.

In this output there is two EOF and one '>' character also. Upto that it wont be giving any problem, but if we are requesting more than that number of bytes it will take much more time to give an output. I want to avoid this delay as the application field where the program is used doesnt prefer this.

[shoneill]

OK, you seem to get each single response with a termination character,

Why not run the VISA Read X times (21 in this case) to return the 21 seperate values with termination character enabled.  This will allow the absolute length of each response to vary without affecting your timing.

If there is some additional unwanted data after these 21 entries, then a buffer flush is good.

I don't quite get "EOF and one '>' character also.".  Where are the EOF and ">"?

Shane.

[PIPL]

I cant do it for 21 times to avail 21 line of data which corresponds to a single set of data, since the requirement is more than two sets of readings per second and now I'm getting 3 to 4 readings per second using the present vi. But if I'm using a wrong byte count it will give a single set of data in 10 seconds only which is not at all acceptable. So the only way is to disable termination character and have all the data that are available from the gauge in a single step, since reading a single data and a set of datas doesnt make that much of time difference.

[shoneill]

I think you still misunderstand something about RS-232 communications....

The VISA read itself is much faster than any instrument could send data over a 38kBaud line.  The VISA read basically chacks the OS buffer for the port to see if data is present.  In your case, using a termination character will only take data from the buffer until a termination character is received, then return the data.  The following VISA read (probable under a millisecond away from the last one assuming the data has already been sent by the instrument) reads the next lot until the next termination character is read and so on.  Once the data is in the buffer (Your Instrument limits this speed) the VISA read itself takes parctically no time whatsoever.  It shouldn't slow down your code measureable at all.

I still suggest you give it a try.  The real speed limitation os the physical transfer between the instrument and the computer, not the VISA read function.

Shane
.

[Dennis_Knutson]

If you would go back to the example I posted, you would notice that the flush buffer is only done once at the very beginning and after the serial port is initialized. This is done to clear anything that might be in the buffer before sending the first write command. If you need a flush buffer after doing the VISA Read, then you haven't read all of the data.

You could also look at it again to see how the VISA Bytes at Serial Port can be used. This has been mentioned several times as the only way to know how many bytes to read but your last example still doesn't do this. Basically, you would replace the single VISA Read you have with the code below.

It would also be nice to see the reast of your diagram. If you are having problems maintaining a certain acquisition rate, it may be due to whatever other code you have in the loop.

[PIPL]

Thanks for the support.

Sorry for posting a partial picture of my vi. It was not possible to include all of the accompying functions.

As i said earlier when i was trying to communicate with a baud rate of 9600, read byte count value of 99 was working absolutely fine. But for 38400 that wont work fine. And all of my doubt is about this 'byte count' only.