03-19-2012 09:58 AM
I think I found a bug in my code caused by a misunderstanding that I want to double check. I generally set a VISA (GPIB) timeout using the property node "General Settings:Timeout Value". Due to the multitude of GPIB communications I do, I always wrap by read and write code in VISA async locks. My previous assumption was that the timeout from the setting in the property node would transfer over and be used by the VISA async timeout node.
In the screenshot below, "5000" is hooked to the VISA async lock timeout value. If I were to delete that, would the timeout for the VISA async lock be "0" (the 'default' listed for that vi) or "500" (set in the property node)?
Thanks!
Solved! Go to Solution.
03-20-2012 10:16 PM - edited 03-20-2012 10:19 PM
Hi tkott,
The VISA timeout value property node sets the minimum timeout for any VISA call, whereas the VISA Lock Async.vi timeout input specifies the maximum wait time for that particular lock. The property node minimum wait (which defaults to two seconds) should take precedence when it is longer than the VI's timeout input, otherwise the timeout value input will define the timeout duration.
To answer your question, the property node will generally define your timeout unless you wire a larger value to the lock VI. Is that the behavior you are seeing?
03-21-2012 05:39 AM
Thanks Tom. I think that is what I am seeing. I'm guessing that the sheer number of VISA calls in one sub-vi is forcing a VISA call in a different sub-vi to fail after 500ms. They're all accessing a SIM 900 mainframe which has 7 active modules, so I'm not too surprised.
0utlaw wrote:
To answer your question, the property node will generally define your timeout unless you wire a larger value to the lock VI. Is that the behavior you are seeing?
That actually makes things easier: I can just up the value in my class constructor and things should improve.
Thanks!
12-11-2012 05:51 AM
Hi Have been given sim900 and some sub unit and ask to connect has anybody got working vi to learn from