Multifunction DAQ

cancel
Showing results for 
Search instead for 
Did you mean: 

Use M-Series cards with DAQmx in Matlab!

Hi Jens!

Thank you very much for your answers!

To be more specific, I want to design a model-based controller for a motor drived by a a a-m-c DC motor drive (zbdc12a8 at  http://www.a-m-c.com/download/datasheet/ZBDC6A6.pdf). My interface between the model-based controller (software on PC) and the drive is the PCI-6221 card.  Previously we used labview to control the PCI-6221 but we felt there was some delays between the NI card and the PC. We are searching options to avoid the quite heavy labview so to use matlab seems a good way. For now we aren't even sure if Real-Time is really needed to control our motor.

I'm currently reading about the Data acquisition toolbox. It seems to be a very interesting product simple to use (input and output blocks). I wonder if it can be used to design a Simulink or Matlab-based control system with feedback. If we dont buy the toolbox I plan to use your code.

Just to be curious: is there any gain to use xPC target with the (not made for real-time) 6221 card? Wouldn't the communication delays shorter if the computer doesn't have to run the OS (Windows Xp)?

Thank you again!
Marc
0 Kudos
Message 31 of 106
(5,496 Views)
Hi Marc!

Not being involved in your project, it's difficult to say what you need. 😉
Using Data Acquisition to control, you can interface your software with the controller maybe at 10Hz (this really depends on the data transferred), but using a realtime application, this can get to 1000Hz and even higher. Another difference is that using direct dll access will not easily work with an exact sample time, it is usually dependent on the CPU load for example.

So, if the DAQ Toolbox or "my" DLL access is fast and exact enough for you: great! Otherwise, read on...

But if not, there is the LabView RealTime Module and of course Mathworks's xPC, which requires a second PC that runs Mathworks's RealTime OS.
Mathworks supplies another RealTime solution: RealTime Windows Target (RTWT). Here, the RealTime application runs on the host PC, while Windows is running - you only need one PC. It is cheaper but also about one order of magnitude slower.
Neither of them works with the new NI M-series cards, only the old E-series cards.
The answer to your question " is there any gain to use xPC target with the (not made for real-time) 6221 card?" is: That's not the point, if Mathworks would support it, it would work. As it does not support it, it does not work in xPC, not even a bit.
And "Wouldn't the communication delays shorter if the computer doesn't have to run the OS (Windows Xp)?" That's the whole point of xPC: The RT PC does not run Windows, but a dedicated RealTime OS and it can be controlled through the control PC.

As you already have the M-series card and the M-cards are _really_ better than the E-series cards, I'd suggest researching the LabView RealTime Module: http://www.ni.com/realtime/ - I don't use LabView, but I'm sure the NI forums will provide a wealth of information!

Another PC-based RealTime solution would be the ADwin cards, but that's another story.

Good luck!
Jens



Message 32 of 106
(5,489 Views)
Hi Jens!

I found yesterday that I may have access to the DAQ toolbox, so I'll try it first to make some experiments. I'll let you know how the project is going!

Thank you again for your answers!

Marc
0 Kudos
Message 33 of 106
(5,460 Views)
Hi again,

I have two questions:

1. The DAQ toolbox 2.9 seems to work fine! I manage to easily get some data with the analog inputs. However, I want the card to output a PWM signal with my 6221 board. I know I can create a software pwm signal in simulink
( http://www.mathworks.com/access/helpdesk/help/toolbox/slcontrol/ug/index.html?/access/helpdesk/help/toolbox/slcontrol/ug/f15869.html ) but I'm wondering if it will be as effective as the Labview way: ( http://zone.ni.com/devzone/cda/epd/p/id/814 ). I dont know labview much, does the labview way make profit of the 6221 onboard clock?

2. The Simulink library Real-Time windows target seems to allow one to select the board PCI-6221 to install it... However I selected it and it doesn't find the card. Does anybody have tried this feature?

Thank you!

Marc

Message Edited by MALavoie on 11-14-2006 01:47 PM

0 Kudos
Message 34 of 106
(5,403 Views)
Jens, this has been very helpful.  I've was able to get a quick demo going in about 15 minutes.  I was wondering if anyone has tried to create simulink blocks using this method.  I really need to make use of existing simulink models and NiDaq communications, if I can create blocks to communicate with a NiDaq card that would be easiest.  I have looked at the DAQ toolkit, but I would need to get a newer version of Matlab which isn't an option at the moment. 

Thanks for any help and Thanks for the write up, very helpful.

- Neil
0 Kudos
Message 35 of 106
(5,374 Views)
Hi Marc!

I think you have reached a level where I really cannot help you much... 😞
Concerning
1) I am pretty sure that both ways use the internal clock(s) of the card(s), as it generally is the case for input and output actions. I cannot comment on which implementation works better, though.
2) I just checked again and the RTWT does not list any M-series cards. I could imagine that Simulink somehow "knows" of your 6221 as the DAQ toolbox is also installed on the same machine, but RTWT cannot talk to the card (as it itself doesn't support it).

Cheers
Jens



0 Kudos
Message 36 of 106
(5,334 Views)
Sorry for the two posts, I haven't figured how to reply to two posts at the same time...

Hi Neil!
Glad my samplecode was helpful to you. 🙂
Concerning your question:
My code (and yours, too, of course) are M-files, these can be used in Simulink mainly in two ways.
1. As an S-function - this works with old and new versions. You need to compile (help mex) your m-code and then you can insert that dll (Matlab version till 6.5) or mexw32 (7 and later) file. Matlab 7 introduced much better S-Function handling. However, even in older versionm, there are several slightly different ways to generate S-functions, so you might have to do a bit of research (as well as trial&error) to find the best option.
2. Matlab 7 also introduced the "embedded Matlab function" block. This allows you to use "any" M-code in Simulink. As Simulink accesses the standard workspace variables you might have to either define some variables as global or rewrite some of the code to fit all in one function. Additional info: Functions create their own workspace and only interface through their inputs and outputs with the governing workspace they were called from. Defining variables as global makes them accessible from "everywhere". (Sorry if that's old news to you.)

I'm not sure of any time advantage, but I think the compiled S-function would be faster. As you imply that you only have an old version (I assume 6.0 or 6.5), an S-function would be the (only) way to go. Then of course the question is how well the compilation of a dll-calling function into a dll actually works.

I'd appreciate it if you could keep me updated on your progress, as I think this is an interesting application!

Good luck
Jens

0 Kudos
Message 37 of 106
(5,330 Views)
As it turns out, using the S-function approach proved very straight forward.  I'm able to create models which will run under simulation mode.  I am further able to generate code and a stand-alone executable through RTW.  The problem that I've run into is that I'm only able to create a single task per operation.  I have been creating tasks in the mdlStart function which works for the most part.

The S-Functions were written in C not matlab.  It only seems to make sense because you don't have to calllib all the time, just use the SDK directly.  This also allows for straight forward code generation.

- Neil
Message 38 of 106
(5,294 Views)

Hi

I have a problem with my NI-USB6009, hope someone can help. I intend to make an S-function for Simulink 6.0 that reads and writes samples. I have done the part that reads samples, and it works fine (thanks to this thread too). There are some problems with the writing part tho.

 

Here is a bit of my code:

    [err,a,task2]=calllib('ni','DAQmxCreateTask','',2);
    disp(err)
    task2chans=['Dev1/ao0:' num2str(st_izhodov-1)];
    err=calllib('ni','DAQmxCreateAOVoltageChan',task2,task2chans,'',0,5,DAQmx_Val_Volts,'');
    disp(err)
    err = calllib('ni','DAQmxCfgSampClkTiming',task2,'',samplerate, DAQmx_Val_Rising,DAQmx_Val_ContSamps,1);
    disp(err)   

So here is the problem. The error code for CreateTask is 0 (so it is OK), the error code for CreateAOVoltageChan is also 0, but the error code for CfgSampClkTiming is -200077. I found somewhere that this code means i have requested an action or parameter that the device phisically cannot do. Is this true? And if it is, any idea of what could that be?

The interesting part is that i have practically the same code for  input chans and it works fine.

PS: apologize for my english 🙂

Peter

0 Kudos
Message 39 of 106
(5,268 Views)
@Neil
Wow, that sounds good. No idea why you cannot start two tasks, sounds pretty weird. Have you tried different combinations, like calling them them from the same m-file? Does one include a clearing function of any kind?

@Peter
You english is just fine with me 🙂
A potential problem I could see is that the 6009 is limited to 150Hz output rate.
http://techteach.no/tekdok/usb6009/index.htm
http://sine.ni.com/nips/cds/view/p/lang/en/nid/14605
I am not sure whether this is the combined refresh rate, or per channel.
What "sample"rate do you use?

Cheers
Jens

0 Kudos
Message 40 of 106
(5,262 Views)