serial port

[sa428]

Please help i need to read bytes continuosly from a port and record them too...

plus before i can read i send to write to the port .

If the value at the port is zero then i get error ..i wish someone could help me with ..i am new to labview...

if i dont specify the no of bytes to be read it gives me n error..so i said 120...can you please help ..i am sending a copy of my code.

[GerdW]

Hi sa,

have you tried the examples that came with LabView? What happens here?

Why do you decided to read 120 chars? Do you really expect this amount on the serial port?What happens if you try to read 1 (or 😎 chars?

And, even more interesting, what happens when you give a small timeout (atleast 1, better 5ms) in the while loop?

What happens when you read the number of available bytes first? (See the examples on how to do...)

[smercurio_fc]

Also, have you verified the communication outside of LabVIEW? For example, if you're on Windows, have you tried HyperTerminal. You should always do this first. Does the write command require a termination character, such as a carriage return or linefeed? Are you including that in your write buffer?

[MattBradley]

Also a basic question -- what about the baud rate and parity?  Do you know what they are supposed to be?  (Also another reason to use hyperterm).

[sa428]

I know the baud rate ..did already the configuration in hyperterminal...can do the thing labview too..but i dont think it is synchronously done.

[Eric_K]

sa428,

For starting with serial communication in LabVIEW, I recommend looking at the examples in the Example Finder.  The Example Finder can be found by navigating to Help » Find Examples... from any open LabVIEW Window.

Two examples that I suggest you look at in particular are the Basic Serial Write and Read example and the Advanced Serial Write and Read example.  The first example should get you started with serial in LabVIEW, and the second example contains the VISA Write and VISA Read vi's inside a while loop, both with enable buttons on the front panel.  This should be a good place to start for reading continuously.

Eric K

[smercurio_fc]

---

sa428 wrote:
I know the baud rate ..did already the configuration in hyperterminal...can do the thing labview too..but i dont think it is synchronously done.

---

I don't quite understand what this means. If the item you are communicating with starts spewing stuff out in response to a command then you basically have what you need. The problem you have is that you can't use an arbitrary value for the bytes to read unless you've set up a termination condition so the VISA Read will stop once it sees a certain character. In your setup you have termination disabled, so you must first check to see how many bytes are actually available on the serial port and only read that many. The VISA Bytes at Serial Port will tell you how many bytes are available. Use this before the VISA Read, and feed the output of that to the VISA Read so the VISA Read only reads that many characters. This is shown in the "Basic Serial Write and Read" example that ships with LabVIEW. You will likely also need a shift register to collect the characters read.

[RTSLVU]

Give something like this this a try.

This vi displays serial data on the screen and saves it to a file. I brought out all the VISA serial controls to make it more universial.

[smercurio_fc]

---

RTSLVU wrote:

 I brought out all the VISA serial controls to make it more universial.

---

It would be more universal if you didn't build paths using strings. Always use the Build Path function. Oh, and paths should almost never be hard-coded.

[RTSLVU]

---

smercurio_fc wrote:

It would be more universal if you didn't build paths using strings. Always use the Build Path function. Oh, and paths should almost never be hard-coded.

---

Sure, but this was originally written to be ran as part of a long term test to capture the debug information the little micro-controller in one of our products spits out.

The file name is auto generated and contains the date so everyday a new file is automatically created.

That way when we discover a problem we could look back by date and see what the micro was thinking at the time the fault occurred.

I hard coded the path to the root for a couple reasions, first to make it easy to find the capture files, second I find end users (at least the engineers I work with)  do not like having to select a storage location or a file name, or do anything more than double click on the icon to start the program.