Writing with VISA while reading.

[DDragos]

I did the necessary changes in my original VI. The only one that was not applied was the change from 'byte at the port' with the proper configuration with VISA. A selector is used instead of the case structure, and the graph is now just checking if the length of the answer is under 2, then it will not print that. This way, even if is a zero from the module, it will be printed because the answer will have a bigger length.

[DDragos]

I did the necessary changes in my original VI. The only one that was not applied was the change from 'byte at the port' with the proper configuration with VISA. A selector is used instead of the case structure, and the graph is now just checking if the length of the answer is under 2, then it will not print that. This way, even if is a zero from the module, it will be printed because the answer will have a bigger length.

[ikaiser]

Hey DDragos,

from just looking at your code (don't have any VISA instrument here) I have another idea where your issue could come from. Your "Untitled 3 (SubVI)" writes the command to the instrument and then instantly checks how many bytes there are as an answer. I assume that your instrument needs some time to process the command and send the answer afterwards. So maybe your "Bytes at Port" sees "0" bytes, so the "first" read operation won't read anything, but the next operation will do...

Insert a delay between the write and the read and check if this helps.

There is also another trick to omit "wrong" values: Flush the read buffer before writing to the instrument. To do so check how many "Bytes at Port" there are, read them and simply ignore them. Then do your write operation.

[Bob_Schor]

Why are you ignoring crossrulz's warning not to use Bytes at Port, but instead to use a Termination Character (if your VISA Device supports this, i.e. if it sends data as a variable-length String terminated by a "termination character", often \n)?  If your device does send out a Termination Character, then failure to use it, and using Bytes-at-Port to give you an unreliable indication of when the message has been completely sent will give you errors!

So if you insist on introducing known errors into your code, please don't ask us how to "fix" them.  At least try the "correct" way and if it doesn't fix your problem, show us the "code that fails", describe the VISA device (so we can check its documentation), and we'll all learn something.

Bob Schor

[ikaiser]

Ups, you are absolutely right. I had become blind to this shortcoming probably because I somehow expected it was already tackled after I read through the thread again. Or because the last device I wrote a driver for did not send termination characters (annoying, indeed). Obviously should not post here after a long day. But all that is no excuse for my previous post. Unfortunately I cannot edit/remote the wrong section 

[crossrulz]

---

@ikaiser wrote:

Insert a delay between the write and the read and check if this helps.

---

Shame on an NI employee for giving that kind of advice!!!  You are just delaying the issue instead of doing it correctly.  The correct method is to use the communication protocol.  In this case, it appears there is a termination character, so we should use that.

[ikaiser]

---

@crossrulz wrote:

---

@ikaiser

---

You are just delaying the issue instead of doing it correctly.  The correct method is to use the communication protocol.  In this case, it appears there is a termination character, so we should use that.

---

Actually I should face-palm myself. I gave you a kudos for posting "DO NOT USE THE BYTES AT PORT!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!" and then posted a similar hint not solving this issue.

But yes, you are right, the ADAM-4000 uses carriage return as termination character, at least I found a manual stating so (page 4-2).

[arteitle]

---

@crossrulz wrote:

---

@ikaiser wrote:

Insert a delay between the write and the read and check if this helps.

---

Shame on an NI employee for giving that kind of advice!!!  You are just delaying the issue instead of doing it correctly.  The correct method is to use the communication protocol.  In this case, it appears there is a termination character, so we should use that.

---

Are you talking about ikaiser? I don't see any indication that he's an NI employee.

[pincpanter]

"blue" users are NI employees.

[arteitle · Accepted solution]

---

@DDragos wrote:

No change, the system reacts the same way, with the error( -1073807253 ) starting from the READ block of VISA. Also when I try to send the 'set' command, everything brakes and is not working anymore.

Also it looks like when I am using the Highlight Execution, everything works fine. Maybe a delay is necessary somewhere or something like that. I implemented a small delay of 35ms in my original VI so the system has time to read the data before sending the command again.

---

That particular error code indicates a framing error, meaning that your serial port received a byte from your device that wasn't formatted the way it expected, for example it was sent at a baud rate or with a parity setting different than your port was configured for. Could you have your port misconfigured? If the defaults used by the Configure Port function aren't correct for your application, you need to wire the correct ones to it.

The reason everything breaks after one error is because you're feeding the error out into the shift register rather than handling it, so it just wraps around to the left side of the loop and gets passed into the next iteration of the loop. Once any subVI in the loop encounters an error, it'll be endlessly recycled through the loop with no way to recover. At a minimum, use the error as a condition to end the loop.

As has been said before, if your "set" command elicits a reply from your device but you don't read the reply or otherwise clear it out of the receive buffer, then it will still be there the next time you try to read the temperature from your device, and that's what you'll read out when you're trying to read temperature. You should be reading everything your device sends, even if it's just an acknowledgement. And as has been said repeatedly before, if your device sends a termination character, use it, and don't rely on delays or "bytes at port" to tell you when the response has been received.