VISA and READ function - Problem linked to the bytes at port

[Flo-w]

Alright,

I will try these solutions tomorrow or on Friday, but here is my very last version(s) of the controller:

- the V2 uses the timeout event, I am usure it could work

- the V3 is an adaptation of the V2 in which I am playing with the buttons. It requires the user to click on it but it should work that way.

Please, let me know what you think of that 🙂

Flo

[Flo-w]

Can't edit the previous post:

So, here is my VI.

I am looking forward tomorrow to try and test it 😄

[jamiva]

Chiming in a little late and what I am suggesting may have been said before in this thread. So bear with me:

1. IMHO I think the “/” is interpreted wrong. It is the termination character for the string response, NOT the termination character of the VISA read. The VISA termination character should be the used to end the read. Use the “/” to only parse the returned string.
2. Even though the manual says “carriage return” (hex 0D), the standard default termination is “line feed” (hex 0A). I personally have never seen 0x0D used for any of my equipment. I may be wrong so try one, try the other.
3. If you look in the manual at the “Pump Command List”, ALL commands send back a response. Even the simplest command sends back an “OK/”. There MUST be a read after every write!!
4. There is one exception. The command “#” does not send a response. Not quite sure exactly what it does but the description is “Clears all characters from the command buffer”. I assume this will flush the outgoing response buffer also. Use it when you first initialize the pump.

[Flo-w]

1. It is the termination character for the string response, NOT the termination character of the VISA read

What do you mean ? And how can I say to the READ function to stop when it spots a "\" ?

2. I'll do !

3. Done

4. Done !

Flo

[billko]

---

@jamiva wrote:

Chiming in a little late and what I am suggesting may have been said before in this thread. So bear with me:

1. IMHO I think the “/” is interpreted wrong. It is the termination character for the string response, NOT the termination character of the VISA read. The VISA termination character should be the used to end the read. Use the “/” to only parse the returned string.
2. Even though the manual says “carriage return” (hex 0D), the standard default termination is “line feed” (hex 0A). I personally have never seen 0x0D used for any of my equipment. I may be wrong so try one, try the other.
3. If you look in the manual at the “Pump Command List”, ALL commands send back a response. Even the simplest command sends back an “OK/”. There MUST be a read after every write!!
4. There is one exception. The command “#” does not send a response. Not quite sure exactly what it does but the description is “Clears all characters from the command buffer”. I assume this will flush the outgoing response buffer also. Use it when you first initialize the pump.

---

I believe we all got mixed up, because technically the <CR> isn't a VISA termination, either.  So I misspoke, too.  Thanks for clearing that up for me, as well.  That being said, I've seen just about anything used for a command terminator.  I wonder why there are two possible command terminators?  Maybe you can string commands together?  e.g., cmd1/ cmd2/ <CR>?

[jamiva]

Are you able to see your com port in NI MAX? I sometimes like to use that to try out troublesome communications rather than creating a VI. 

If you can see it in NI MAX, highlight your Device/Interface then click “Open VISA Test Panel”. According to your previous post, you are using 9600/8/1/none. Check that the serial settings are correct in the Test Panel then click “Input/Output”. Type your commands in the box and do a “Query” and see what you get back. If you get back old data, just keep hitting “Read” until all data is flushed from the buffer.

---

@ICCR-Lab wrote:

1. It is the termination character for the string response, NOT the termination character of the VISA read

What do you mean ? And how can I say to the READ function to stop when it spots a "\" ?

It is not just a backslah. The backslash "\" in this instance tells the LabVIEW to interpret the following characters as

[billko]

---

@jamiva wrote:

Are you able to see your com port in NI MAX? I sometimes like to use that to try out troublesome communications rather than creating a VI. 

If you can see it in NI MAX, highlight your Device/Interface then click “Open VISA Test Panel”. According to your previous post, you are using 9600/8/1/none. Check that the serial settings are correct in the Test Panel then click “Input/Output”. Type your commands in the box and do a “Query” and see what you get back. If you get back old data, just keep hitting “Read” until all data is flushed from the buffer.

---

@ICCR-Lab wrote:

1. It is the termination character for the string response, NOT the termination character of the VISA read

What do you mean ? And how can I say to the READ function to stop when it spots a "\" ?

It is not just a backslah. The backslash "\" in this instance tells the LabVIEW to interpret the following characters as

---

Whaaaa?  Ugh.  No workarounds, please.  We don't fix a pothole by setting up a detour sign.  This is a symptom of not understanding something correctly, not the problem.

[Flo-w]

---

@billko wrote:
Whaaaa?  Ugh.  No workarounds, please.  We don't fix a pothole by setting up a detour sign.  This is a symptom of not understanding something correctly, not the problem.

Sorry Bill, could you please be more specific. may I remind you, guys, that Labview is quite new to me and I really don't want to throw any debate here but would rather seek for recommendations, advices and help 🙂

I am trying as hard as I can to improve my code according to your suggestions!

Flo

[jamiva]

---

@billko wrote:

---

---

Whaaaa?  Ugh.  No workarounds, please.  We don't fix a pothole by setting up a detour sign.  This is a symptom of not understanding something correctly, not the problem.

---

You mean to tell me that you never used a serial port sniffer? You never used NI I/O Trace? You never used VISA Test panel? These are not workarounds. They are tools to understand what is going on. Once you understand what is going on, THEN you can fix the problem.

What's the old proverb: teach a man to fish and you feed him for a lifetime. Maybe if the OP knows about, and uses these tools, he/she may not have to come back and ask the same questions over and over again.

[billko]

---

@jamiva wrote:

---

@billko wrote:

---

---

Whaaaa?  Ugh.  No workarounds, please.  We don't fix a pothole by setting up a detour sign.  This is a symptom of not understanding something correctly, not the problem.

---

You mean to tell me that you never used a serial port sniffer? You never used NI I/O Trace? You never used VISA Test panel? These are not workarounds. They are tools to understand what is going on. Once you understand what is going on, THEN you can fix the problem.

What's the old proverb: teach a man to fish and you feed him for a lifetime. Maybe if the OP knows about, and uses these tools, he/she may not have to come back and ask the same questions over and over again.

---

It sounded like you were trying to cerce the user into just ignoring a stale read and going on from there.  You never mentioned you were implementing a troubleshooting method.  Note that you never told the user what the meaning of finding stale data would be, so really I had no idea what you were trying to do.  I reserve using the VISA Test Panel for when I can't get a response at all.  And no, I've never had to use a serial port sniffer before.  I was tempted to a few times, but there was always an easier troubleshooting method available if I thought about it.

At any rate, we already DO know "what is going on".  What is going on is that we are not able to communicate effectively with someone who is not familiar with LabVIEW.  Nobody's fault; that's just the way it is.  We have not communicated effectively what the code needs to do.  Once that is solved, the other problem with stale data will likely resolve itself.