Asynchronous custom device fails to shutdown

[GSinMN]

Hello Stephen,

  The fuctionality I am implementing is for error handling.  In my Sub VIs, I monitor errors and warnings, and write them to a text file.  Since the error handler runs continuously as part of the "execute" VI, I implemented the delay to allow for file writing, and to give the VI a chance to fix itself before writing the same error to the file.  If there are no errors or warnings, the delay is bypassed.  Right now, I have the delay set to 10 seconds.

  All that being said, from what you are telling me, the FIFO error may have nothing to do with my file writing.  Perhaps the data I am writing to the channels has something to do with the issue?  Right now I am using only 5 channels.  For the first, I am passing the absolute time into the custom device (for timestamps), and the remaining 4 are test signals (simple sinewaves generated in a Matlab model).  For all 5 channels, the input data is passed in double precision, and is changing constantly. 

GSinMN             

[StephenB]

maybe do a feedback node and check if you get the same error value twice? if you do, don't write to the file. that way you can run at a much higher rate (same rate as your error generating code).

[GSinMN]

Ultimately, I will implement a more efficient error handling scheme, that will likely include a feedback node.  Right now, I'm still in the proof-of-concept stages, and just trying to establish basic functionality. 

Did you have any more thoughts on the FIFO being deleted before the loop is done?  My error file writing can't really be effecting it because I don't even enter the writing loop until after the error occurs.  Additionally, while I am still working out the basics of this, I reset the error cluster every time I see an error, just to make sure I see every error (recall that the built-in error checking will only propagate the first error through to the end).

Thanks,

GSinMN       

[StephenB]

can you post your error handling VI?

you should filter out error -2206 and error −307557

[GSinMN]

Hello Stephen,

  See attached.  I actually use a combination of 2 sub VIs for error handling.  The first will check for errors, build a summary data string to send to the writer Sub VI, and then reset the error cluster.  The second is the actual writer.  The reason I have them separate is because there are several instances of the checker VI, but only one instance of the writer VI.  Thanks.   

GSinMN  

[StephenB]

I don't see any timing related stuff in here. Should be fine. the minor change you can make to get better performance and behavior would be to only log when an error has changed, like we discussed.

One thing I've done before in custom devices is have an asynchronous "error reporting" loop that I launch at the beginning of my custom device. that loop just listens on a queue for errors it needs to log. the rest of the custom device pushes any new errors into the queue. To tell the error loop to shut down I just delete the queue

[GSinMN]

Sounds like a good idea.  I'll keep your reccommendations in mind as I optimize my design.  Thanks for taking the extra time to look at my scheme. 

Regards,

GSinMN

[StephenB]

sure thing! hope it works out well