Error -201314

[ry78]

Well I was excited to open your edit until my version (2010) of Labview decided it couldn't convert it.  Unbelievable, could you resend.

Thanks

Ryan 

[Patrick_NI]

Sorry about that, here they are saved for 2010.

[ry78]

Well, I tried both samples and they both give me the same error. (201314) haha that error is starting to annoy me.

On another note I do like what you did with the 1/10 sample read "Rule of thumb."

With the error handling why is it necessary to run them in parallel?  Is it for performance reasons?

Thanks

Ryan

[Patrick_NI]

It is for performance reasons.  When you wire them together as you were, it will cause your program to run each after one another and will slow your loop.

The error handling checks for a certain error and cancels out that specific error.  Right now the code is cancelling out error 201314, not -201314.  Try making the "exception code" input of the General Error Handler VI negative.

[ry78]

Great, by changing the error to a negative value it now ignores the error.  For future reference is this always the case?

The problem I have now is I don't have any readings for my frequency count.  The analog side works great but the digital side I'm receiving absolutely nothing?

Thanks

Ryan

[ry78]

On a side note, I tried giving the code what it wanted in terms of digital input.  I hooked up a function generator, output 0-5vdc square wave at varying frequencies.  What I found within my code was anything under 8,000 RPM +/- or 1,600 Hz's +/- the code would kick out the error.  I tried adjusting the sample rate but it had no effect.  I'm assuming the clock it's running is approx 1,600 Hz's and anything less then this, it will see two pulses between acquisitions.

Ryan

[Patrick_NI]

Hi Ryan, 

I've looked a little further into this.  You are setting this rate to 1000 Hz.  However, if you look in the manual of the 9237 in the section "Understanding NI 9237 Data Rates" you'll find that the minimum sampling rate is actually 1613 Hz when using an internal clock.  So, your sampling rate is being coerced to 1613 Hz.  You can confirm this by using the DAQmx Timing property node, SampClk.Rate.  

You mentioned earlier that your signal has a maximum frequency of 1600 Hz.  This means our current strategy will not work, as you will always have too high of a sampling rate.  One option would be to share the start trigger and just acquire simultaneously, but this will not be truly synchronized.

Another workaround might be to use another counter on the 9401 to decimate the 9237 sampling rate.  This will work for all frequencies above the decimated frequency.  I'll post this to community examples and then link it here once I do.

EDIT: https://forums.ni.com/t5/Example-Code/Synchronize-NI-9237-with-NI-9401-at-Low-Frequencies-in-DAQmx/t...

[ry78]

Hi, Patrick thanks for your help on this issue.  This program seems to work fine.

I do have one question: Why do I have to feed in a frequency greater (double to triple) than what I specified in the box "Frequency of decimated 9237 timebase" to get the program started?  Once I start the program on a higher frequency it works great and can turn the frequency all the way down to the specified frequency before it kicks out the error.

Just curious?

Thanks 

Ryan

[Patrick_NI]

Hi Ryan, 

Hm, that's odd.  Perhaps the CO Frequency is not what we assume it is.  To troubleshoot this, I would create the CO Pulse Frequency property in the while loop to check what your frequency is at all times.  If you try this, please let me know the results.

Additionally, it looks like the "actual decimated frequency" may not be giving the right value, since it is called before we change the timebase.  I have edited this on my example by changing the property node to this:

This new order will account for the change in timebase when it outputs the actual frequency.

[ry78]

Well Patrick, sorry about the delay.  I did update the code to reflect your changes in the DAQmx Channel.  Although I still have to feed the program a higher frequency then the specified "actual decimated frequency" to start.  I can then bring it down once it's running.  (I'm not sure if this change was suppose to help this or not?)

How do I go about setting up the CO Pulse Frequency property in the while loop?  I'm new to these property nodes.

I have attached a copy of the updated code.  I believe the changes are correct.

Thanks again!

Ryan