08-19-2014 03:21 AM
In actual command here only when it was failing. Ok if you say so then I will repeat first 3 commands for 10 times in one test sequence. Let me see
08-19-2014 08:35 AM
If your response from the Arduino can have variable length and you cannot use a termination character, then what characteristic of the response can you use to tell when it is complete? In the examples you have been showing in the past few posts all the response end in $. Do all responses to the *AA$ command end in $? If so, keep reading all available characters, append them to the previous characters, and search the resulting string for the $. All the characters before the $ should be part of the desired response. Anything after the $ may be part of the next response.
If other commands have different responses, you may need to process those responses differently.
These kinds of things are not difficult. But you need to have the command and repsonse protocol for every possible command and response before you can design a program to handle it.
Lynn
08-19-2014 09:35 PM
@johnsold wrote:
If your response from the Arduino can have variable length and you cannot use a termination character, then what characteristic of the response can you use to tell when it is complete? In the examples you have been showing in the past few posts all the response end in $. Do all responses to the *AA$ command end in $? If so, keep reading all available characters, append them to the previous characters, and search the resulting string for the $. All the characters before the $ should be part of the desired response. Anything after the $ may be part of the next response.
If other commands have different responses, you may need to process those responses differently.
These kinds of things are not difficult. But you need to have the command and repsonse protocol for every possible command and response before you can design a program to handle it.
Lynn
If you take reponse of *AA$ then reponse can be either 4 or 5 bytes. So I always try to read 5 bytes as this is max possible so based on timeout(5 sec in my case) and after processing that response I say response is ok or not. Yes lots of command ends with $ but not all.
Not all response is available all the time. Based on different command response varies.
Do you want me to change the structure of my VI? Can you please explain me what is command response protocol? Do you think because of my VI structure it is failing?
08-19-2014 09:38 PM
@Nathan_B. wrote:
Well, if that one particular command works, test a different one and see if there is a specific one that is breaking things.
I real time testing it was failing at 3 step, so what I did is made one different test sequence in which I copied 2nd and 3rd command. and it worked fine.
08-19-2014 09:58 PM
Whew - over 100 posts and the problem still isn't defined.
08-19-2014 10:03 PM
Problem is defined but soltution is on the way
08-19-2014 10:13 PM
@Ranjeet_Singh wrote:
If you take reponse of *AA$ then reponse can be either 4 or 5 bytes. So I always try to read 5 bytes as this is max possible so based on timeout(5 sec in my case) and after processing that response I say response is ok or not. Yes lots of command ends with $ but not all.
Not all response is available all the time. Based on different command response varies.
Do you want me to change the structure of my VI? Can you please explain me what is command response protocol? Do you think because of my VI structure it is failing?
Since the current implementation is not working, something needs to change.
If each command in your Arduino has some sort of response that conforms to some sort of pattern (fixed number of returned bytes, a termination character, etc.) then you could probably simply handle each command differently (looking for that pattern when reading via VISA). ~~> SubVI.
The protocol that you need to be concerned with, as far as I can tell, is the protocol of your Arduino code (which you have not given us; something that you should either know or have access to). So, without knowing the protocol employed by your Arduino code it is increasingly difficult, if not impossible, to help you with it.
08-19-2014 10:21 PM - edited 08-19-2014 10:23 PM
@billko wrote:
Whew - over 100 posts and the problem still isn't defined.
I agree but I have a feeling that things are becoming clearer (but are still quite fuzzy).
I'm not sure how much you've been following in this thread but here is how I understand the progression:
The original issue was that communication with the Arduino was having timeout issues on the production computer but not on the development computer. After establishing that the Arduino appears to work fine in a test VI with a single command sent to it on the production computer, there does not seem to be any fundamental/OS issues with using the Arduino.
After several days of conversation, I've come to think that it all comes down to the LabVIEW developer not understanding the protocol used by the Arduino code with which he is interacting. So, if he was testing his code on the developement computer with only a single, known working, command but then when implemented on the production computer, there were more and different commands being issued for which the code was not designed (causing timeouts because of the unknown responses from those commands). Hence the "works on Win7 but not WinXP" problem.
This premise is now what I'm basing my advice on.
Disclaimer: This is only how I have perceived the situation given that I've had a hard time understanding many of the posts by the OP.
08-19-2014 11:05 PM
I was paying attention at the beginning, then got tired of trying to follow what was going on because there was no progress made and I wasn't able to provide an answer or any insight.
Just came back a little bit ago and was surprised to see it hasn't progressed much in 100 posts.
I've been on that side of the fence before - you know, the one where you don't even know enough about what is wrong to even explain it properly.
@Nathan_B. wrote:
@billko wrote:
Whew - over 100 posts and the problem still isn't defined.
I agree but I have a feeling that things are becoming clearer (but are still quite fuzzy).
I'm not sure how much you've been following in this thread but here is how I understand the progression:
The original issue was that communication with the Arduino was having timeout issues on the production computer but not on the development computer. After establishing that the Arduino appears to work fine in a test VI with a single command sent to it on the production computer, there does not seem to be any fundamental/OS issues with using the Arduino.
After several days of conversation, I've come to think that it all comes down to the LabVIEW developer not understanding the protocol used by the Arduino code with which he is interacting. So, if he was testing his code on the developement computer with only a single, known working, command but then when implemented on the production computer, there were more and different commands being issued for which the code was not designed (causing timeouts because of the unknown responses from those commands). Hence the "works on Win7 but not WinXP" problem.
This premise is now what I'm basing my advice on.
Disclaimer: This is only how I have perceived the situation given that I've had a hard time understanding many of the posts by the OP.
I was following it closely in the beginning, but as I didn't have enough knowledge in the area to help him, I eventually lost interest. I eventually got curious enough to peek into the thread again, and I was surprised to see that it hadn't progressed much in nearly four weeks.
08-20-2014 12:24 AM - edited 08-20-2014 12:28 AM
@Nathan_B. wrote:
I agree but I have a feeling that things are becoming clearer (but are still quite fuzzy).
I'm not sure how much you've been following in this thread but here is how I understand the progression:
The original issue was that communication with the Arduino was having timeout issues on the production computer but not on the development computer. After establishing that the Arduino appears to work fine in a test VI with a single command sent to it on the production computer, there does not seem to be any fundamental/OS issues with using the Arduino.
After several days of conversation, I've come to think that it all comes down to the LabVIEW developer not understanding the protocol used by the Arduino code with which he is interacting. So, if he was testing his code on the developement computer with only a single, known working, command but then when implemented on the production computer, there were more and different commands being issued for which the code was not designed (causing timeouts because of the unknown responses from those commands). Hence the "works on Win7 but not WinXP" problem.
This premise is now what I'm basing my advice on.
Disclaimer: This is only how I have perceived the situation given that I've had a hard time understanding many of the posts by the OP.
Its not LabVIEW developer in not understanding the protocol, I was in the team of development of arduino code. From last few days whatever testing was doing it was in production PC. Let me make something clear
1. One test sequence in which total 35 differenct command was working on WIN7 but not on XP3(production). Failing at *AA$
2. All 35 test sequence made same (*AA$), tested at production PC and worked fine for the same VI.
3. All 35 test sequence changed with two different command example below, tested at production PC and worked fine for the same VI.
*PON$ *POK$
*AA$ *A0$
repeated for 18 time.
As my original testing sequence in which there are all different command response is working fine at developemnt PC but failing at production PC at *AA$. *AA$ is my 3rd step to testing sequence and failing in such a way that I need to reconnect my arduino again to make it work