DAQmx port read/write questions

[CharlieD]

Environment

WindowsXP SP3

LabView 7.1

NI-DAQmx 8.7.1

(2) PCI-DIO-96 cards

I am attempting to change over from TDAQ register level programming to DAQmx and giving myself a "crash course" in mx.  I am not sure about a couple of things.

I need to set up 20 channels/tasks that will perform a mix of single, port wide (8 bit) reads and writes.  Some will be handshaking (82C55 mode 1) and some no handshaking (82C55 mode 0).

The plan is to create all of the tasks during an init routine and save the task names into globals.  I would leave the tasks open after creation and use the globals during execution of the main body of the program when I do the port reads/writes.  The main body may be running for hours at a time.  When the main is closed, the shutdown routiine would close all of the tasks prior to exit.

With reference to task creation/destruction - is it safe to create the tasks and leave them open, or should they be created/destroyed each time a read/write is done?

With reference to port reads/writes, I assume that when a single port read/write is done, there is no buffer created.  Is this correct?  Specifically, if I use the above method and leave tasks open, is there any chance of buffer overrun or something similar happening?

TIA

Charlie

[JÞB]

Congratulations on moving to DAQmx! 

A couple of pointers on Tasks:  Yes, you can programatically create them and store them in a global variable but, why?  There are a few drawbacks to doing this beyond the use of Global Variables.  Tasks can be configured and saved in several ways and each has some advantages.

1st using the create/destroy task LabVIEW API functions.  works great but requires you to either know or programatically determine the device aliases (from MAX) This is pretty simple and works great if you develop on the end target system i.e. programming in the lab.  Disadvantages: MAX import/export between machines and system troubleshooting.

2nd Create the tasks in MAX with the DAQ wizzard and use those tasks in LabVIEW.  The Task constant will let you call any configured task without the need to recreate it  also you get the benifit of being able to run the same task (or change its properties) in MAX for prototyping and debugging.  Disadvantages: anyone can change your task simply by fat fingering MAX and break your application also you need to deploy the MAX settings to the target machine if you have a large number of jobs for a specific piece of hardware the MAX configuration can get very cluttered and you'll have trouble finding "Task XYZ for Project umpity-five Test ABG."

3rd Create Tasks in the LabVIEW Project where they will be used.  This associates a Task with a specific set of vi's that will use it and you still have the DAQ Wizzard to create, run, debug, and edit the tasks.  Plus this allows you to selectively deploy the tasks without much effort and requires the LabVIEW IDE to edit your task so it is not going to get fat-fingered by an operator breaking your deployed application.

I have a preferance for using approach 3 and creating little "Modules" like this example for use in applications I develop for clients-  note the VI Documentation that lists the requirements for Hardware and Alias  And the use of a USR to hold the task rather than a "Global variable"

[CharlieD]

Jeff,

Thanks for the quick reply.

I had already decided to do all of the task creation inside the project, so we are thinking along the same lines there.  Unfortunatly, we are running LabView 7.1 so I can't open your attachment.  I think I get the general drift of your explanation.

Once created, is it a safe practice to leave the tasks open during main execution (for hours of run time) and close at end of execution?

If leaving the tasks open and doing single port reads/writes, I should not run into buffer problems, correct?

Charlie

[JÞB · Accepted solution]

Sorry about that - Yes you mentioned 7.1- I cant save back that far from here but here's a screenshot

And - the task is saved external to LabVIEW so it really isn't "Opened" or "Closed" even when programmatically creating and destroying tasks.  Tasks exist or do not exist.  If they exist and have no errors they can be run.  

Buffers are for moving data to or from the device.  For static DIO this is not an issue.  You COULD run into problems with a contiuous acquisition task if it is acquiring data faster than you read the data but you can get around this by starting and stopping the task appropriately.