LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Problem using AI Read..

I am relatively new to Labview, and I'm using a .vi which was set up by one of my predecessors a few years ago. As such I'm finding it quite hard "reverse-engineer" exactly how this system works in order to solve this latest problem.
I am using a PCI-MIO-16E4 DAQ to measure voltages from four in-cylinder pressure transducers in an engine. I'm running Labview 6.1 on Win2K .
The .vi uses the AI Read.vi to read data from the buffer and output a waveform. Until the problems started, the output of the AI Read was simply an array containing four columns, one for each cylinder at which pressure was measured. Now, inexplicably, the output waveform has changed to an array of 16 columns, with each of the four original pressure traces being duplicated four times. As far as I know, the system has been left untouched for a month or so whilst the engine rig was down, so I can see no reason why this change has occured. I do share the system with other users though, and perhaps someone has unwittingly changed some settings.

Am I right in assuming this is nothing to do with the AI read vi itself?? Presumably this vi just provides a snapshot of the data in the buffer, that has been written from the DAQ board? I have to admit to having limited experience in Data Aquisition in general, so please don't be afraid of patronising answers!
The data aquisition is triggered, every revolution, by a shaft encoder on the engine crankshaft, and the AI Read vi is inside a while loop.

What would be a likely cause for this duplication of data columns within the buffer?

I have attached the .vi for reference - I should point out again that I did not create this one, and although the steps carried out after the "AI Read"  are fairly straightforward, I am still not completely familiar with the way the triggering and clock config parts work.

Cheers in advance
Theo

0 Kudos
Message 1 of 16
(4,152 Views)
Better bump this one back up a little....


Smiley Happy

0 Kudos
Message 2 of 16
(4,126 Views)
You need to probe the wires and see where these 'extra' channels are being generated.

I can't see anywhere in the code that would cause the duplication of this data. I would start probing the data coming from the Read function and then work my way along the nodes up to the point which the data is written.

Which write to file are you talking about anyway? I notice some output tunnels have auto indexing enabled whilst others don't. Do you know the reason for this?

Let me know a bit more and I'll happily work through this one with you.

Cheers

Stuart
0 Kudos
Message 3 of 16
(4,122 Views)
is it just scanning so fast that its returning that much data ?? it appears as though its scanning at 500Khz with a buffer size of 1440 ??
0 Kudos
Message 4 of 16
(4,111 Views)
Hi guys, thanks for repsonding

Ok, I'll try and answer your questions as well as possible. First of all, the output tunnels - I added all of the "write to file" parts myself (remember this vi was written by a previous colleague), so I could see what the vi was actually outputting, in a format that was more familiar to me (excel!)
I had all of the tunnels set to indexing, so that every output of the loops would be written - but I disabled indexing on the output tunnel that goes to the file called "Raw  Voltages" just so it wasn't such a huge file - this way it only showed me the array from the last loop, which was enough to see that this array seems to be four times bigger than it should be.

I put the "Raw voltages" write-to-file in to see what the "AI read" vi was actually reading from the buffer. This is the point where the strange things are happening - there are supposed to be four channels in total, one for each cylinder of the engine. So the output of the AI read vi is *supposed* to be a matrix of four columns, 1440 elements long (1440 is the amount of half degree increments in two revolutions (or one cycle) of the engine)
BUT, using the above write to file, I see that now, for some reason, the output of the AI read is a matrix 16 columns long. The data are now being duplicated  four times each, so the first four columns are identical and relate to cylinder one, the next four are identical, and relate to cylinder two, etc, etc.

In the first place, I don't really understand where this output from the AI read vi is coming from - is the buffer stored in the computer memory, or on the DAQ board, or where??

So, I've effectively probed the date back as far as I can, by ouputting what comes straight from the AI read

I will be continuing to get my teeth into this, and will be looking forward to your replies, but I should point out that I will be on holiday for the next fortnight, so please bear with me if I don't reply to any responses until after that!

Thanks in adavance!
Theo


0 Kudos
Message 5 of 16
(4,095 Views)

Theo

i dont remember what your code looks like , but , i am assuming that you are using the write to spreadsheet.vi , try transposing the array before you write it to the file ... then look and see if it looks like what you want.....

0 Kudos
Message 6 of 16
(4,089 Views)
Hello again folks,

Sorry for the quiet period, as I mentioned in the last post, I've been away on holiday for the past two weeks.  But I'm now back to trying to figure this out. Hopefully, those that have made suggestions so far won't mind picking this thread back up once more!

I've tried to answer all previous questions in that last post - as for the suggestion of transposing the output of the "write to spreadsheet", I am fairly confident that this wouldn't make any difference to the problem, because; Correct me if I'm wrong, but what I see in the spreadsheet output is simply what the AI Read function is reading from the "Buffer" (As mentioned in my last reply, I'm still not sure where this buffer is stored - is this in the computer memory, the DAQ board, or where??)

The "write to spreadsheet" serves no purpose other than for me to check what is being sent out of the AI Read vi... that's all I put it in for - no other calculations/operations rely on it. So surely it's something wrong with the way the buffer data is being written?? I just don't have a good enough understanding of how the buffer is written, so perhaps someone who is familiar with my board model can offer an explanation?

Over to you, and thanks again!

Theo


0 Kudos
Message 7 of 16
(4,039 Views)
.....bump
Smiley Happy
0 Kudos
Message 8 of 16
(4,020 Views)
Hi JTed,
 
I am also working on similar project., and also new to labview
I may require your help on the application
I hope you dont mind to .
 
Best Regards
Vikram Ghatge
 
 
 
0 Kudos
Message 9 of 16
(3,773 Views)
Hi Vikram
Wow, this thread has been idle for some time now, was surprised to see a response to it in my email today!

Well, if I can help you at all, I'll try my best, although I am relatively inexperienced in comparison to the majority of people on this board!

Drop me an email if you like, I'll get back to you as time permits.


Cheers
Theo

0 Kudos
Message 10 of 16
(3,755 Views)