10-23-2008 11:12 AM
Hi Nick,
The GpibStatusFlag.End flag will occur when END is asserted. You have set the END to not be asserted on the end of the string and it seems like your device isn't always setting END.
mGpibBoard.SetEndOnEndOfString = false;
This line could be causing some of your problems if the device isn't setting end every time.
National Instruments
10-23-2008 12:28 PM
Hey Caleb,
So sometimes it does set the end? I did a GpibStatusFlags statusa = Unit.GetCurrentStatus(); and the statusa showed the End event happening (just did it a couple times). I'll try setting both the Board and individual Device objects SetEndOnEndOfString to true and see what happens.
Thanks,
Nick
10-23-2008 12:36 PM
Hey Caleb,
Yeah, that didnt help either. Still times out at the Read part randomly. Any other ideas?
Thanks,
Nick
10-23-2008 01:27 PM
Hi Nick,
It appears that your device is not always setting END and is not always sending a termination character. It seems to be getting hung. You will want to put a wait between the read and the write, but unless your device sets a line when it is complete you cannot find when the device is done with its computations.
National Instruments
10-23-2008 02:37 PM
Hey Caleb, Ok, I thought that's what the MAV stuff was for. The Lambda power supplies says it sets that when the message is available, so I shouldn't need the wait.
So I just tried turning off all the power supplies, then running my software, and it seems to work now! I am complete baffled. Did the Board device maybe need to be reset for the changes to take place for each device? Any ideas why it might work after rebooting (guessing it something to do with the Board or Devices). Should I be doing any resetting or clearing or anything that you know about to get the Boards/Devices into a know/non-error state?
Thanks,
Nick
10-23-2008 02:48 PM
Hi Nick,
Glad that it's working for you! It sounds like the device just wasn't sending proper responses. It should work fine now as long as the device continues to operate with the same specifications.
National Instruments
10-24-2008 10:57 AM
Hey Caleb,
I have a capture file from the NI Spy program. It shows the timeout I think in the red, but I'm not sure what is causing it. It looks like it works for some cases, but not others. Could you take a look at the file and let me know if you know why it fails?
Thanks,
Nick
10-24-2008 11:38 AM
Nick,
If this error is still happening you will need to ensure the proper configuration of your device. The EABO status is usually due to an error in handshaking. You can see the description of this error in this Knowledge Base document: http://digital.ni.com/public.nsf/allkb/A80DBFCCAC36EBDE862562C80058856E?OpenDocument.
National Instruments
10-27-2008 10:34 AM
Hey Caleb,
As it turns out, the power supply was timing out on the reads. The problem is I set the timeout value to 300ms which I thought would be plenty of time to get a ReadString response back. I am using 2 LAMBDA,GEN30-50-IEMD,S/N:27E7411,REV:1U:3.0-E power supplies. I've tried switch out power supplies to see if that would change the timing, but it doesnt seem to help. I changed the timeout to 1 second, and i was seeing delay times of almost 500ms! Do you know or could ask why the lambda power supplies takes so long to response from a simple voltage or current query? Is there any known issues with the software or communication that I should know about?
Thanks,
Nick
10-27-2008 05:26 PM
Hi Nick,
I'm not very familiar with that model. Who is the manufacturer. You would probably be best contacting the manufacturer to see what can be done to solve the problem.
National Instruments