Synchronization multi-function(D/O, PWM)& multi-device(USB6501, NI9237)

[hygeia44]

Hi there,

I am new to labview and I have a problem of synchronization.   I checked  some example like 'Muti-Device Synch-AI Start Trig-Change Detection'  VI and some online help http://zone.ni.com/devzone/cda/tut/p/id/3615#toc3.  It seems my case is both 'multi-device' and 'multi-function'. 

There are three parts in my VI: Part 1( top; USB 6501) is the Pulse Width Modulation(PWM) output connected to 'CLK'(requires pulse input) on my motor drive board; Part 2 ( middle;  USB-6501) connects to the 'ENA' and DIR' (requires static logical signal ) on my motor drive board, part 3 is load cell data acquisition using NI cDAQ-9172 and NI 9237. All of these three work well as separate VIs.  The ideal synchronization is like once I click the 'run' button, the ENA(part 2)  is turned on and the pulse(part 1) and load cell data acquisition should start together.  Then after a pre-set pulse cycle, I can pause the VI or it can auto-stop, until I hit the 'pause' button to activate all again. 

I list some of questions here and attached my VI (8.5):

1) I did the synchronization for the 'ENA'(static D/O) and 'CLK'(PWM). When I clicked 'run' button, the pulse(CLK) begins, but I have to manually click the 'ENA' button on the front panel to turn on 'logical on'. (Note: the ENA must be keep on to let the 'CLK' work for my motor). How to let the 'run' button also turn on the 'ENA' ?

2) From the examples for multi-device  , It seems I should connect all in series rather than in parallel.  Please give some suggestion to synchronize part 1,2 and part 3.

3)In part 3, should I keep the 'offset' on through  all the test ?  I believe stop the VI will reset the 0 for load cell each time( I do not want to reset offset during pause). But I am not sure how 'pause' affect the offset. 

4) the part 3 has some 'time out' before it can read the data, how to synchronize the data acquisition and motor motion ?

I hope it's clear. Any help would be appreciated!

Melody

[John_P1]

Hi Melody,

One thing to keep in mind in this application is that the 6501s are actually software-timed.  The synchronization examples you are referencing require hardware-timed boards.  I am actually a little curious how well the pulse width modulation aspect of the code is functioning, but if exact precision is not important you may be able to get by with software timing.  I'll go off of the assumption that everything is working to your satisfaction independently and the problem is integrating the code:

1)  It looks like the "ENA" button is set to false by default.  When you start the code, if the ENA button is set to false then ENA will be false.  You can set the button to be true before running your code if you wish.  You can also set the default value of the ENA button by right-clicking on it and selecting "Data Operations >> Make Current Value Default".  Of course, you should set the button to true before doing this for it to have any effect.

2)  We may have a disconnect as to what you mean when you say "synchronize".  When we use the term synchronize, we are referring to sharing a sample clock (or timebase) and a trigger between multiple devices or multiple tasks.  This is not possible with the 6501s since they do not use a sample clock and are timed by software only.  From what I can tell, you would like the devices to start at (approximately) the same time.  What I would recommend would be to start your three tasks in software inside the same frame of a sequence structure so we can ensure that all configuration occurs before starting any of the tasks.  I am not sure what you mean by "in series" for this application--wouldn't that by definition prevent your code from executing simultaneously?

3)  The "Offset Null" button will enable the bridge offset nulling calibration of your 9237.  This is configured shortly after you begin the code for the first time, so the status of the button when you first run your code should perform the calibration.  The bridge offset nulling calibration is just performed once, so if you were to pause the code and resume it would not happen again until you re-run your code (with the button enabled of course).

4)  Part 3 has a 10 second timeout.  That is, if you do not acquire enough samples after 10 seconds, the DAQmx Read will return a timeout error.  So, the timeout is not the amount of time it takes before the data is read, but rather the maximum amount of time that can elapse.  For example, right now you are acquiring at 500 Hz, 50 samples per read.  So, the 9237 will take 0.1 seconds to read 50 seconds, which is well under the timeout value.  If you specified a sample rate of 5 Hz however, this would take 10 seconds to complete and you would be in danger of reaching the timeout value.

It sounds like you are pressing the Pause button in LabVIEW to pause your code.  If you plan on making a Pause button a feature, I would suggest you actually implement it in the software.  The pause and abort buttons are meant to be used as debugging tools, and can possibly leave your hardware in a bad state.  Also, what do you have in mind specifically when you refer to "synchronization"?  With this hardware it is not possible using our definition of the word.  Any insight to your application (big picture) would be helpful as well, with more information I can most likely recommend a better example for you to begin with.  Do you have any hardware to use other than the 6501s that you can use for hardware timed digital I/O?  I hope this post has been helpful, I look forward to hearing back from you with more details.  Thanks for posting and have a great evening!

