VISA read always returns blank

[mgouveia]

Í think I can see your problem

You are using termination char and from what i Understood it is an CR. Visa Read will stop reading if there is a CR char in the buffer (I think you all know that), and will stop in the first CR it finds.

Raghunathan said that his device does not accept LF as a term char, are you refering to your hardware? or to labview for some reason? If is your hardware, and you are not sure if the termination char is CR or CRLF just put LF in the configure serial port and test it.

Also in your first image poste i see a few consecutive Write, do you know if your device allways answer after receiving data? If yes, and i had some devices that just replyed with CR, it can be your problem, meaning, that for each write you have an CR in your read buffer.

How can you solve this, try to make a simple vi that just write and read the same things like you have in the state you are having problems, use no termchar, and in the read string read configure it to show as "\ codes display"

Now you can see what data is in you buffer, study it and see what could be wrong.

Usually when i do a communication driver for a new device, First I use a Terminal program to see what the device answers, then I use simple labview code to test it and to see if it answer as i expected, and to decide how to do my driver.

also i usually use a buffer to read the data like this

Here is a simple Terminal made in labview (you should change the term char and "\r" constant in the loop for ther term char you want)

For you test simple use only the blank constat to stop the loop

I hope this help

[MogaRaghu · Accepted solution]

Hi Mgouveia,

thanks for your detailed post. And I liked that idea of a simple Terminal code. Also your idea to try out the sequence in Hyperterminal - well that is the first thing i do in any such Comm application.

Well my problem is solved and the following two things helped out :

1. Clearing the recieve buffer prior to a write. [ Kudos given to the suggestion..]

2. Reading the Bytes at Port and making the TermChar input False in configuration.

Finally a big thanks to all those who helped to understand the VISA process more clearly.

[RavensFan]

Then you really should mark whichever post most helped you as the solution to your problem rather than your own thank you message.

[MogaRaghu]

The decision to mark my REPLY as solution was conscious.

Crossrulz - Suggested Trim WhiteSpace

dkfire       - Suggested VISA clear before Write.

billko        - Suggested not to use Term Char & Bytes At Port together.

All these and also some of the other tips led to the solution. And the Forum allows only one Response as a solution.

[RavensFan]

Then pick the first or best one.  Give everyone else kudoes.

You certainly didn't solve your own problem because if you did, this message thread wouldn't have stretched to 20+ messages.

[MogaRaghu]

A point was made on the aspect of the right solution and in turn I have explained my logic. And also  in this particular instance I have amply mentioned / thanked the members who offered genuine help and hence irrespective of how you feel I should handle this, my decision stands. Thanks for the pointer anyway.

[billko]

---

@Raghunathan wrote:

Hi Mgouveia,

thanks for your detailed post. And I liked that idea of a simple Terminal code. Also your idea to try out the sequence in Hyperterminal - well that is the first thing i do in any such Comm application.

Well my problem is solved and the following two things helped out :

1. Clearing the recieve buffer prior to a write. [ Kudos given to the suggestion..]

2. Reading the Bytes at Port and making the TermChar input False in configuration.

Finally a big thanks to all those who helped to understand the VISA process more clearly.

---

I can't help thinking that step 1 is a kludge.  There are things left unaccounted for in the buffer and one day there may be something meaningful there.  Keep this in mind if you are experiencing unusual behavior in your application.

Beware step 2.  If you are relying on "bytes at port," it is imperative that you have it in some sort of loop that only exits on an error or 0 bytes at port, or you get - hey - leftover bytes in the receive buffer!

IMHO you'd be better served by understanding WHY there is "extra" stuff in the buffer to begin with.  This SCREAMS that there is still something very wrong with your communications and you are covering it up, rather than fixing it.

I would STRONGLY urge you to check out the manual to see what are the REAL communications requirements so you can handle them properly.

[JÞB]

Bill(ko)

way back when many serial "messages" were formatted as

<CR LF> Data <CR LF>  Which makes sense if the reciever is a teletype terminal since you don't want to keep printing on the same line of paper.  Termial emulators picked up the habit for similar reasons.  Local echo off was the accepted default so your typed CR LF did not advance the page.  It almost makes you wonder who still uses fan-fold paper.

Apparently, the device here follows that older convention.  End mode on reads = Term Char is not the Ideal choice for those.  Hopefully the device also uses hardware handshaking (Common for terminals) but, there are a few devices I have run across that you simply must know the expected response size or read twice knowing the term char will also start the Tx and use return count to decide if CRLF is Start of text or End of Message

[MogaRaghu]

Bill,

I cannot but acknowledge all of the excellent points you wrote. Thanks . ( the 3rd Kudos was from me 😉

Right now I am happy to read something on   the screen !! And must say that I am reading sense. Of course I must make the code robust to handle all of the crap that will get thrown at it in real life. And for that I will keep your advices handy..

Quite really there is a serious problem when trying out new instruments ( my CAN- Bluetooth adaptor )  with a programming language ( read LV ). First read the manual. Then when you are stuck,  you have to read the manual again , slowly now , try out options and if all fails approach the vendor of the instrument. But then he knows only about his instrument ( naturally ) and nothing about LV. So its a big effort to first place the problem ... and for a guy like me who does not own exotic stuff like protocol analyzers etc. it is very difficult to go by just symptoms.. Simply put .. i am a mechanical engineer by qualification and profession. Electronics and softyware are just hobby. Just to make it easy for the client and also to satisfy my thirst for challenges, I offer LV as a package with my test stands and over the last decade have more than 30 odd applications running fine.  And some of them are real big ones.

And of course but for this forum and supporting members like you,  all of above would just be a dream ....

[billko]

---

@JÞB wrote:

Bill(ko)

way back when many serial "messages" were formatted as

<CR LF> Data <CR LF>  Which makes sense if the reciever is a teletype terminal since you don't want to keep printing on the same line of paper.  Termial emulators picked up the habit for similar reasons.  Local echo off was the accepted default so your typed CR LF did not advance the page.  It almost makes you wonder who still uses fan-fold paper.

Apparently, the device here follows that older convention.  End mode on reads = Term Char is not the Ideal choice for those.  Hopefully the device also uses hardware handshaking (Common for terminals) but, there are a few devices I have run across that you simply must know the expected response size or read twice knowing the term char will also start the Tx and use return count to decide if CRLF is Start of text or End of Message

---

Hi, Jeff:

You make some excellent points.  So enabling the term char would result in every other read being a blank.  (Hence your 'read twice' comment.)  I know that CAN is VERY old; do you think the serial interface to that piece of equipment is that old?  I honestly never considered it.

Thanks!