"Start Trigger" for encoder measurement AND AI

[Milqman]

I am building an application for the following:

I have an encoder (2000 Count Optical Encoder, Output-Quadrature)
I also have an Analog Input

Currently, I am using a rise in the 'A' Channel as the sample clock.

Therefore, I should be getting 2000 pulses per revolution, which I am.  However, I need them to be "aligned."  The data I am trying to generate requires that the indexes of these two arrays line up with each other.  That is to say the following: given 2 arrays, one of angles (encoder), and one of voltages (analog in) I need the first (and every other) index to coorespond to the other.  Say the voltage was 3.5 when the angle was 96 degrees, I need them to be in the same index of their respect arrays.

This whole application runs in a loop, so I am constanly capturing pairs of 2000 element arrays.

I am not totally familar with reference triggers, start triggers, and arm triggers  (but my guess is that I need to use one of them here).  I have the rest of the app worked out already, and it is functioning well.  I do know that the arrays are not lining up (the graph I output is proof of this).

I have an index channel that I can use as a trigger.  I would like to be able to trigger every loop/revolution in case the encoder misses pulses (I am spinning pretty fast)

Basically, what kind of trigger do I use?, how do I configure it?, where do I put it?  And do I use continuous aq or n-sample aq?

I apologize if I missed on some information, if you need any additional info, just ask.

~milq

[Milqman]

So, I did what I thought might fix my problem, guessing how I might implement some triggering.



Of course, I was a little surprised when I found Error -200452.  Apparently Start Triggers are not allowed to trigger Counter/Encoder Measurements.

If that is the case, I need something that will work, or maybe some ideas on how I could massage the data mid loop to get them to line up.

LabVIEW makes the easiest things hard and the hardest things easy.

Any assistance would be wonderful,
~milq

Message Edited by Milqman on 02-27-2007 04:49 PM

[Milqman]

Maybe Start Trigger the AI, and leave its sampling the same, then take 2000 points of data and calculate what the angle of each of those was based on it's index?

That seems like it would be ok, hokey in my opinion, but ok.

Is there a better way?

~milq

[Milqman]

So, I have it working according to that final method (still think there should be a better way).

Now I have my Read.vi outputting waveform datatype (in hope of getting timestamps).  Unfortunately, when I combine them, in front of the Write Measure File vi, the WFM+Array Clustering does not make the "convert to dynamic data" adapter happy.

Is there going to be a good way to record this data?  With timestamps if possible?

This forum is acting more like a journal than a help source, all I hear are crickets! (just kidding guys)

~milq

[tbd]

Hi milqman,

      Theoretically, it's possible to route the AI StartTrigger to a Counter task.  Forgive me, I haven't read all your posts - hope this is "on-topic."

Cheers!

[Kevin_Price]

Yeah, I think there is a better way.  Here are some comments, hints, suggestions, etc.

1. Counter measurement tasks cannot use the standard "Digital Start trigger."  A similar behavior can be programmed using an "Arm Start trigger" which applies only to counters.  You need to use a DAQmx Trigger property node to find this setting.

2.  If this is still your engine measurement app with unidirectional motion, you may not need the Position measurement task at all.  As long as you trigger off the Z-index, then the index into the array of AI and/or Freq samples tells you the corresponding position = (index/2000) * 360.  You referred to this as "hokey", and I kinda see your point, but I think you'll find that the actual data you collect isn't really giving you more information.  You're just gonna see angles incrementing by a constant fixed amount.  Personally, I would use the "hokey" method and save the counter channel for another purpose (perhaps a delayed trigger?).

3. You still need to sequence the various calls to DAQmx Start to help keep your tasks in sync.  More on this later.

4. Right now, 2 of your tasks are Started and Stopped in a loop.  This would only make sense for certain types of triggered finite acquisitions.  The trouble with finite acquisitions is that you are then committed to a certain "willful blindness" to what's going on between loop iterations.  In some apps, this is just fine but in others, not so much.

   The choice between finite and continuous really depends on the needs of your app.  Finite acquisition is simpler to program because you can make a single call to read the entire buffer of data and DAQmx is smart enough to handle the waiting for you.  Continuous acquisition gives you much more flexibility and allows you to accumulate long periods of gap-free data, but it requires smarter programming to repeatedly read smaller chunks of data from the buffer and feed it to your file and display.

5. Sequencing.  I'm not at a LV PC to verify this, but here's an idea I *think* will work.  I'm assuming that you've got an engine that's already running so the encoder A & B and index pulses are coming in continuously.

A. Configure the Freq measurement task to use the AISampleClock as its sample clock and the Z index pulse as an "Arm Start" trigger.  The encoder's A channel will be the Start this task.  Then feed the output error cluster to the input of the AI configuration vi's to enforce sequencing.

B. Configure the AI Pressure task to use the encoder's A channel as its sample clock and the Z index pulse as a Digital Start trigger.  Now Start this task.

Result: You'll get buffers of synchronized freq and pressure measurements.  The index into those buffers represents position, and a cumulative sum of 1/freq can give you a timestamp for each measurement as well.

Gotcha to watch for: the very first freq value can't be entirely trusted.  The first Z-index pulse after starting the freq task will "arm" the counter and it will start counting time.  It won't store a measurement of freq into the buffer until after the AI task has been started and triggered so it starts producing sample clocks.  So there's a chance that the engine will go through 1 or more revs between the time you start the freq task and the time you start the AI task.

-Kevin P.

[Milqman]

Thanks Kevin, as always you swoop in to the rescue.

I guess I am going to stick with the hokey method for now.  Not really sure why it is hokey, I just see it as lowly (maybe just because it is sneaky and resourceful).

Like I said, I have that working at the moment:



If you'll look over by the WriteMeasureFile.vi you can see where I have to cram a Wfm and an array together (the current way does not work, I know).  Is there an easy way for me to get the timestamps of each pressure measurement (all 2000 of them per cycle)?  That would be particularly useful.

As for the first freq measurement, that is fine, I only record when the user clicks, so it is of little concern.  It wouldn't even be bad if I missed entire cycles, as long as the cycles I do get are right.

In case you were wondering, the application is not quite the same as before (though they all do operate on the same engines).  This uses an encoder to translate a spinning "cam"s angle into a piston position.  These piston position coordinates are lined up with pressure coordinates to generate a Pressure vs Volume graph.  With the shape, size, and change of that graph you have access to an enormous wealth of information.

Does the current version look better (with the exception of trying to mash two non-like things into an array)?

Thanks again,
~milq

[Kevin_Price]

I've got only a minute or so now.  There's probably a half dozen or so things that'd be simpler for me to "touch up" for you than to fully explain with words alone.  Could you could post the actual code instead of a screenshot?  Version 7.1 or 8.2 preferred.  Hopefully you've got a version (probably LV Pro, maybe Full) that will let you do "graphical differencing" on the changes...

-Kevin P.

[Milqman]

<attached>

There will be subVI missing, but the contents of that are super mega secret (a complete lie, it is just silly math).

Thanks again,
~milq

I just want to pipe the CoarseSpeed data into the write measure file.vi.  It is a scalar, and I am throwing it in there with arrays, I am not sure how it will like that.  Hopefully it will like that just fine.

Message Edited by Milqman on 03-01-2007 02:00 PM

[Milqman]

Any update?

The application is still having a few problems, due to hardware, not software.

Getting that RPM value into the write measure file block so it fits in with each cycle would be nice.  The only way I saw to do it would be to fill an array with that value and just pipe it in, but I would rather have a smaller sized solution (that would increase my file size by like 50%).

What were your suggestions/edits/tweaks?

Thanks,
~milq