I cannot access my multi-function DAQ hardware from VB/Meas Studio after upgrading to latest Meas Studio Version and NI-DAQmx

[JasonAtSeagate]

I have a farily complex project that was initially written in VB6.0 with Meas Studio 3.0 and using traditional NiDAQ.  For seveal reasons, I wanted to upgrade to the latest NI software.  So, I purchased the latest version of Meas. Studio.  I installed this, along with NI-DAQmx.  Now, I cannot access any of the hardware from the VB IDE / Meas. Studio DAQ objects.  Nor can I get the installed examples to run.  The test panels run ok from MAX. 

The whole process of trying to do this upgrade process has been extremely confusing and frustrating.  I have a support request in, but have yet to hear from anyone.  Trying to get useful information on this problem from the NI web site has also been difficult since almost all of the support doucments of any detail reference Labview.

Any help will be appreciated.

[Matthew_W]

Hello JasonAtSeagate,

 Which example are you running? What error is reported? What NI hardware are you using to acquire data with?
 The fact that test panels can acquire data is a good first step, we know the physical channels are ok, the DAQmx drivers are installed correctly and MAX is operational.

I just looked at this example:
   C:\Documents and Settings\All Users\Documents\National Instruments\NI-DAQ\Examples\DotNET2.0\Analog In\Measure Voltage\ContAcqVoltageSamples_IntClk\vb
When you run this example, you must first select a physical channel, then click Start before acquiring data.

The transition from Traditional to DAQmx can be confusing, here is a good document that explains some of the terminology changes between the drivers.

Thank you,

MatthewW
Applications Engineer
National Instruments

[JasonAtSeagate]

The problem is that the physical channels do not populate the ActiveX control. I now understand that DAQmx does not work with the ActiveX controls.  So, I have given up on DAQmx, at least for this project.  I need to add some additinal DAQ capacity to this project - so I will just go with another vendor. 

DAQmx should come with a big warning:

"Don't expect to use the very nice ActiveX DAQ controls with your project - you will need to use calls to the type library !!!"

[Matthew_W]

 MeasurementStudio v8.0.1 is not dependent on NI-DAQmx, Traditional DAQ can be used, but as you noted you will have
    to make calls into the type library.

  Which driver would you like to develop with? The DAQ Assisstant can make data acquisition/generation very easy.
  I'm including a quick walkthrough in creating a data acquisition program in Measurement Studio v8.0.1 with NI-DAQmx below
  for reference.

  What hardware are you using? I'd like to check and be sure there is no compatibility problem.

 Data Acquisition  with Measurement Studio v8.0.1 and NI-DAQmx:
 
    1. Create a new project, Measurement Studio->NI DAQ Application
    2. Create a new project task
    3. Select the type of task, for this example, Acquire Signals->Analog Input->Voltage, Click Next
    4. Select the physical channels, in my case Dev 14->ai0, Click Next
    5. Click Finish
    6. The Configure DAQ Component UI window will come up, Click Finish.
    7. The DAQ Assistant will complete the code, Visual Studio will launch in the Code View window.
    8. Click Start Debugging , the application will compile and run.
    9. Click Read, the acquisition will perform a N Samples acquisition and populate the graph with the result.

    
    Thank you and have a great week.

   Best regards,

   MatthewW
   Applications Engineer
   National Instruments

[JasonAtSeagate]

Hi Matthew,

I guess that your suggestion would be ok if we were talking about a new project.  However, I have an existing project - which is quite large and complex.  I merely wanted to add a board (for additional IO capability) that is only supported by mx.  However this would require that I re-write (and re-test) my exsting code.  If I had a lot of fee time, I might do that - but I don't.

Frankly, it is easier for me to get the additional IO cabability from another vendor than it is to mess around with mx anymore.  Maybe I will take it on as a learning oportunity for my next new project.

I really don't understand why support for the  ActiveX DAQ controls was dropped in mx.  The excuse is that Microsoft is moving away from the ActiveX model.  But, it appears to me that the remaining components of Meas. Studio, for example, UI and Analysis controls are still ActiveX.  Why not maintain legacy support for the ActiveX DAQ controls?  Probably not your job to say - I just wanted to vent.

[drohacek]

I'd like to better explain the decision not to provide ActiveX controls for DAQmx. My intention is not to de-legitimize your concern or downplay the pain/inconvenience this caused you.

The decision not to provide ActiveX controls would be more accurately summarized as a cost/benefit decision.

DAQmx is an entirely different API. The choice not to support mx with ActiveX controls was not a matter of dropping support from an implementation perspective (I understand that from a product-offering perspective, it is dropping support). Rather, the choice not to support mx with ActiveX controls was a matter of not designing and implementing an entire new set of controls.

Given our resources, we have to make choices about what languages (C#, VB.NET, C++, VB6), frameworks and versions (.NET 1.1, .NET 2.0, ASP.NET, MFC 7.1, MFC 8.0, VB6), and development environments (VB6, VC6, VS2003, VS2005) that we support. When NI decided that mx was necessary (that is, we could not move forward with new hardware under the old Traditional DAQ API), the Measurement Studio team had to decide which of these languages/platforms/ADEs to support.

We view the ActiveX controls as native support for Visual Basic 6.0. In March of 2008, Microsoft is going to stop supporting Visual Basic 6.0 (http://msdn2.microsoft.com/en-us/vbrun/ms788707.aspx). It was largely because of this that we did not feel that our customers, as a whole, would gain enough benefit from us developing ActiveX controls to justify the cost. Instead, we developed native .NET and C++/MFC libraries for DAQmx.

We developed the type library for mx because we did understand that some customers would want or need to use mx boards in existing VB6 systems. While this is not an ideal solution, we hoped that it would be good enough. I am sorry that it doesn't meet your needs.

Looking back, we see that our customer base has not moved away from VB6 and to VB.NET or C# as quickly as we thought they would. This is why the Measurement Studio product continues to include VB6 support (the UI and Analysis ActiveX controls that you mention) and why we continue to fix bugs in these components. However, we are not putting much effort into developing new features in these ActiveX controls. Almost all of our new feature development efforts are in the .NET libraries.