Writing with VISA while reading.

[ikaiser]

Thank you for this really good and detailed explanation of what is happening in DDragos' code!

@DDragos: As said before, using the protocol (here: using the advantage of the termination character) as it is meant to be used is the best solution. Even though it seems like making a detour because the Byte-at-port trick looks like a fit-for-purpose solution. It might be, but a quick-and-dirty one. Unfortunately you are encountering the "dirty" part, coming across a problematic data exchange every now and then.

[DDragos]

First of all, really sorry guys for the late answer. I was not able to put my hands on the real hardware, so any tests will not be relevant before that. 

@ikaiser Thank you for your ideas. I understand why some of your answers were attacked so bad(too much I think) ), but you just wanted to help and I get it.I was also thinking of a lot of your ideas, but the problems mentioned before by the other people are clear for me and as I can see for you also :).

@Bob_Schor ""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.""

Sorry if something from my explication is bad, but I never intended any of your comments. I followed every advice and keep them in my mind. I used what was working and applied it to the system.What was not working I tested and remove when it had an error. And I was trying just to give back the best stuff that worked for me. So we can learn together and let me struggle with it so I can learn from them, but also learn LV at the same time.

@crossrulz I got it all. I will not insist on the Byte at port stuff. I understand why is not good to use it and why the termination character is just better and the right way to use the communication protocol. Thank you very much for all the help. Everything works so smooth and fast(just as is supposed to be).Thank you 

@arteitle Your answer put it all together for me from your way of explaining. Thank you very much also.

I just want to mention that is very hard to find the best way to communicate between ADAM 4000 and LV. I hope all this will help somebody else. I will post a final VI with the basic communication between the modules and LV in this thread. Also, I will move to another topic in another thread regarding PID controller and a way of writing data on a file in a certain way.

Thank you very much boys, all of you, thank you :):).

[arteitle]

One other tip I have for robust serial communications is to clear the receive buffer before beginning each command-response transaction. Even if you're properly using the termination character to recognize the end of each response from your peripheral, any erroneously-received termination character will throw those responses out of sync with the commands. For each command you send you're reading from the serial buffer until just one termination character is received, but if somehow an extra one gets in there, you'll never know it except that the responses won't match up with the commands anymore. Normally the buffer will already be empty at the start of each transaction, but if it isn't then clearing the buffer will prevent the erroneous characters from causing problems.

[Bob_Schor]

arteitle,

Thanks for the excellent suggestion about clearing the Receive buffer before starting a Command/Response transaction.  We read Mettler balances that we configure to send weights 10 times/second (no big deal, right?), but sometimes one of them will "lock up" and typically not start.  When it gets bad enough, we go and power-cycle things, but what a pain that is!

I wonder if, in a situation such as ours where we say "Send Weights Repetetively", it would be a good idea to Read to Termination Character, parse, and if there's no error, clear the Receive Buffer "preemptively" (possibly using the "Bytes at Port", which should be 0, as a check for validity, logging anything else that pops up).  Does this make sense to you?

DDragos:  I apologize for coming down so hard on you.  I was frustrated by not seeing the code and not understanding what the error was, meant, and how it could occur.

Bob "Contrite" Schor

[arteitle]

It should never hurt and can only help if you clear the receive buffer any time you expect it to be empty anyway. You can check whether it's empty or not first if you want, but it doesn't really make a difference except to tell you that erroneous characters were received. That way if there actually is something unexpected in there, it won't interfere with subsequent communications.

[billko]

---

@arteitle wrote:

It should never hurt and can only help if you clear the receive buffer any time you expect it to be empty anyway. You can check whether it's empty or not first if you want, but it doesn't really make a difference except to tell you that erroneous characters were received. That way if there actually is something unexpected in there, it won't interfere with subsequent communications.

---

An example of this is the good ol' "noise in the line" issue when communicating over a modem.  Line noise often gets interpreted as extra characters, so it would be good to flush the buffer in case this happened.