Re : Re: Re : Re: cdaq and encoder -- loosing counts on measurements

[zoopy]

Hello Mark,

Thanks a lo four your reply. I'd some problem, in first with your vi, because I put in source "cdaq1/mod3/ai/sampleclock" and I got a error about material compatibility and the right way is "cdaq1/ai/sampleclock" mod3 is slot where is my ai card, but is to much in the cadencement source.

So, the application, now, run corectly.I used max to realise the task, so when this application will be complete, I will send my complete configuration, I think it's a good example about problems we can met on cdaq rack.

At this time, my customer give me a other challenge. I need to add a I/O input detection on my curve encoder acquisition, so I try to synchronise a front detection vi on ctr1 on my 9401 card who's don't use at this time, but I got a error (sorry I don't remeber the number)(I try count digital event.vi to do it).

I return on my customer place next year, in few time now!

I want to wish you a very good christmas and my best wishes for the new year.

Alain 

[Neal M]

Hello Alain,

Without the error code and text, it will be hard to troubleshoot what is going on.  If you are not using ctr1 somewhere else, then the example you are using should work.  Since the counters you are using are shared between slots 5 and 6, if you are using ctr1 on the other slot, you will get a resources reserved error.  If you are just running the Count Digital Events.vi, then there are some other things to check. If you combined the two examples, it may help if you post your code so I can look at it.

Again, the error number and text will tell us much more about what is going on. Once we have that, I should be able to give you more ideas about what is going on.

[JohnnyF]

I hate to bring this thread back from the dead but I've got a similar issue to the one posted and addressed in this thread. I'm using this encoder (with a 9401 module on slot 6 of a 9172 cDAQ chassis) to measure angular position of a shaft, from which I'll be calculating the angular velocity and acceleration later. I can get position data using the executable I've attached as a stand-alone. However, I need to perform this acquisition with some other analog inputs in tandem and would like to display and calculate all data on the same waveforms. This is where the issue comes in-I haven't been able to create a "dummy" task that I can run in parallel with the other tasks running as part of this executable, and even with this setup I occasionally run into the data overwrite issues originally posted in this thread. In this case, I had a 9234 module in slot 1 with two unused slots so I was trying to use that for the mock task but was unsuccessful (I also have a 9485, 9265, and 9201 module available in case I needed to use them for timing). I need a relatively high sampling frequency (theoretically at least approx. 54kHz) to avoid any potential aliasing in my acquired signal, but the maximum I've been able to get in this manner is 50k. I guess the other question I have is why I can't seem to use any of the onboard counters for timebase purposes whn I use the standard buffered counter example.

The secondary issue (once I get this sorted) is getting everything synchronized in the data displays and data files of my larger executable. I'm hoping to avoid having to sample everything at such a high rate as my file sizes are becoming large even sampling at 100 Hz. I've attached images of the buffered counter executable I've used to get position data and the larger executable into which I must insert the counter routine.

Thanks in advance to anyone that can provide any insight and my apologies to the mods if it is felt that bringing this thread back is in bad form.

[Jordan F]

Can you not create an AI dummy task because you see a resource is reserved error?  What behavior are you seeing when you run the two programs simultaneously?  I am a little confused as to what modules are acquiring at the same time and what all the different measurements you are doing in parallel are. 

 

The max sample rate you should be able to receive with your 9234 module is 51.2kHz.  However, if you have other modules in your system that cannot reach this rate you will be limited to that lower frequency.  The buffered counter example returns the number of edges seen every time a rising or falling edge is seen on a gate signal.  Do you need to return the number of counts at the rate of 54kHz? 

Since you only have one timing source for analog inputs, do you want to throw out samples to minimize the file size?  What are all the different signals being acquired and what exact modules and setup do you have other than the 9401 and 9234 module? 

Message Edited by Jordan F on 04-16-2009 09:02 AM

[JohnnyF]

Thanks for the reply. I I've made a bit of progress on this as I searched around more. The first thing I found was that my computer only had USB 1.0 so I switched to another with USB 2.0 and was able to use cDAQ1/100kHz timebase without the error I had been experiencing with data being overwritten nor the need for a dummy task. So, at first it would seem all was well but then one of the other engineers decided he actually wanted velocity instead of position.

That got me started on differentiating the position signal, though the problem I then had was the implementation of the OrthogonalSmooth.vi I was using to differentiate as there seemed to be an issue with the dt values I was pulling in (I was using 1/sample rate) and reading in an array of position values. I headed back to these forums and it seems the consensus is that frequency is better as a means of obtaining velocity as it eliminates the possibility of induced error resulting from differentiating a signal with any noise in it. So, to make a long story longer, I started looking at the shipping examples for frequency measurement. The issue I'm having there is that I can only get the low frequency example to work for me, when the longer range application seems best suited to my needs as I am measuring a velocity that will ramp up (accelerating a flywheel) and then be brought to a stop, so there will be variation in the frequency. Any of the two counter examples times out, giving me error-200284 regardless of how I manipulate samples to read and any other parameter. I've attached the version of the non-buffered frequency measurement I've been able to perform just as a reference-it is essentially the shipping example with a control to supply power to the encoder, as I'm hoping to use the 9285 to perform that within the task.

It seems from what you're saying I might be in trouble in terms of being able to perform the frequency measurement I need. The maximum frequency I expect to read from the encoder is approximately  27kHZ so I would like to sample that signal at a minimum of 54 kHz to make sure I'm not missing anything in that signal. The other modules I have in the chassis are the 9234 for two dynamic load cell measurements, a 9485 that is switching relays controlling the clutch, brake, and motor state for this machine, and a 9265 that is outputting a single current value to provide a reference speed for a motor controller. I also am acquiring data separately from a USB-9162 with a 9211 module with 4 thermocouples, so its max. sampling rate is 2.4 Hz. Currently, the load cell data is sampling at 100 Hz. I've attached my executable showing the tasks I've configured for each of these (LabView version 8.5). I haven't included the encoder routine there yet as I wanted to figure out how to properly read that data before integrating it. I would like to minimize file size if at all possible, but my lack of LabView experience has me a bit baffled on how I might go about throwing out some of the data from the signals sampled at higher rates, though I imagine that should be a simple task once I start looking at examples and searching these forums (I've been more focused on getting the measurements in the first place).

