From Friday, April 19th (11:00 PM CDT) through Saturday, April 20th (2:00 PM CDT), 2024, ni.com will undergo system upgrades that may result in temporary service interruption.
We appreciate your patience as we improve our online experience.
From Friday, April 19th (11:00 PM CDT) through Saturday, April 20th (2:00 PM CDT), 2024, ni.com will undergo system upgrades that may result in temporary service interruption.
We appreciate your patience as we improve our online experience.
08-22-2012 11:08 AM
Hi,
PC with Window 7 and GPIB-USB-HS to GT9000s (Gigatronics Signal Generator) are used for the test. The program is used to change the setup and do some local process then change the setup again - power/frequency/PM. It always stops after around one and half hours operating - aroun d 800 times talk to the device.
From some website, it is mentioned that the fast PC with slow device causing it. Some suggested to change the rate - I am not sure how to change the rate.
Any suggestion for solving it?
Thanks,
Ott
Solved! Go to Solution.
08-22-2012 02:38 PM
Can you post the code?
08-22-2012 02:45 PM
Here you are... Here is the code with a loop keep changing the parameters.
Thanks,
Ott
08-22-2012 02:52 PM - edited 08-22-2012 02:53 PM
There are no loops. You said after about 800 iterations. You are not using run continuously are you? But probably this is a subVI that is being called in a loop?
Generaly you open and configure outside of a loop, execute some commands inside of a loop, and close the device after the loop executes. You would typically do this using a state machine with an open, execute and close state.
But sometimes serial devices can just be finicky. I have one that just times out every once in a while. What I do to fix it is check for the timeout error and try again. If there were five errors in a row then I return the error.
Edit: And if this is a subVI being called in a loop, you should get rid of the Simple Error Handler. That only belongs in top level VIs and not subVIs.
08-22-2012 02:57 PM
Thanks for your comments. but the issue is if it happens, the only way I could talk to the device again is to power cycle it.
I don't think the loop could cause it.
Any suggestion?
Thanks,
Ott
08-24-2012 09:39 AM
It's resolved. I removed the turn off before set and turn on after process, and seperated the command in its individual loop instead of setting once in the inner loop.
Thanks,
Ott