set number of samples in daqtask

[ifisch]

Hi - I'm using a DAQ-Assistant-generated Daqtask Component to collect asynchronous data. The daqtask.mxb that the Assistant generated includes a textbox for specifying the number of samples per channel (as well as the sampling rate), but I want the user to be able to specify this at runtime. In the old Componentworks, it was just a property of the CWAI component that could be programmatically assigned. Anything analogous to this? I've looked at the analog input examples included, and have a sense of how this might be done directly with a multchannel reader, ReadFinite, etc., but the ComponentModel approach makes some other things simpler, and I'd like to keep it.

thanks -

Ira

[Ima U]

Hi Ira,

Assuming you are using LabVIEW, my suggestion is to right click on the item you would like the user to enter during runtime and choose "change to control".  Controls are values that the user has to enter in either prior to each run or to enable each run.  If you are relatively new to LabVIEW you should go through the Learn LabVIEW in Six hours.

I hope this helps!

[ifisch]

Hi Ima -

Not a Labview person; I've been learning VB 2005 within the Visual Studio Net platform. Something equivalent to the LabView procedure?

- Ira

[Song_D]

Hi, Ira,

I'm afraid that there's not an equivalent procedure for DAQ assistant in .NET.

There is a way to get around it if you really want to use the assistant, rather than modifying the examples. Whenever you set up the DAQ Assistant to create all of the code for you (which, by the way, you are wise not to attempt to recreate because that would be a pain), it generates a file in your project corresponding to the name of your mxb file (DAQmx task) that you created. To view this file, click on any item under your project in the solution explorer and then click on the "Show All Files" button at the top of the solution explorer (this should be the second button from the left, depending on version).  Now, you should have a *.mxb file inside of your project (named according to your DAQ task name, such as "DaqTask1.mxb".  If you click on the plus sign next to this, two things should show up underneath this file: one file with the same name of the mxb file, except .vb and a file that contains the word "User".  Click on the second file with the word User.  This file is a customization of the DAQTaskComponent1 object. You can then add your custom function in the user.vb file. Then in your main form code, you can call that function to change your DAQmx task setting.

Now based on your originial post, it sounds like you were using Traditional DAQ driver before. The DAQ assistant is part of our new driver, DAQmx. The APT for those two drivers are drastically different. So let me recommend this source to you. It should help you with the transition.

Song D

[JonathanN]

Hi Ira,

You may also want to check out the Adding Custom Functionality to a .NET DAQ Component help topic in the Measurement Studio Help. It discusses how to enhance or extend the code that the DAQ Assistant generates for you. 

All the help topics for the DAQ component are found under the NI Measurement Studio Help >> Developing with Measurement Studio >> Developing with Measurement Studio NI-DAQmx >> Creating a Measurement Studio DAQ Application >> Creating a Measurement Studio DAQ .NET Application.

Hope this helps!

Best Regards,

[ifisch]

HI Song -

Thanks for the suggestion. As it turns out, I followed closely to this path just yesterday. I'd read the comments on the Assistant-generated code, in particular the DaqTask.User.vb code, regarding adding custom functionality (also finally found the Help section on that - not a trivial task), and that this was the place for example to expose methods and properties not done so by the assistant-generated component. Groping around the examples, I entered [Task.Timing.] within the OnCreatedTask function, and lo and behold the SamplesperChannel method comes up. I was able to complete it as follows: Task.Timing.SamplesPerChannel = intNumSamp  (where intNumSamp had been defined and set in my own forms' code). Worked like a charm. I don't know enough yet about dotnet and how VB2005 coordinates the various components of a project to know how this works, but I'm happy.

Stepping back, it's been a lesson about the challenges of how to make a more complex and powerful system as transparent and usable as simpler generations. The old traditional NiDaq Componentworks was, from my perspective as scientist/programmer, pretty easy, once I got the hang of the forms & components OOP approach. In comparison, doing the same things with the new system, while ultimately as straightforward, was much more difficult to implement. Figuring out what was where, getting different versions of MS, VB and .Net to handshake, and especially the different approach taken by the assistant, on one hand, and the sample programs on the other, was often frustrating. I still wonder where to look, for example, to learn about other properties and methods of the DAQ task that I might need to know - is the Task.Timing.SamplesPerChannel documented anywhere? I understand that with thousands of classes, methods etc., it's impossible to have tutorials for it all, but I do have to say I felt the need for a professional software developer who could at least look over my shoulder, much more with this generation than with the previous one. (Well, maybe I shoulda bought into LabView.)

thanks again,

- Ira


 

[ifisch]

Hi Jonathan (& Song et al)-

thanks for the follow-up. See my comments to Song about resolving my NIDaq problems. I'm now exploring the NI Zone tutorial on the Transition from traditional NiDaq to VB net, as Song suggested. Likely would've been helpful earlier - I'm not sure I'd accessed it before; possibly did and passed by because I wasn't coming from a VB6 background (but of course I realize now it's still relevant). Anyway, thanks for all the help and guidance. As to poster on my wall says, Learning Never Ends.

- Ira