DAQmx base error -50103

[cbfreder]

I am currently porting a functional application on the PC using DAQmx with PCI-6251 and PCI-6713 to Mac OSX with DAQmx Base and the same hardware.  I have finished manually changing the DAQmx VIs to the DAQmx Base VIs and fitting the new VIs in with the existing code.  However, whenever I try to use the hardware LabVIEW gives me a -50103 error with a message along the lines of "The DAQmx Base globabl config is reserved and could not be accessed.  Please quit the DAQmx Base Configuration Utility and try again."  I am fairly certain that this utility is not running and that the current user has sufficient privledge to read and change the necessary files.  What may be causing this problem?  Are there any limitations to DAQmx Base other than the obvious ones that may be contributing to this problem?

Thanks,
Brandon

[Tom_W_[DE]]

Hi Brandon-

One limitiation of NI-DAQmx Base that is not a consideration when programming with NI-DAQmx is the fact that NI-DAQmx Base is not multi-thread safe.  This is outlined in the NI-DAQmx Base ReadMe as follows:

---

NI-DAQmx Base is not multi-thread safe. In LabVIEW, use the error cluster to force execution order. In C, use only one thread to make API calls; especially for task/channel creation and deletion.

---

You will need to make sure that you do not have parallel branches in code and that the error cluster follows through the entire chain of operation.  I have attached a VI that shows how the error cluster can be used to force only a single thread of operation.  Please keep in mind that this is an example written for Windows so it might not be functional with your card, but it should give you an idea of how to force execution order on the VIs.

If this ends up not being the problem, please post back here with any more info you think might be useful or a SMALL portion of your code that is acting up to see if we can have any luck reproducing the problem.

Good luck!:manhappy:

[Poormanphysics]

Hello:

What can be done here? The shipped example for PID Control for Multichannel is having a problem with this error too.

FYI.

Berns B.

[Tom_W_[DE]]

Hi Dr.Berns-

Your example is an NI-DAQmx example and not an NI-DAQmx Base example as discussed in this thread.  So, you are not seeing the same problem with your PID example.

The problem you are seeing with NI-DAQmx is likely that you are trying to run the two analog output tasks from that example on a single card.  This is not possible and will result in the error you are seeing.  From the documentation for that example:

---

 Note:  The 2 analog output tasks are on two separate devices.

---

You can never have two analog input tasks or two analog output tasks on the same card at the same time.  Am I correct in assuming that this is the problem?  Please post back if not.

Thanks-

[Poormanphysics]

Hello again:

You are right! Now late night at the lab I figured that out. Here is the code I attempted to to solve the problem but when I test them I can't "decouple" the outputs right? What happens is  either I do not have anything on sero drive Y (dac ao1) or when I have it actually influence the the first servo drive (ao0) output? It seems that when I only have the first servo drive i is ok both not with both? How can I decode the input feedback to correspond to the output? Note: I wanted two independent P-controllers here.

Thanks.

Berns B.

Message Edited by Dr.Berns on 10-23-2005 05:55 PM

[Tom_W_[DE]]

Hi Berns-

I am assuming you want to read only two analog input channels and then write PID values out on your card's two analog output channels.  The reason you are seeing the problem with your analog outputs is that you are using the DAQmx Read VI improperly.  You should use one DAQmx Read VI per task and write an array of values to the task to update all channels at the same time.

If this is the case, you only need to create your analog input channel once and use "DevX/ai0:1" for the channels.  Since you are using the Hardware-Timed Single Point mode your DAQmx Read should return a 1-D array of values.  You should then index the appropriate values from the array and input them to the PID VIs as single points (rather than using the entire array).  The outputs of the PID VIs will then be single points that you should build into an array and write to the output task using a single DAQmx Write VI.  Also note that it isn't necessary to create the analog output channels twice; a single call of the DAQmx Write with "DevX/ao0:1" will be sufficient.

This operation should be straightforward.  Let me know if you have any additional questions.

[Poormanphysics]

Hello Tom:

Well just one more overnight work in the lab and a lot of reading from all over LabVIEW and trying it out it out in the optical bench seemed to be the formula for success. I followed your indications one by one this seemed to work now. I wish I could still write in the manner with the legacy DAQ Analog IO used as quite clear compared with new DAQMx but 6251s don't like it. I haven't seen how the two proportional controller code has been corrected or commented in the forum (maybe to easy to bother?) but I still want to see that corrected and working too. Here is what I have now.

Anyway another day in the lab.

Thanks,

Berns B.

[Tom_W_[DE]]

Hi Berns-

Your new VI looks great!  Are you having better results by using that method?  I also spent a few minutes updating the PID example to a point that it should work with a single card 2-channel solution.  Please take a look and let me know what you think.

Thanks-

Message Edited by Tom W. on 10-24-2005 10:20 AM

[Poormanphysics]

Hello Tom as long as I get to have a good advise from NI I can and enable to make improvements. And yes the servos and galvas are already mounted on the laser bench were already debugging the optics part ( I wonder where's that hiss in the servo is coming from?).  I do not know how fast enough is my new M-series 6251 is for PID? Anyway Tom thanks for this new VI also!

Regards,

Berns B.

[Poormanphysics]

Hello Tom:

I've tested on real time the VI youv'e sent. It seems that it's running (or my servo hardware) is on a "race condition" it actually influence the movemement of my other servo axis even if initially I am only using one and the other is set at zeroth position? I do not experience this condition if I use Express and if I have subVIs embedded inside a main program loop or even on Flat Sequence or Stacked Sequence? I have seen this happened only for DAQMx simultaneous and multiple channel analog IO? Or could it be the 6152 board? I do not have a profiler for me to see this but you guys have. Can you check for a race condition here?

Thanks again.

Berns B.