Write to spreadsheet problem

[Crashdx]

Changes1) I switched over to 100 Hz sampling frequency and applied the correct timer. When I saved the values using the 10 ms timer the same issue was coming up because there would be about 2 or 3 values that were the same. So if it was down to 1 ms that would be 20-30 consistent values.

After that I changed the case statement like you said by using the index for the false queue. I left the write to spreadsheet command to check it and it counted from 1-5000 without any repeated numbers saved to the spreadsheet. I also went ahead and changed my queue type to U32.

Changes 2) When I simplified and removed the write to spreadsheet function and ran the program it seemed to be running fine, but by just watching the data go by it looks the same as when the write to spreadsheet is in the code.

[Bob_Schor]

If I understand your tests correctly, I think you said that substituting the "dummy data" of the loop index for the data from the Counter caused "correct" data to be written to the Spreadsheet.  If that is so, then the problem is clearly reading the data from the Counter.

I confess that I didn't look closely at the details of your code in the earlier examples, but now that we seem to have narrowed it down (possibly) to reading the Counter, I took a look.  Why are you reading N samples?  If you read a single sample, it would give you the current count, and nothing else.  See if that fixes the problem.  To make the switch, click on the down-arrow under the Read Counter VI, choose Counter, Single Sample, U32.  You can get rid of the Index Array function since this VI will now return a single U32.

BS

[Bob_Schor]

Incidently, if this is a Class Assignment, be sure to give proper acknowledgment to the NI Discussion Forums.

[Crashdx]

That is quite a good question. I initially had my counter setup to take only one sample instead of N continuous samples, but I was having a different issue at that time. I was unable to go below 20 ms sample rate without having my timing variable start to skip numbers and start going out of control (ex. 20,40,60,77,102,122,142). So it was suggested to me to change my counter to N samples which resolved my problem for my previous timing issue.

I've switched it over to take 1 sample in the simplified version of the code, but I'm currently getting the same results. The time is flowing steady, but the data will still get hung up.

This isn't for a class, but it is a small part of a research project that I'm working on and is currently the only part that is holding me back from starting my testing process.

[Bob_Schor]

The problem is clearly the device.  Can you tell me what this is?  I presume it is an NI device of some kind -- if I know what kind, I may be able to figure out the behavior you are seeing.  Also, (although you've probably said this earlier), what are you trying to do?  I can see you have configured a "Count Edges" -- are you trying to estimate the frequency of a signal, determine the period of a signal, or something else?  What are the characteristics of the signal you are trying to measure (e.g. "I'm trying to measure the bit rate of a TTL data stream coming at 9600 baud" or "I'm trying to estimate the frequency of a 20 to 5000 Hz sinusoidal signal").

BS

[Yamaeda]

Looking at the result file i agree that it's a sensor/detection problem. The result is very similar to one i had trying to get rpm-speed.

It seems you've mostly got the main loop to spin at 1 ms, though windows often has problems with those timings. As you can see in the result file it's not a 1:1 ratio but you often get 2 or even more counts in 1 ms, so do the main loop need to spin at 1ms or could it be e.g. 5?

I'd prefer if the consumer gathered some values before writing to file, you'll get alot of file open and close with the current design. Add up incoming values to an array and check time, write to file 1/sec or something.

(Or build the array in the producer loop and send 1000 values at a time)

(Instead of building an array of 4 strings you can place a string-array constant) 😉

/Y

[Crashdx]

I am using a quadrature encoder and detecting the edges on the square waves so I can calculate and determine positioning. With my current configuration I'm only using the input from one channel from the quadrature encoder. The encoder itself can easily operate with sampling frequency above 100 kHz, but I'm looking for at least 1 kHz. The device has 1000 cycles per revolution.

[Crashdx]

I'm actually fine with transferring multiple samples into the spreadsheet at one time. I've never done anything in labview where I move a cluster of values into a spreadsheet. I've always fed individual values into the spreadsheet.

So I'm not sure if I understand on how to accomplish this. I'm assuming I would have to change the timing value from "1" to "5" or "1000" do have it hold for that long. After that would I need to build an array to the size of my timing interval to store my values? and if so how would I put a time stamp on each individual value so I could feed it into spreadsheet with the proper time stamps?

I attempted to take my time and counter array and use the insert into array function to try and hold these values. When I do this I don't get any errors, but the output to my spreadsheet is still a real time value, instead of an accumulation of number I wanted to store.

[Yamaeda]

If the main point is to get the timing of the edge you're attack angle is the wrong one, you should Trigger on edge and get that time, for starters. The High resolution timer (look in vi.lib on HD) would also improve your result.

Send the result as they arrive, lets change the consumer some. I've attached a modification where you gather up 1000 results before writing to file and a finishing write in case it's less. 

/Y

[Crashdx]

Thank you for the response and I apologize for my late response,

I have been diligently working on trying to solve this issue by running some test to narrow it down. I ran your program and I didn't make any alterations to it, but whenever it fed the data into the spreadsheet it came out in a weird pattern. I've attached the excel file which shows this data(FinalProto).

I ran a test where I hooked configured the analog input to feed data into my spreadsheet while I also collected data from the counter input for my optical encoder. This was because I wanted to see if the program itself was stalling or if it was either the optical encoder or the counter input channels. After completing the test I discovered that while the data from the optical encoder would stay the same on the counter channel that the voltage reading on the analog input channel would actually change. I'll attach that spreadsheet as well.

This is where I am currently stuck. I am unsure if it is actually my optical encoder that is causing these hiccups or if it is the counter input channel. Any feedback on this topic would be much appreciated.