LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Robust and Reliable Digital IO with DAQmx

thanks for the replies, the Action Engines nugget is very helpful.  nice tesla coils, I'm working on an app that machines micro structures, too small to view with the eye.

 

I use a parallel loop with state machine on the top level diagram of my Manufacturing App to handle Digital Outputs, enqueuing True/False to change the state.  I've not tided all of Digital Inputs yet.  The important Digital Inputs that monitor plant are sampled by a separate Logger App exe, I log all the rising/falling edges to file to aid with the investigation of fails.  The Logger App exe constantly updates the manufacturing App via TCP/IP, Logger being the server, Manufacturing App the client.  Periodic updates received by TCP/IP are held in a Functional Global with a simple Get/Set enum to a dedicated FG for each input.

If I start using Open/Close/Clear task, I have the added complexity that both Logger App and Manufacturing App are able to run independently or together.  One App could close a task the other App is using.

The main reason I use the Logger App in the way I do, is to reduce the total time of the main thread in the Manufacturing App, total manufacturing time is motion time plus computing overhead that's executing in-line with the motion thread.

One solution would be to put all Digital Inputs in the Logger, but that would mean if the Logger crashes or is accidentally closed by an operator, the Manufacturing App would fail.

At present I protect against that scenario but checking the timestamp of the last TCP/IP update from Logger App, if data is old, I use a DAQmx Read to sample the IO directly.  Adding Open/Close/Clear task would mess with that design scheme.

Action Engines allow for multiple processes to share a single copy of the Digital Input, but it's the sharing of the Digital Input between Logger App and Manufacturing App that's causing me a puzzle.

If it's safe to use this VI anywhere in the Manufacturing App?  am I'm safe from crashes.NI-6515digitalIO-code.JPG

Does anyone know what's happening under the bonnet of LabVIEW & MAX ?  My concern is that every time someone re-starts Manufacturing App, a new task reference is created and over time this leads to an accumulation of open references, or possibly a resource in use error if Logger App happens to be sampling the Digital Input at the instant Manufacturing App is started.  It appears to function okay so far.

 

 

0 Kudos
Message 11 of 11
(280 Views)