10-17-2016 10:22 AM
Yet something must be different. Try logging every response you get. Try using NI's I/O trace to inspect what is actually being returned from the serial port. Just because the device's manual says nothing is different about that command and response doesn't mean the hardware guys actually programmed the device according to what the manual says.
10-17-2016 10:25 AM - edited 10-17-2016 10:26 AM
You can additionally stick probes on the wires in the problem areas. Like the output of the reads in question. (i.e., the reads after the CC and CS commands.)
[edited for clarity]
10-17-2016 10:29 AM
I've done all of that already, and I Just get (sometimes, not always) the response of the CC command after the WRITE function calling for the CS command. The returned string is exactly what a CC command would send back.
10-17-2016 10:29 AM - edited 10-17-2016 10:41 AM
@RavensFan wrote:Yet something must be different. Try logging every response you get. Try using NI's I/O trace to inspect what is actually being returned from the serial port. Just because the device's manual says nothing is different about that command and response doesn't mean the hardware guys actually programmed the device according to what the manual says.
Wouldn't it be interesting to find out that the firmware is incorrectly treating both commands as "CC"?
10-17-2016 10:34 AM
gnore my last reply - it was made before you noted it was intermittent.
10-17-2016 10:36 AM
The CC command always returns the appropriate data?
10-17-2016 10:45 AM
@ICCR-Lab wrote:I've done all of that already, and I Just get (sometimes, not always) the response of the CC command after the WRITE function calling for the CS command. The returned string is exactly what a CC command would send back.
When you get the CC response following the CS command, what did you get for the CC response immediately after the CC command? The same thing? Nothing? An error? A timeout error? Something completely different?
10-17-2016 11:26 AM
So. I'll try to be as clear as possible.
As the error is intermitent is quite hard to spot it, especially when I don't know what triggers it.
BUT:
From my snippets you can see that I've got a gauge for the pump brine controller. I think the gauge sometimes goes to zero then immetdiately back to the current pressure. My guess is:
- step 1) the CC command is written/read nicely
- step 2) the priming is done (nicely or not, whatever) and then I run my backpressure regulator and the cp pump. as the CS command is the last one interpreted (if I didn't set any new values), the flow rate is kept somewhere into the buffer and will be later read by the CC command of the gauge ( I think that as the response of the CC command is OK, pressure, Flow rate/ where the CS is OK, flow rate, etc.)
It's a guess.
Flo
10-17-2016 11:38 AM
@ICCR-Lab wrote:So. I'll try to be as clear as possible.
As the error is intermitent is quite hard to spot it, especially when I don't know what triggers it.
BUT:
From my snippets you can see that I've got a gauge for the pump brine controller. I think the gauge sometimes goes to zero then immetdiately back to the current pressure. My guess is:
- step 1) the CC command is written/read nicely
- step 2) the priming is done (nicely or not, whatever) and then I run my backpressure regulator and the cp pump. as the CS command is the last one interpreted (if I didn't set any new values), the flow rate is kept somewhere into the buffer and will be later read by the CC command of the gauge ( I think that as the response of the CC command is OK, pressure, Flow rate/ where the CS is OK, flow rate, etc.)
It's a guess.
Flo
Thanks for being so specific. It really helps. (Not that you weren't trying to be clear earlier.) It's like being a detective. The more questions you ask, the clearer the issue becomes until the mystery is solved.
In step 2, are you actually saying that the format of the response is correct, but the value of the flow rate is incorrect?
10-17-2016 01:02 PM
@ICCR-Lab wrote:So. I'll try to be as clear as possible.
As the error is intermitent is quite hard to spot it, especially when I don't know what triggers it.
BUT:
From my snippets you can see that I've got a gauge for the pump brine controller. I think the gauge sometimes goes to zero then immetdiately back to the current pressure. My guess is:
- step 1) the CC command is written/read nicely
- step 2) the priming is done (nicely or not, whatever) and then I run my backpressure regulator and the cp pump. as the CS command is the last one interpreted (if I didn't set any new values), the flow rate is kept somewhere into the buffer and will be later read by the CC command of the gauge ( I think that as the response of the CC command is OK, pressure, Flow rate/ where the CS is OK, flow rate, etc.)
It's a guess.
Flo
Are you checking the VISA Read for any errors? It sounds to me like you are sending the command, it is executing, but you might be getting a timeout error when the response to the command isn't coming back in time before the VISA Read executes. Perhaps the priming function takes a little longer and only responds when it is done. When you get the timeout error, you have no response which gets intepreted as zero. Then when you get to executing the next command, the response to the first command as finally reached the serial buffer and you read it instead. The response to your second command will be sitting in the buffer waiting on the next VISA read.
You don't want to just flush things. You need to figure out what is going on and fix it. Perhaps a longer delay between the prime command and reading the response. Or allow for several retries of the VISA Read for that response until you get a valid response.