event based sampling and output

[LucyXF]

Hi John,

I think there might be a little bit of complication for my case, since the frequency of the signal that I'm trying to get is not the one coming from the internal timebase, which is driven by the angle. It is another signal from yet another encoder (not the one measuring the angle). The two encoders are not related to each other. Can I connect the input terminal for the DAQmx property node to some other digital signal source instead of the timing base?

Another concern is that if I count the frequency of the signal between the 30 degree duration, the frequency I get would be an average velocity over that period, right? Is there any way that I can get the immediate velocity measurement at around that time instance? If not, I'll try to see if the averaged velocity will work for my application.

Thank you!

-Lucy

[John_P1]

Hi Lucy,

You had mentioned this already, sorry for the oversight on my part.  You can perform a frequency measurement on any external signal, and the 621x that you are using should allow to use a sample clock with a frequency measurement (at the pulse of the sample clock you will read in the most recent frequency value).  I think this attached code should be more along the lines of what you are looking for:

-John

[LucyXF]

Thanks, John. I will try out the vi with my hardware later. Thanks so much for your help!

-Lucy

[LucyXF]

Hi John,

I got this error when I ran the vi that you posted. What is wrong?

Error -201025 occurred at DAQmx Start Task.vi:5

Possible reason(s):

Measurements: Non-buffered hardware-timed operations are not supported for this device and Channel Type.

Set the Buffer Size to greater than 0, do not configure Sample Clock timing, or set Sample Timing Type to On Demand.

Task Name: _unnamedTask<23>

Thanks,

Lucy

[John_P1]

Hi Lucy,

Could you confirm that you are using a USB-6211?  Also, which version of DAQmx are you using? 

The error you are getting is the same error that I would get on my PCI-6251 when configuring a sample clock for a period measurement.  I tried running with a simulated USB-6211 and didn't have any issues using DAQmx 9.0.  I am fairly sure that the 621x should be able to do this type of measurement but need to track down the hardware to double-check (the behavior is not clearly documented).

-John

[LucyXF]

Hi John,

I'm using DAQmx 8.6 which comes with Labview 8.5. Does it mean that I need to upgrade my software? This is so frustrating since I have had similar experiences with cRIO recently. As I was trying to employ the new cRIO-9022 for the application that we discussed here, I noticed that my computer didn't "recognize" the new hardware. After trying several trouble shooting techniques, I realized that it was because I do not have the most up-to-date software. It requires Labview 8.6.1, which we have not received yet...

Currently, we have Labview8.5.1 with DAQmx8.7.1 in our lab. Will it work for this vi?

Thanks!

-Lucy 

[John_P1]

Hi Lucy,

I tracked down a USB-6211 myself so I could run the code with actual hardware.  I was actually a bit mistaken--it looks like the error is coming from the Analog Output task.  For some reason the simulated device did not return this error--it's purely a coincidence that the error you were receiving was the exact same message as the one I was worried about if running on a non 621x.  The driver version shouldn't affect this particular error.

Taking out the DAQmx Timing function in the AO task should prevent the error from occurring.  In retrospect we probably shouldn't be using a sample clock for the AO task--since the value is determined in software we want to generate as soon as the data is available rather than based off of some other clock signal.  You also should probably handle the timeout case so that the AO Write is not called when AI times out.

-John

[LucyXF]

Hi John,

Thank you so much for the effort and help. I tried to delete the timing of AO and made some modifications for the time out case. I'm not very sure if my way of dealing with the time out is correct. Could you please take a look at the vi and let me know if something is not right?

I tried to run this vi with my experimental system. However, there were several unexpected behaviors.

1. According to this vi, when will the CO pulse ticks task generate its first high pulse? At the instance the CI task starts or when the CI counts certain ticks (i.e. after N degrees)? The motor starts spinning when the CI angle changes slightly (almost the instance when it starts rotating).

2. The motor kept spinning for several seconds after I hit the Stop button. Does it mean that the system is spending lots of time on calculation? Which probably means that the vi wouldn't work as "real-time" as we want it to be? If this is the case, I will have to switch to the cRIO system...

Thanks!

-Lucy

[LucyXF]

Sorry, here is the vi.

[John_P1]

Hi Lucy,

This is pretty much what I had in mind too--as you have it configured if the AI task times out we will simply not call DAQmx Write so the voltage output will not be updated.

The CO should start almost immediately if you have the Offset from 0 (Degrees) parameter set to 0.  This parameter is what determines the initial delay of the counter output.  The counter output should pulse every N degrees (0, 30, 60, 90 ... etc.).  If you don't want to output at 0, you can set the Offset from 0 (Degrees) parameter to 30 (for example).  This should give (30, 60, 90 ... etc.).

The reason the motor is still spinning after you hit the stop button is that you will not exit the loop until after the DAQmx Read either returns a value or times out (default timeout is 10 seconds).  The latency between hitting the stop button and the motor stopping is not indicative of the level of determinism of the motor control itself.  If you'd like you can decrease the timeout to a lower value (e.g. .1 seconds) since we are already handling the timeout case.  This will speed up the loop rate and will allow you to stop the code more rapidly.  I am a bit curious why it is taking so long since in theory if the motor is still spinning we should continue to acquire new samples.

-John