VISA Serial Read Issue

[wlydick]

I'm trying to read the data out of a customer's proprietary hardware.  The output should look like the UUTOutput.txt file attached.  Unfortunately, the VISA Read routine is failing as soon as data starts to arrive at the COM9 port.  I'm using a TTL-232R-3V3 cable plugged into a USB port of the computer and can read and write data to the unit using PuTTY, so the communications are clean to and from the device, which means that I'm doing something critically wrong inside my LabView code (attached).

The data should start sending as soon as the power button is pressed on the unit.  Unfortunately, as soon as the power button is pressed, the VISA Read errors out.  I can sometines get the data to queue up and then read some of it, but it was failing out after the first line (figured out it was the termination character).  Now I cannot even get there.  However, I can always shut down LabView, open up PuTTY, and communicate clearly.

I'm confused.

[ogk.nz]

For those without 2015 see the snippet:

Have you had a look at the VISA continuous read and write example that comes with labview? Can you use this to communicate with your device?

What is the error being produced at the VISA Read? This should give you a pretty good understanding of the cause of the issue or at least somewhere to start.

[wlydick]

The error (as displayed) is in the FrontPanel image on the right.  It is -1073807298 -- VISA Read in Phase1.4-Read Firmware Version.vi.

I used the continuous read/write example to dreate my vi.  However, when I run it the example, I get:

VISA Read in Phase1.4-Read Firmware Version.vi

Possible reason(s):

VISA: (Hex 0xBFFF003E) Could not perform operation because of I/O error.

But it does display the data up to a further point (tonight) that my vi...

[wlydick]

OK, based on today's testing, I have a better list of symptoms...

It's not the cable.  I've replaced the first one after I broke it checking for shorts in the custom plug. (whoops)

It's not the computer itself.  I've duplicated the problem on a different system.

The first time it runs after being connected, everything runs fine.  Any further attempts to access the port fail out at various points, typically when the customer's unit is started.

It fails both in the NI Continuous Read/Write Example and in my code (listed above).

I tried adding a delay between the serial port setting and the first read in case the port wasn't setting fast enough.  Nothing changed.

I'm stumped.

[crossrulz]

Are you sure the termination character should be disabled?  Looking at the text file, it looks like there is an End Of Line at the end of each message.

And continuing down that thought process, if you are using a termination character, then you should not be using the Bytes At Port to determine how many bytes to read.  You should tell the VISA Read to read more than the longest message you expect to ever recieve.  The VISA Read will stop reading when it finds the termination character or when the desired number of bytes come in, whichever is first.

This just makes sure you get a full message each time you do a read.  You can then do your checks for reactions to the data based on the current message instead of the entire amount of data that has come in.

[Eric1977]

Get into the habit where you use the error wire to wire EVERYTHING through it. Just something that I have gottem anal about becasuse I've been burned too many times by that.

Wire your error wires through the Bytes at Port and put a small flat sequence structure with about a 500msec wait inside that and wire your VISA wire and error cluster wire through it if your term. char. is False. Kinda like this:

 

But I do agree with Crossrulz...why not use the term. char. and make your life easier?

[wlydick]

Regarding the termination character, I've tried it both ways and had the program fail in the same way with it both on and off.  I had left it False  because I wanted to get everything that was in the Read queue in one shot rather than get it one line at a time.  However, I'm not particularly committed to either setting, so I'll reset that back to the default.  And you're right (not that you need me to say it) that using the termination character would help auto-parse the message.

I've started running the program with USBlyzer running on the port and have been getting some wierd results.  At least, they're wierd to me...  It appears that each "line" is starting with a 01 and a 60 character (hex).  The 01 (SOH - Start of Heading) kind-of makes sense to me.  The 60 (`) is kind of a waste character to me.  However, the 60 isn't showing up on either my PuTTY logs or LabView (on those times it works), so it makes me wonder if it might be contributing to the problem.

[wlydick]

I hadn't noticed the error terminal on the Bytes at Port.  I will wire that in the future.

Would the Write to the port really interfere with the Read from the port if they weren't spaced out?

[JÞB]

---

@wlydick wrote:

Regarding the termination character, I've tried it both ways and had the program fail in the same way with it both on and off.  I had left it False  because I wanted to get everything that was in the Read queue in one shot rather than get it one line at a time.  However, I'm not particularly committed to either setting, so I'll reset that back to the default.  And you're right (not that you need me to say it) that using the termination character would help auto-parse the message.

I've started running the program with USBlyzer running on the port and have been getting some wierd results.  At least, they're wierd to me...  It appears that each "line" is starting with a 01 and a 60 character (hex).  The 01 (SOH - Start of Heading) kind-of makes sense to me.  The 60 (`) is kind of a waste character to me.  However, the 60 isn't showing up on either my PuTTY logs or LabView (on those times it works), so it makes me wonder if it might be contributing to the problem.

---

The 0x60 is "Length of message"  What is the device on the far end and have you read the manual?

[Eric1977]

My guess would be no. However, the key was just get into the habit of wiring your error clusters all the way through.