The problem is that your "boolean" (you should rename that to something meaningful as well as the other control names), is outside of the event structure and is read before the value change event for it occurrs. You aren't using that value in any other event case anyway.
Move "Boolean" inside its value change event.
Here is a modified version of your VI that fixes the location of your button, fixes some constructions that borderline on Rube Goldberg, and also makes improvements that were pointed out in earlier posts.
I changed some of the generic control name labels to something else. Be sure to change the labels of those controls to something that is more meaningful.
Hello again. I've modified my VI a little bit according to your recommandations guys, and something weird happens every now and then: When I prime the the pump (when I first run the app) the CS command of the prime event sends back a string which should be sent back by the CC command (this command lies outside the event case structure).
I've put the # command which should clear all the characters from the command buffer, but it doesn't seem to work well...
Is it possible that the CS command, CC command, or something else is sending back an extra termination character? If you send a command, but it responds back with something contain two termination characters, then it will take an extra read to get everything after the first termination character. Does the CC command otherwise look okay? (Since you say you got a response that belongs to the CC command, that makes me think that the first VISA read right after the CC command didn't give all that it was supposed to.)
If the #/r command "clears the command buffer", that is something that acts on the device. It doesn't clear the serial buffer if an earlier command happened to send a longer command than it should have.
You can always tryi a VISA Flush in your code before a VISA Write to clear the serial buffer before you write the command followed by reading back the response. It will get rid of anything extra that is hanging around the serial buffer.
looks like a flush function solves it!
Thank you so much !
Just remember that this is not a solution - this is a workaround for something you don't understand. Continue forward, but try to resolve this. Don't forget about it. It may not matter now, but if the application scope widens (or if you build a new application based on this one), you could quite possibly end up with some kind of intermittent glitch in the application - but this time, maybe the consequences are more serious than "a strange response". Like maybe equipment damage.
Alright, I see. I feel pretty bad now. So better fix it now. I have no clue why I keep geting a CC responce while when clicked on it, the prime function should trigger a CS command. Looks like this command is ignored every now and then. does that has to do with the fact that the "refresh rate" of the loop is fixed at 200ms ?
I really have no clue as I've checked what RavensFan said earlier, and everything is fine on the code.
I think it is a problem with the command/response thing. I think these commnds are "different" than the other ones. I'm afraid that as you go along, you'll find other commands that are "different" in the same way, and that is where the danger lies. I'll re-download the pdf and scrutinize it to see if I can spot anything.
But that is why I think it's okay to move forward for now. It's not an immediate threat.