-John 

[hygeia44]

Hi John,

Thanks for your reply! It's quit clear and helpful!

Actually we have a third party motor drive which need digital O/I.  I am not an EE major that's why we sent info to NI and they gave 2 quotes one is USB 6501 and another is USB-6525. We bought both but it turns out both of them can not generate pulse train using counter. So PWM is kind of a 'plan B' now because I will give an presentation in two weeks. The PWM pulse is not smooth and the highest frequency 5KHz is lower than I need. Please recommend a D I/O that is suitable for my application. Attached is the info of my drive board 'MTSD-V1 Motor driver'. Page 3-4. 

My application is the loading and unloading test. Stepping motor( drived by 3rd party board which requires D I/O from USB-6501)is used to generate motion while NI-9237 recording the  load cell data.  Set up the steps numbers , frequency for the stepping motor, then start motor motion and load cell data acquisition together. When the motor finishes the preset number,  motor motion and load cell data acquisition stops together.  After 5 to 10 minutes, restart the motor drive and load cell data acquisition without the offset nulling calibration again. say let the load cell stay in 'pause' not 'stop' status during  the hold period. Then after serial run , I will change the direction of motor and do the unloading.

Here are some of the problems I have:

1)Synchronization.  You are right , I  'd like two devices( 4 functions : USB 6501 controls CLK, ENA and DIR) to start at (approximately) the same time. I put all the four parts(CLK,  load cell, ENA, and DIR) in one flat sequence structure. Is that what you mean?

2)Should I put all four 'DAQmx Start Task' from four parts inside one 'flat sequence' frame to let them start together?  

3) I input a number to the for loop in the CLK(PWM) part which control how many steps the motor will run. The 'PWM' will stop when finish the preset number, my question is how to automatically stop the load cell part when the motor stops?

4) the 'load cell' part will reset the offset null(begin from zero) each time I rerun the VI.  I do not want to reset the reference(offset null) when I repeat the PWM. How to  implement 'pause' in the software rather than click the PAUSE button in the LabView?  I do need a restart button in the front panel to reactivate the PWM, letting motor run the  preset number again without zeroing loadcell  again. I guess during the whole process the RUN button in the labview is also on then I can avoid the load cell offset null.

5) I want to also write step number( from PWM)  into the same file of load cell data acquisition. How to implement that ?

Attached is my VI and drive board info 'MTSD-V1 Motor driver' Page 3-4.  . Please have a look. Thanks!

Melody

Message Edited by hygeia44 on 02-15-2009 10:53 PM

[John_P1]

Hi Melody,

1)     Sorry that I wasn't so clear in my last post about the sequence structures--I actually meant to put the DAQmx start functions inside a sequence structure.  The reasoning behind this is that the configuration can take several milliseconds (longer if running the Shunt/Null Offset calibrations).  The sequence structure guarantees that all of your configuration steps have occurred before starting the tasks.  I have attached an example code to help make this and the following points a bit more clear.

2-3)     There are a number of ways to stop the strain task at the same time as your pulse generation completes.  The way I implemented this was to use a local variable "Acquisition Running".  The value is set to true when your tasks start, and is set to false after the pulse generation completes stopping the strain task as well.

4)     The easiest way to do what you need is to simply re-run the VI for each acquisition you want to make.  To avoid performing unnecessary shunt and offset calibrations, just make sure that the buttons on your front panel are turned off before running your code.  I made the buttons automatically reset to false after they are called, so you won't forget to switch them if you decide to run the code multiple times.  To enable the calibration functions, simply turn the buttons on before running your code.

5)     Again, there are a number of ways to do this but in the attached example I used local variables to pass the data between the loops.

The example code should give you a good starting point--it is the essentially the same code that you provided earlier but rewritten and slightly modified as described above.  I tried to preserve as much of the original code as possible.

If you find that the jitter in your software-timed pulses is too much for your application, I would recommend going with a board that supports hardware-timed digital output.  Since you already have a C Series chassis (9172), your best bet if you have to buy new hardware would be to purchase a correlated digital I/O module such as the 9401.  The programming will be slightly different with hardware-timed digital I/O.

I hope this post has been helpful, please let me know if you have any questions about any of this.  Thanks for posting and have a great evening!

-John

Message Edited by John P on 02-16-2009 10:02 PM

[hygeia44]

Hi John,

Say thanks first!  Really appreciate your help!

I will work on that:)

Melody