VISA Serial Read Issue

[wlydick]

Thanks.  Knowing that it is supposed to be the length of message indicator helps me out.  Of course, it doesn't seem to be implemented by the circuit designer correctly, because it stays at 60 hex (96 dec) regardless of how many bytes are in the message (10, 16, 17, 18, or other).  I've included to of today's USBlyzer logs in the attachments.

It's a proprietary device with custom circuitry running the communications.  Even worse, there is no documentation and no manual for the underlying protocol(s)... after all, I'm just supposed to read and write the data.   It takes straight serial in and feeds it out.  *sigh*

If I compare the FullSuccess file to the FullFail file, I'm seeing that the failure is happening somewhere after seq 0568 (in FullFail) because the data from seq 0566/0567 loaded successfully into the VI.  The data from seq 0578 is not reaching the VI because the VISA Read has already faulted out.  I did rewire the VI slightly so that the loop exits immediately upon a fault from the VISA Read VI rather than waiting an extra cycle.

I'm thinking tomorrow is going to be a long day on the phone with the circuit manufacturer and the customer's electronics engineer trying to figure this one out.

[JÞB]

Thanks.  Knowing that it is supposed to be the length of message indicator helps me out.  Of course, it doesn't seem to be implemented by the circuit designer correctly, because it stays at 60 hex (96 dec) regardless of how many bytes are in the message

---

That sucks!

Protocols are protocols.  When FW engineers just plain toss out useless data in a message package it sucks!  Every 8 bits should have a purpose.

Can you punch the stupid SOB in the jaw?... Try not to hurt him / her too much! but a bit of physical pain might just educate the person that missed that clue before.

Before the engineer goes to bed

deny them soup, 

deny them bread.

Smack them twice upside the head

say "what were you thinking?" instead.  --Jeff

[wlydick]

---

@JÞB wrote:

Thanks.  Knowing that it is supposed to be the length of message indicator helps me out.  Of course, it doesn't seem to be implemented by the circuit designer correctly, because it stays at 60 hex (96 dec) regardless of how many bytes are in the message

---

That sucks!

Protocols are protocols.  When FW engineers just plain toss out useless data in a message package it sucks!  Every 8 bits should have a purpose.

Can you punch the stupid SOB in the jaw?... Try not to hurt him / her too much! but a bit of physical pain might just educate the person that missed that clue before.

---

I'm just a contractor.  I can't tag them, especially since they're in another state (possibly the state of Confusion?).  This stuff was all "developed" about 18 months ago without a true electronics or electrical engineer (of which I am neither) overseeing things.  The customer got curcuitry that did what they asked for, but not necessarily what they truly wanted.  That's the risk of outsourcing.

However, for an on-topic item, I've been able to get past the hurdles and now have working code all the way through the testing process and the code is complete.  I was able to circumvent the VISA Read issue by having the error handler ignore the single error code that I was getting and ... voila! ... everything works.  After spending a lot of time with USB sniffers, TTY programs, and NI's I/O Trace, I think that's the only way to avoid the errors.  It looks like they're from NUL characters in the string, but I'm lost as to why those would confuse the VISA Read vi.

Thank you to everyone who helped with this.

[ALAB]

We have developed a package on the LabVIEW Tools Network to automate serial port interactions. You can use it to replicate what you manually do using Putty in LabVIEW for serial devices such as logining in, entering commands, waiting for a response and returning it. You can find out more about it and download a 30-day free trial at: http://sine.ni.com/nips/cds/view/p/lang/en/nid/214248