Error -201133 occured at DAQmx Start Task

[Christ0phe]

I have recompiled two versions of the application where I reserve each task in two consecutive and separate frames.

V4: CMD WakeUp is reserved before

V5: CMD WakeUp is reserved after.

Both application work with no error with Max 4.6.1 installed.

Both application give the same error code as before with Max 5.0 installed.

So no progress unfortunately.

Thanks again

Christophe

[ThiCop]

Hello Christophe,

I still don't get any errors with these executables.

Can you share the source code behind these executables?

I'm using the same DAQmx driver as you, the only difference is the version of MAX I'm using (5.1).

Is it an option to upgrade to a new DAQmx driver or not?

If yes, can you try this: http://joule.ni.com/nidu/cds/view/p/id/2933/lang/en

What I would first advice you to try is to back-up your configuration data in MAX and afterwards do a reset of MAX.

Doing a reset of MAX can be done by going to:

Tools>Reset Configuration Data

[Christ0phe]

Here is what I did:

- reset MAX using the command that you suggested

- restarted PC

- all errors still there

- upgraded to DAQmx9.3.5/MAX 5.1

- restarted PC

- all errors still there

- reset MAX

- restarted PC

- all errors still there

When i say 'all errors still there', I mean: using MAX and the 2 application.

See attached the code of the 2 applications I am using.

Isn't somewhere a king of log file that would provide more info as to the problem that occurs?

Thanks

Christophe

[ThiCop]

Hello Christophe,

Looking at the VI's you sent me it seems like you didn't completely understand my explanation about the order of VI's.

I was talking about the order in which the DAQmx Start Task VI's are called.

This is the one that you have to do in a specific way.

This was also shown in this KB: http://digital.ni.com/public.nsf/allkb/0495B7D5E2345DF386257730007EFD17

Can you implement this through a Flat Sequence Structure and inform me about the results?

[Christ0phe]

Although the reference that you point out refer to a mix of Digital Input and Output -which is not the case in my application where I only use Digital and PWM output- I have nevertheless implemented it the way it says. I made one version with the reservation of tasks and the other one exactly as mentionned in the reference. No improvement. Always the same error.

Thanks

Christophe

[ThiCop]

Hello Christophe,

Thanks for the extra work.

While looking again at your code I saw a possible cause of your resource issues.

To have  short summary:

At your side you were also not able to reproduce the issue with simulated hardware?

There are several things that are troubling me in the code itself.

- You're not wiring the error clusters completely through your code.

- Using the "Abort Execution" function in combination with real hardware is often the cause of resource issues.

This forces your code to abort/crash while resources are still allocated to specific tasks.

I'll create an example from scratch.

Can you redefine which things you would absolutely need in the code to happen in parallel?

Then I'll make an example that just does this and works with my hardware set-up over here.

[Christ0phe]

Hello

I really feel that you are trying to avoid answering my questions. It is sad. Since the beginning I mention that the issue arises in MAX itself (but not in MAX 4.6), so why focusing on the code?

The only thing I need is clearly depicted in the codes already sent: to be able to start 2 tasks, one digital output, one PWM output, and be able to change the value sent to each of those outputs (in the while loop). In parallel I should be able to act on an analog output. Nothing more.

The reason for the wire prolonged outside the error cluster are just to there to be probed more easily.

Thanks.

[ThiCop]

Hello ChristOphe,

I'm not avoiding answering your questions, but in our database I didn't find anything that mentioned this error ever being related purely to the MAX version.

I wanted to be able to reproduce the issue at my side to actually fix it if it is a bug in MAX or the driver.

Personally I think that the issues is not situated in MAX itself , but rather in the used driver or the code.

MAX on itself will not cause the code to fail.

Also when running your application MAX is normally closed.

In that case it cannot be MAX that iscausing the issue.

What could be the case is that a specific task (or combination of tasks) or change in driver version causes this problem

If you solely want to focus on the MAX version itself, then this is also ok for me.

Reverting back to an earlier version of MAX can however not be done with one simple uninstall/reinstall.

When you update some software or drivers (with newer versions) this will in some cases also update the minimal required MAX version.

This minimal required version for those drivers will then of course also be installed.

In this case the sure way to garantee that everything is "ok" when reverting back to an earlier version would be to perform a clean reinstall of your NI software and drivers.

This means that you uninstall all NI software and install exactly the software that coinstalled with MAX 4.6 on PC1.

This would give the possibility to check if the problem is located in the actual software set-up (MAX, LV, drivers) or something else (LV code, HW, MAX,...)

What you could also try as a first step to show tht the issue solely resides in the MAX version is the uninstalling the different software versions:

DAQmx 9.3.5

VISA Runtime 5.1.0

Traditional NI-DAQ Legacy 7.4.4

And afterwards reinstalling the working DAQmx and VISA Runtime

This could give an indication about where the problem resides without having to reinstall everything.

I would still like to make an example set of code that you can use to test where the problem resides.

Would this be ok for you or would you prefer me to not do this?

[ThiCop]

Hello Christophe,

One other thing that I found bizar in your MAX configuration.

In your VI you use tasks:

PUMP_PWM

Commande_Tension

Digital Out

In MAX 4.6 you have these tasks available:

PUMP_PWM

Commande_Tension

No "Digital Out"  Task is available

In MAX 5.0you have these tasks available:

PUMP_PWM

Digital Out

No "Commande_Tension" task is available

Is this still the case at your side?

if yes, which tasks do you use instead?

[Christ0phe]

Hello

In MAX 5.1 I use "Commande Tension" without "_", but both tasks point towards the same analog output channel.

In MAX 4.6, the Digital Output task is called "CMD WakeUp" but again points towards the same channel than its couterpart in MAX 5.1 (DigitalOut).

The reason why I am insisting on MAX is that I do not get the same behavior in MAX 4.6 than 5.0 and 5.1. In MAX 4.6 I am able to launch both tasks (Digital Out and PWM) concurrently and moreover whatever the sequence (PUMP_PWM then CMD WakeUp or vice versa). Everything works. This is NOT the case with MAX 5.0 or 5.1. I am not talking about any Labview code here. Only MAX. Does MAX depend on my own written Labview code, I do not think so...

As I am having the problem on different stations that were running well with Labview 8.2.1/MAX 4.6 then no more after an upgrade to DAQmx 9.3.5 and MAX 5.0, I have uninstalled all NI products and reinstalled Labview 8.2 and MAX 4.6 (I do not recall which version of DAQmx did enclose that MAX version). No problem anymore !

Thanks

Christophe