LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

How do you troubleshoot a USB virtual COM port?

Solved!
Go to solution

It looks like the board is sending 0D 0A (carriage return line feed) during the read transaction (last three lines of the monitor report).  Even though those characters do not appear in the data sent to the board, I would try sending them to see what happens.  When a device uses termination characters like that, it usually does so in both directions.

 

Lynn

0 Kudos
Message 11 of 19
(1,263 Views)

Reply to Knight of Ni message

 

Arduino's Serial Monitor has a "No line ending" option.  When I used Arduino's Serial Monitor I used this option and received a timely and correct response from the Arduino board.  Hence not terminating the string is not the source of the problem. 

 

Howard

0 Kudos
Message 12 of 19
(1,244 Views)

REply to Todd Lesher's comment

 

"I wonder how many Bytes are sitting at the port waiting to be read?"

 

There are no bytes sitting at the port waiting to be read.  Both Portmon and Free Serial Port Monitor show that the Arduino board does not return a response when Labview is used to send a command to the Arduino board.  In addition the Arduino sketch is designed to add a terminating character to the end of the strings it sends. 

 

As far as I can tell from the Portmon and Free Serial Port Monitor data Labview and the Arduino's Serial Monitor are sending the same commands to the Arduino board.  My next task is to determine why in one case the Arduino board sends a reply and in the other case it doesn't.

 

Howard

0 Kudos
Message 13 of 19
(1,243 Views)

Since the Arduino is not sending a termination character, and it is sending less than 32 Bytes, the VISA Read will timeout. I just thought that "VISA Bytes at Serial Port" would probably show you the Bytes. If it does, disable term char in the VISA setup. Portmon, etc, will not show Bytes waiting in the buffer - just the Bytes that are actually read.

0 Kudos
Message 14 of 19
(1,240 Views)

Reply to johnsold's message

 

The data you refer to was taken when Arduino's serial monitor was used to send a command to the Arduino board.  This was the command sent to the Arduino board to  produce the reply you refer to.

 

31 32 33 2C 33 34 35 36 48                        123,3456H

 

Notice no terminating characters.  The Arduino Serial Monitor has a "No line ending" option

 

Howard   

 

 

0 Kudos
Message 15 of 19
(1,239 Views)

Reply to Todd Lesher's comment "Since the Arduino is not sending a termination character,"

 

No, the Arduino board is sending a terminating character.   See FreeSerialPortMonitor.txt file attached to message 10 in this thread for proof.  First line of message 10 is "Reply to Daniel's message'.

 

Howard

 

 

0 Kudos
Message 16 of 19
(1,236 Views)

Right, sorry.

This is the point where I get the oscilloscope out and see what's actually happening on the wires.

0 Kudos
Message 17 of 19
(1,230 Views)
Solution
Accepted by topic author hrh1818

Some success at last.

I am now able to use Labview to send and receive  messages from an Arduino Leonardo board.  Whereas I was using an Arduino Uno board when I initiated this thread.

Although both the Uno and Leonardo boards use the same Usbser.sys driver they use different .ini files.  The Uno .ini version is not compatible with Labview.  Whereas the Leonardo .ini version is compatible with Labview.  The Leonardo .ini version meets the "Communication Device Class (CDC) subclass Abstract Control Model (ACM)" specification. 

Howard

0 Kudos
Message 18 of 19
(1,197 Views)

I came across the following that explains why an Arduino Uno board would not respond when  a command was sent from a Labview VI.  Source
<http://www.arduino.cc/playground/interfacing/python>

"It is worth noting that the example above will not work on a windows machine; the arduino serial device takes some time to load, and when a serial connection is established it resets the arduino.

Any write() commands issued before the device initialised will be lost. A robust server side script will read from the serial port until the arduino declares itself ready, and then issue write commands. Alternatively It is possible to work around this issue by simply placing a 'time.sleep(2)' call between the serial connection and the write call. "

My problem was caused by my VI immediately sending a command after establishing a connection.  By adding a delay between establishing a connection and sending a command an Arduino Uno board would return the correct response.

Howard

0 Kudos
Message 19 of 19
(1,177 Views)