event based sampling and output

[LucyXF]

Hi John,

I understand what you are saying. For my system, I only have one AI. The Freqout is not related to the AI itself. The Freqout is used as an excitation to the sensor itself (you can think of it as a power source to the sensor) and should be provided constantly to the sensor. The AI and AO do need to be updated every 30 degrees as specified by the controller design, although it might seem strange. The AO need to be calculated online, not as a predetermined sequence. Would you say that I better use a CompactRIO system for implementing this controller?

Thanks!

-Lucy

[John_P1]

Hi Lucy,

I am still a bit confused by something you had mentioned earlier (assuming the updates must occur at precisely 30 degrees):

"The time lag between the AI sample and the AO output is not very critical in my application."

How much time lag is acceptable?  If it is truly not very critical, then I'm not positive it's necessary to switch to the cRIO.  Although it probably would be the optimal solution, there would be some overhead (learning and cost) to making the switch.

One possibility we haven't considered would be to simply use the A input of the encoder directly as the sample clock for your AI task.  You could read (say) 300 samples at a time which would give you a loop rate based off of your encoder signal.  You could use the Z signal to trigger the start of the AI task the first time.

I'm still not sure what behavior you need when the encoder changes directions.  For example, say we read back the following position measurement:

0.........25 degrees (direction change) .......... 20 degrees

What does this need to return?  The encoder has travelled 30 degrees in total, but it is only at the 20 degree position.  Using the A signal as a sample clock would not account for direction changes, so this would result in an update even though we have not hit 30 degrees.

-John

Message Edited by John P on 08-10-2009 06:55 PM

[LucyXF]

Hi John,

I wasn't being very clear about the acceptable lag between AI and AO before. Of course it would be the shorter the better. However, I don't know specifically how large the lag would have to be before hurting my controller performance. I'm guessing something around 0.5ms would be ok? I already have a cRIO system, but like you said, the learning time is also an issue. I would hope to get some experimental results soon. So switching might need to wait until absolutely necessary (e.g. the lag is unacceptably large.) 

If we use the counter ticks directly as the timing clock, this means that if we only need one sample per 100 ticks, then we would have to collect 100 times the number of samples needed just to get the one we really want, right? Would this increase the processing time?

About the rotational direction, you've asked a very good question. 🙂 The controller in my system is designed in a way that it only works (giving out nonzero output) when the angle is increasing (in one direction). If rotating in the other direction, the controller would not do anything. It is not very critical for now since we can limit our experiments to only rotating in one direction. However, it would be more desirable if we can have the system working without limiting the rotational direction, i.e., the controller knows when to stop the output and when to start, making the whole system autonomous. 

Thank you for all you help so far. You've given me some very good suggestions.

-Lucy

[LucyXF]

Hi John,

I copied your idea and modified the file a little to accomodate to my situation. However, I got this error after running the program.

Error -200284 occurred at DAQmx Read (Analog DBL 1Chan 1Samp).vi:1

Possible reason(s):

Measurements: Some or all of the samples requested have not yet been acquired.

To wait for the samples to become available use a longer read timeout or read later in your program. To make the samples available sooner, increase the sample rate. If your task uses a start trigger,  make sure that your start trigger is configured correctly. It is also possible that you configured the task for external timing, and no clock was supplied. If this is the case, supply an external clock.

Property: RelativeTo
Corresponding Value: Current Read Position

Property: Offset
Corresponding Value:


Task Name: _unnamedTask<3>

Please let me know what was wrong with my program. Thanks!

[John_P1]

Hi Lucy,

Error -200284 is a timeout on DAQmx Read.  In this case, the issue is probably that the AI task is not receiving its sample clock quickly enough (the default timeout is 10 seconds).  Or, perhaps the encoder has stopped generating pulses but the code is still running.

The code seems to run on my end if I input a 4 kHz clock to Encoder Input (A).  If this clock was turned off or disconnected I would receive error -200284.  You may need to programmatically handle the error if your encoder is not going to be turning continuously.  If this is the case, a useful function to look into might be the Clear Errors function in conjunction with a case structure.

If you already have the cRIO it wouldn't hurt to try to get some help on that end as well--it would offer the minimal delay between AI and AO since the processing would be done on the FPGA.  For questions about cRIO programming I would post in the Real-Time Measurement and Control forum.  The FPGA solution would be ideal for this type of control application.

-John

[LucyXF]

Hi John,

Thanks for the help. I will try the usb board first to see if it can get things done. If not, i'll have to move on to the cRIO system.

Thank you so much for your help!

-Lucy

[LucyXF]

Hi John,

I don't know if you'll be able to see this post since it's inside a solved thread. If not, I'll repost it as a new thread. 🙂

I've met some new difficulties with the angle based timing. I want to have a velocity measurement (from a counter input) with the angle-triggered timing. I have two separate encoders in the system. One is used as the timing trigger for other AI AO and CI tasks (like we have discussed before). The other encoder is the CI task which is used to measure the velocity. This means that the CI should be angle-triggered(by another encoder) and take two samples several milliseconds apart from each other. I don't know if I can use the 1chanelNsamples reading function to achieve this. Is this possible at all with the usb-6211 device?

Thank you!

-Lucy

[John_P1]

Hi Lucy,

One way you can measure the frequency of your encoder is to count the number of timebase ticks that occur between encoder pulses.  In software, this is configured as a Low Frequency 1 Counter Measurement.  Are you sure you need to trigger the measurement off of the other counter?

If possible, could you post a link to the motor controller you are using and include some diagrams showing when you need to sample the signals and output the data?  We lose our determinism anyway when performing the processing in Windows, so I am not sure if we need to make such a big deal about synchronizing everything at 30 degrees.  I'd be happy to take a shot at an example program to show how I would try this on a DAQ device.

Again, the crio would be able to perform the processing in hardware and would likely be a more ideal solution.

-John

[LucyXF]

Hi John,

Here is the vi that can demonstrate the operational diagram. In the vi, i used the counter 1 sample task to represent the velocity measurement task. In reality, it will take at least 2 counter samples to calculate the velocity. The control algorithm in the second case structure frame will look more complicated in the real program. Here I just used one addition to show how the system works. I have two problems right now. One is how to get the velocity measurement based on this structure. The other one is that I still get the 200284 error after applying the Clear Error vi as shown in the diagram. Could you please let me know what was wrong with my vi? Thanks so much!

-Lucy

[John_P1]

Hi Lucy,

The timeout error should actually be -200284 (with a negative sign).

As for the frequency measurement, I think what you want to do is count a known timebase instead of the edges of your encoder (see the attached VI).  This configuration would count the number of internal timebase ticks that occur during each 30 degree pulse and compute the frequency of the 30 degree pulses.  You could divide this by 12 to get the RPS of your motor.

-John