RS232 Communication

[Dennis_Knutson]

In the future, you really need to start a new thread since your question is unrelated to this one but yes, you can interface a DB9 to DB25. There are whole cable assemblies as well as short adapters that can be used. You should google 'DB9 to DB25 adapter'. We buy a lot of cables from L-com but even your local Radio Shack should have something.

[PIPL]

In NI VISA READ.VI there are three inputs, 1. Visa Resource Name, 2. Byte Count, 3. Error in

Now the question is about Byte Count Input. How can we determine or calculate the value to be given for this input.

From the gauge we'll be getting the data in packets of 11 bytes.

Using a baud rate of 38400 means it will be sending datas @ 38400/11 Hz.

I think all of my problems have been explained satisfactorily, if not please let me know.

Thanks

[Dennis_Knutson]

As I said, you can use the VISA Bytes at Serial Port to determine how many bytes are available. Just wire the output of this to the VISA Read. If you know that there are 11 bytes per packet, and you know how many packets the instrument is sending, then multiply 11 by the number of packets.

[PIPL]

I've tried using VISA Bytes at Serial Port but its only gives a value of 5 and sometimes 8. By using this we wont get all the data that is sent by the gauge. Then I tried with constant values and it was working fine with a value of 101. this is what i dont understand.

[Albert.Geven]

When you check for bytes at serial port when communication is still going on, you get a too low number
maybe you can wait a second and see then, The number of bytes does not change when changing the baudrate
The time to receive the message changes linearly with the baudrate.

[PIPL]

I got that, but the question is about how to determine the value that should be given for byte count in NI VISA READ.vi

I've found it manually as 101 in my case. For this I've tried for several values and from these trial and error method I got this value.

If I go for a value greater than this, the read.vi will take 10 times more time than the normal.

[Albert.Geven]

Hi

normally the command syntax of a message gives the answer, most instruments use an EndOfLine character (LineFeed, CarriageReturn) and in GPIB we have the EOI (end or Identify) signal in a special hardware line.

When a special EOL chracter exists you ca use that to ask for much more data and visa will only deliver up to the next EOL.
A normal default is CR or LF.

But the rule is that you know at least the maximum number of characters you want to receive.

[PIPL]

And my question is that how can we determine the maximum number of characters you want to receive.

[shoneill]

Getting instruments to talk to each other and to PCs can be difficult.  This is why most instruments adhere to a specific protocol.  Your manual for the instrument or whatever it is you're interfacing to should have information about what should be sent back in response to which command (its protocol).

If this information seems wrong or is giving unexpected results, maybe you should contact the instrument supplier for more information.

Otherwise post your code here so that we can get more of an idea what might be going wrong.

Otherwise the discussion will continue to rotate on its own axis.

Shane.

[shoneill]

"Using a baud rate of 38400 means it will be sending datas @ 38400/11 Hz" is incorrect.

Your sender will send at 38400 bits per second, irrespective of your packet size.

Assuming you have a parity bit, and a stop bit, this means that for each 8-bit byte transmitted, 10 bits must be sent per RS-232.  This works out at 3840 BYTES per second.  This will (at 100% interface bandwidth - an unlikely scenario) result in 11 BYTES every 11/3840 seconds = 3ms.  So basically, you should be receiving one packet of 11 8-bit bytes every 3 milliseconds.

The input to VISA READ labelled "Byte count" should be set to 11 in my opinion, since this is the packet length you're expecting.  Loop this command to read in subsequent packets.

The timing is performed by the RS-232 port and the computer.

Shane.