I hope that explanation of the modules I've got and the tasks I'm performing is a bit more clear-let me know if not. Thanks very much for taking the time to help.

[JohnnyF]

Since I guess I can't edit after 5 minutes, I'll update my situation. It seems that using the low frequency counter routine I'm actually getting a frequency that is equal to revolutions per second and not counts per second. This is a bit confusing to me since the vi requires you to specify the edge type to count and not a gate. I've verified that my connections are proper in that I am able to measure position accurately as I mentioned previously (in a seperate vi based on one of the other shipping examples). Also, when I run this example there is generally a lag of several seconds before it starts displaying data and it times out once I push the stop button, though I can't necessarily figure out where that error is arising.

[Jordan F]

The way the low frequency counter works is that there is that one period of your external signal is compared to a known internal timebase.  So, between rising edges on the external signal, the number of rising edges are seen from the known timebase signal.  This is explained in more detail in the cDAQ User Guide and Specifications on page 49.  I am not sure what the encoder you are using outputs.  If you the encoder outputs a pulse every revolution than the frequency would be revolutions per second.  The actual measurement returns a frequency dependent on the signal between two rising edges. 

cDAQ User Guide and Specifications

http://www.ni.com/pdf/manuals/371747f.pdf   

Also, in the same manual it discusses how to use the large range 2-counter frequency measurement.  I would recommend to check out the signal connections and how to properly set this up.  The drawback to this method is that

you will use both the available counters on the cDAQ chassis.

I tried running your program and I do not see the same behavior that you were experiencing.  I was able to run the program, toggle the digital I/O and measure the frequency without any lag or errors.  Can you run this program stand alone?  Try using hightlight execution to see if you can locate where the error is occuring. 

Message Edited by Jordan F on 04-20-2009 09:39 AM

[JohnnyF]

Hi Jordan,

Thanks for the reply. I actually solved the frequency measurement issue-it was apparently reading the gate channel so once I created a channel property node and specified the correct terminal it was fine. Now I am to the point where I can run the various frequency shipping examples as stand-alones, but when I try to integrate the frequency measurement into my main program either it waits indefinitely or I receive no data from the encoder. The bizarre thing is that there are no error messages and nothign shows up when I highlight execution outside of the errors you get once the memory buffers overflow.

I've attached my latest attempt at this executable; if you're able to spot the glaring error in my programming that would be fantastic but I'm still experimenting (hence the start task inside the loop on the first iteration-this eliminated the hanging issue but doesn't seem like sound programming).

Thanks again for taking the time to help.

[JohnnyF]

So I found my issue yesterday, and it's a rather embarassing one. I was sending the digital high to the wrong channel so my encoder was not being powered on within the program.

My main issues now are that although I can capture encoder data and display it, there are a few issues with correlating data timing with the other data being acquired. As an example, I've tried to take the array of counter data and display it as a waveform but there are discontinuities, particularly as speed is increased. I haven't been able to eliminate this issue by altering the sampling rate of my AI task or sample count as if I increase the samples to read on the counter my loop hangs and otherwise my AI buffer overflows. Here's a shot showing my array data plotted (small chart) and the waveform data below:

The more serious issue is that when I go to save the data my AI data shows up with correct timing and duration, but it seems like the saved data from the counter eliminates the timing where there are gaps and so I end up with a duration that is 1/3 to 1/4 that of what it should be and what is displayed with the other data. This is a rather serious issue for this application as accuraacy here is paramount due to the nature of this testing.

Here's the current state of the block diagram. I suspect these issues are more related to my lack of understanding of certain LabView fundamentals but haven't been able to find a solution searching here or the KB articles.

[Jordan F]

Lets try to break down the code again to see if the problem can be recreated on a smaller scale.  I am having trouble running your program (dont have all the channels set up) but if you want to split the code to only include the counter task and the analog input task we I may be able to locate the problem better.  That way we can eliminate the other aspects of your program. 

Also, I am a little confused on how you are comparing the frequency measurement to the analog input task.  What are the resultant data that you are expecting from the frequency measurement compared to the voltage?