Closed ryanolf closed 12 years ago
Could you paste in the log output? I'll take a look.
The RFSG output alternates between the following, between runs. (Here I started and stopped the run, but it doesn't matter.) I should mention that we are using RFSG 1.6.2. I'm downloading a newer version of the drivers to see if that helps.
6/14/2012 11:16:21 AM AtticusServer.RfsgTask: RFSG command to initiate device gave error. Device probably already initiated.
6/14/2012 11:16:21 AM AtticusServer.RfsgTask: RFSG commanded to enable output
6/14/2012 11:16:21 AM AtticusServer.RfsgTask: RFSG commanded to frequence(Hz)/amplitude(dBm) 1200000000/-109.97940008672
6/14/2012 11:16:22 AM AtticusServer.AtticusServerCommunicator: Received a STOP signal. Stopping any currently executing runs.
6/14/2012 11:16:22 AM AtticusServer.AtticusServerCommunicator: non-daqMx Task AtticusServer.RfsgTask finished.
6/14/2012 11:16:22 AM AtticusServer.RfsgTask: Aborted rfsg task running thread.
6/14/2012 11:22:54 AM AtticusServer.RfsgTask: RFSG commanded to initiate output (enter committed state)
6/14/2012 11:22:54 AM AtticusServer.RfsgTask: RFSG commanded to enable output
6/14/2012 11:22:54 AM AtticusServer.RfsgTask: RFSG commanded to frequence(Hz)/amplitude(dBm) 1200000000/-109.97940008672
6/14/2012 11:22:55 AM AtticusServer.AtticusServerCommunicator: Received a STOP signal. Stopping any currently executing runs.
6/14/2012 11:22:55 AM AtticusServer.AtticusServerCommunicator: non-daqMx Task AtticusServer.RfsgTask finished.
Ryan, are you able to compile / run Atticus from source? I have a possible fix put together, wondering if I should send it to you as a binary or just point you at the right commit.
Hi Ryan,
Try the .zip file I just uploaded "RFSG_FIX.zip" and let me know if this fixed the issue.
As of commit 5d309d1 -- what I did: There is now a static Dictionary from RFSG devices to bools, which keeps track of whether a given device is believed to be "Initiated". This flag is set to true when an Initiate command is successful, false if a command fails OR if an abort command is successful. If the flag is true, Initiate commands are skipped.
My one concern is that if the flag is errantly set to True, it is possible that the device could go into an uninitiated state and then would never receive further Initiate commands.
I don't have a convenient way to test out these changes at the moment, so let me know if this is working or doing something funny and new.
Aviv
(this not very elegant fix was required since, in answer to your question: "Or is it possible to query the card to find out if it is already initiated, and send the Initiate() command conditionally?" -- it would appear to be No. At least, I couldn't find an RFSG API call that would tell me this).
I've got it compiling so if you tell me the commit I can try it out.
On Jun 14, 2012, at 12:02 PM, Aviv Keshetreply@reply.github.com wrote:
Ryan, are you able to compile / run Atticus from source? I have a possible fix put together, wondering if I should send it to you as a binary or just point you at the right commit.
Reply to this email directly or view it on GitHub: https://github.com/akeshet/Cicero-Word-Generator/issues/2#issuecomment-6337606
Aviv, thanks for the fix. I'll check the it a bit later. Have experiments to run right now.
Ok, the fix is working here. I can now leave AutoInitiate=True. Hopefully this doesn't cause problems for other people. Thanks a lot Aviv!
Leo Stein (@duetosymmetry) says hi
Hello to Dr. Stein.
On Thu, Jun 14, 2012 at 2:42 PM, Aviv Keshet < reply@reply.github.com
wrote:
Leo Stein (@duetosymmetry) says hi
Reply to this email directly or view it on GitHub:
https://github.com/akeshet/Cicero-Word-Generator/issues/2#issuecomment-6344142
When AutoInitiate is enabled for our PXI-5650, the initiation is attempted every time, but when the device is already initiated, the initiate command actually disables the output. The Initiate command throws an exception, it is caught, and the log notes that the command failed. However, it does not take any action to correct the problem. This seems like a bug in the RFSG drivers: the initiate command perhaps should throw an exception, but it shouldn't disable the output. Obviously, the drivers are not under our control. This bug has been present since the beginning of RFSG integration.
A workaround might be to re-send the Initiate() command in the catch, except that I'm not sure what sort of adverse effect this might have on other cards or in other use cases. Our current "manual" work around is to enable AutoInitate once every reboot of the system, and then to turn it off.
Is there some information in the exception that could be used to determine if sending a second Initiate() command is necessary? Or is it possible to query the card to find out if it is already initiated, and send the Initiate() command conditionally?