Trying to use the 'Continuous Serial Write and Read' example

[ahg32]

Hi,

I'm new to LabVIEW and using serial ports.

I'm trying to use the example VI in the title. The program I am writing needs to read a com port, so I thought this example would be good as I think it writes to and reads the same com port.

However, when running the example I get 'Error -1073807339 occurred at VISA Read in Continuous Serial Write and Read.vi' with the possible reason being 'VISA: (Hex 0xBFFF0015) Timeout expired before operation completed'. I've been trying to find a solution but I can seem to find one. I've tried writing to the com port using other programs such as MATLAB.

The only thing I can think of is that the com port I am using is only a simulated one as my workstation doesn't actually have one. I need the program I am righting to read a com port because the computer the program will be running on has one. The com port is set up correctly (it appears in task manager and cmd prompt) and LabVIEW does see it though, so I don't think the simulated port is the problem.

Any advice would be appreciated.

Thanks,

Andre

[Bob_Schor]

Your Post seems to indicate that you are developing a LabVIEW Program on your computer (which has LabVIEW), but your Computer does not have a COM port.  You want to run your Program on another Computer (call it PC2) that does have a COM port, and may (or may not) have LabVIEW.

• If PC2 does have LabVIEW, then you can develop your Program there, and can use the Serial VIs to handle communication for you.  If it does not have LabVIEW, then you are going to have to build an executable version of your LabVIEW program developed on your PC and port it over (a more involved undertaking, requiring possibly higher licensing levels).
• To easily see what devices you have available on your PC, open MAX, and under "My Systems", expand Devices and Interfaces.  Are any COM devices listed?  [On my 2-year-old Laptop, none are shown].

If (like my PC) you have no COM Devices listed, you'll need something to establish communication with your external COM device.  There are devices that connect through USB ports or through TCP/IP and provide Serial Interfaces -- I presume you have one such device.  Plug it in, and see if MAX detects it as a COM device.  If not, you can ask MAX to "Create New ..." (top of right-hand pane) and choose "Port (Serial or Parallel)".  I've not done this, myself, but it should be fairly self-explanatory.

Bob Schor

[Kevin_Price]

I happened to use that example just yesterday as a jumping-off point for diagnosing some old equipment.  I needed to do a couple mods to make it useful to me:

1. I right-clicked the "Write" boolean control and changed the mechanical action to *LATCH* when released.  It starts as "SWITCH", which would make the program keep writing the same string repeatedly until I personally un-switched the boolean control.  I only needed to occasionally send single commands without repetition.

2. The program as written will terminate when there's a timeout error while waiting to read from the serial port.  That isn't necessarily such a great idea.  A lot of equipment won't continuously stream data without prompting, so timeout "errors" can be both expected and commonplace.  In such cases, I'll call the "Clear Errors" function with the error code for the timeout wired in as the specific error to clear.  (Other errors that are unexpected would still pass through and make the example program terminate.)

So that was enough to make the program useful for *my* purposes yesterday.

In *your* case, the COM port is simulated rather than being connected to some other device that's writing to it.  So timeout errors are probably all you can ever expect when you attempt to read from it.

Note: if totally new to serial, understand this:  It doesn't work like a storage location where you write something to the port and come back later to read the same thing back.  There are separate wires in a serial connection for the data you write and the data you read.  These wires go to a device on the other end of the connection which would read what you write while you read what it writes.  If there's no other device out there, there will be nothing for you to read and you'll get timeout errors.  And your writes just kinda vanish into the ether (without errors) because there's nothing out there to receive them.  

-Kevin P

[ahg32]

Thanks both of you for your advice - I thought I could write and read to the port using the example program. Yes Bob you are right - the PC I'm going to be using the program on has a com port and not labview, but the PC im working on has labview and no com port.

I've adapted the serial read for the program I am writing. The issue I am getting now is that when the serial input value changes the response instrument changes, but nothing else. I can't seem to get the rest of the program to react to serial input changes. The input is a string of two numbers, eg "256 256"

I've attached the program, am I missing something completely obvious?

Thanks again.

[Kevin_Price]

The only thing you do with the serial strings is display them.  No part of your code *uses* that info for any other purpose. 

You have 2 PID blocks, suggesting that you *probably* intend to interpret the serial string as 2 numeric values.  Normally, those would end up being the present values PV for the PID calcs.

I can only briefly note some other things that stood out.

1. 1200 baud - wow, it's been a long time since I've seen that.  I remember when this was an excitingly fast modem speed -- back in the late 1980's.

2. A more typical way to read from a serial device is that when configuring the port, both define and enable the appropriate 'termination character' (these inputs are at the top of the function block).  Line Feed (decimal 10, hex 0A) or Carriage Return (decimal 13, hex 0D) are two of the more likely possibilities, but in general it depends on the device you're connected to.

   When there *is* a termination character, VISA Read has a useful-but-not-inherently-obvious behavior.  You can ask for an excess # of bytes (like 100 or 1000), but it won't necessarily wait to get that many.  It will *instead* return as soon as the first termination character arrives.  It will return with all the bytes it received up to and including that termination character.   No matter how many characters you ask for, you'll only receive back one "line".

   So with this in mind, I'd confirm that the connected device sends a termination character, configure my VISA connection to use it, and then request 100 bytes per read. You'll probably only be receiving 8 in the example you mentioned -- the 7 characters of the string you quoted plus the 1 termination character).

-Kevin P