10-10-2016 12:20 PM
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.
10-10-2016 01:27 PM - edited 10-10-2016 01:28 PM
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.
10-17-2016 05:15 AM
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...
Flo
10-17-2016 08:08 AM - edited 10-17-2016 08:11 AM
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.
10-17-2016 08:42 AM
looks like a flush function solves it!
Thank you so much !
Flo
10-17-2016 09:17 AM - edited 10-17-2016 09:19 AM
@ICCR-Lab wrote:looks like a flush function solves it!
Thank you so much !
Flo
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.
10-17-2016 09:21 AM
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.
Flo
10-17-2016 09:40 AM
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.
10-17-2016 09:41 AM
But that is why I think it's okay to move forward for now. It's not an immediate threat.
10-17-2016 09:41 AM
thanks...
from the manual it doesn't look like it's diferent from the other commands
Flo