Measurement Studio 8.0?

[dualtronic]

A couple months ago, I heard about a new Measurement Studio (8.0) beta. When is the new version going to be released?

I've had a lot of trouble with Measurement Studio 7.0 so I hope this corrects some of the problems.

[Elton Wells]

The beta is for Measurement Studio 7.1, not Measurement Studio 8.0. I'm not at liberty to discuss release dates, but the beta period will not be long as it was for Measurement Studio 7.0.

I'm curious to hear more about the trouble that you had with Measurement Studio 7.0. Could you please list the problems that you had? Have you tried the Measurement Studio 7.1 beta? Do you see any of these problems in the beta? Thanks.

- Elton

[dualtronic]

I got an email offering to try the beta, but I never got a response after I sent a reply. But I would really like to try it. Please put me on the list if you can...

As for MStud7, I have two complaints:

1. It's missing many, many features that were included with the MStud6 ActiveX controls. This not only includes the UI controls (slider, etc.), but it also misses many of the math tools. For example, the array object is practically useless in MStud7. There may have been good reason to eliminate the extra functions. If so, then there should have been a document saying what to use instead.

2. DAQmx is overly complex and buggy. The MStud6 ActiveX controls were simple and stable. I know that NI is trying to make the DAQmx object "universal", but i
n doing so it has pushed out many of the non-professional programmers. I guess NI feels that if you can't figure it out, you should be using LabView. But that just isn't possible for companies that have put a major investment in VS.NET. As for the bug problems, DAQmx consumes resources and causes a lot of multithreading problems. Not everyone wants 20 threads running in their program. Also, it is impossible to run an application when the user is not a local administrator. This is very important in a plant situation. These are only a few of the problems I have found.

Another thing is the price ($1500)! I remember Componentworks 2.0. I think it was $500 and it was a breeze for newbies.

Don't get me wrong, MStud7 is a big step. But it needs a little TLC to make it worth the expense.

[bilalD]

Hello dualtronic

You should have access to the beta now. You can get to it by going to ni.com/beta. You can still download the Measurement Studio 7.1 beta and we appreciate any feedback you can provide for the product. You should also have gotten an email from the beta coordinator at the email you used to register the last time. If you still do not recieve an email, please email the beta coordinator at mstudio.beta@ni.com.

We had some initial problems with the beta setup this year and somehow the beta coordinator never received your response. I apologize for any inconvenience this may have caused you.

I'm pretty confident the Measurement Studio 7.1 beta will address your complaint about the missing features.

As for the DAQmx issu
es, please provide us feedback about some of the issues ( in addition to what you think about the beta components ofcourse) you have dealt with as a part of the beta feedack. We're always trying our best to improve the user's experience with our products and the more feedback you can provide us, the more we will have to work with.

If you have questions about the beta, you can email the beta coordinator at mstudio.beta@ni.com.

Bilal Durrani
NI

[drohacek]

I understand your frustration with the complexity of DAQmx, compared to the Traditional DAQ ActiveX controls. I'll try to give you some information on where we are coming from on the issues that you brought up.

Regarding CPU utilization - Check out this post for more information on the issue. The short of it is that this behavior is by design. The DAQmx driver essentially acts like the system idle process. It utilizes 100% CPU time when no other processes need the processor and yields the processor as necessary. However, we do understand that under many circumstances, users do not wan this behavior. We are evaluating ways to make this behavior customizable in future versions of the product.

Regarding threading - the DAQmx driver utilizes threading in as a key part of its internal architecture to gain significant performance benefits over the Traditional DAQ driver.

Regarding the complexity of the driver in general - many customers were frustrated by the lack of consistency in the way the DAQ driver supported various NI DAQ products. Users felt like they had to learn a whole new API when they changed a DAQ board or when they added a board to their system. One of the goals of the DAQmx driver is to provide a consistent, measurement-oriented API across the breadth of NI-DAQ hardware products. This results in more entry points in the API.

Regarding the complexity of the .NET API relative to the ActiveX controls - the ActiveX Traditional DAQ API did not include all of the features included in the LabVIEW Traditional DAQ API. This led to a lot of frustration on the part of Measurement Studio users. They could not be assured that they would be able to take advantage of hardware features without switching from Visual Basic to LabVIEW. The .NET and C++ DAQmx APIs currently support (and will continue to support) all of the hardware features that the LabVIEW API supports. Support for new hardware features means more classes, methods, and properties.

Regarding the ease of use of the ActiveX controls vs. the .NET API - admittedly, the ActiveX controls provide a rich design-time configuration experience through the property pages that is missing from the .NET DAQmx API persay. Our intention was to replace this functionality with the DAQ Assistant, integrated into Visual Studio .NET as a code-generating designer. You use the DAQ Assistant to interactively configure your DAQmx Tasks, much in the same way that you would use the ActiveX control property pages to configure an acquisition or generation in Traditional DAQ. Additionally, Measurement Studio includes a User Control generation feature, which generates code that demonstrates how to acquire data or generate data through a task.

Have you used the DAQ Assistant and/or the User Code generation wizard? Do you have any suggestions on how we might improve these tools to help improve the usability gap of the .NET API?