LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Intensity graph problem

Hi, 

 

I'm working on a VI that read the incoming data from a serial connection between the Arduino and the PC. 

 

I have a sensor grid (12 rows X 12 columns). 

 

the rows connected to 2 multiplexers, and the columns connected to 2 shift registers. 

 

after i shift the columns and multiplex the rows, i read the output of that through A0 pin in Arduino.

 

in my VI i configured the Visa port and the baud rate, after that i start reading from Visa read then pass the data into spreadsheet string into array. 

 

the output from Spreadsheet is the input of the new element of replace array subset. i initialized a 0s array of 12X12  and defined it as a dimension of the replace array subset. 

 

The output of this function is going to be displayed over an intensity graph with 2D interpolation.

 

my point is 

 

i know for sure that my array's dimension is so right, as i can see the object i place over it on the right position over the serial monitor of Arudino. 

even i tested myself by applying some force over each row and each columns individual and see the representation in the right position. 

 

but when i try to display my object over the Intensity graph, i noticed that all the time my intensity graph shift the data up, never stays in the same position. 

 

I tried to fix this problem by using state maching (get, wait and reset) to get the data, wait for ms and reset the intensity, etc.. didn't work. my intensity still shifting my data up. my data is numeric ones representing the force of object over the sensors. 

 

I tried to index data into arrays and subtract the location by 1, but also didn't work. 

 

 

I need an advice to avoid this shiftting. what i need is to represent my data in the same position of the real object over the sensors. 

 

 

Also i found that at some point the labview breakdown and the computer shutdown when i apply a big force, i increased the resistivity through using big resistors such as 1Mohm. but still no woriking. 

 

however, when i applied the same force using just the serial monitor of Arduino, nothing broke down and everything went smoothly. 

 

 

 

any suggesting. 

 

 

 

 

Thanks in advance and for a long subject. 

0 Kudos
Message 1 of 7
(2,751 Views)

My guess is you're using an intensity chart, not an intensity graph. But it's going to be near impossible to know for sure without seeing any code.

 


@N.Ghrayeb wrote:

 

Also i found that at some point the labview breakdown and the computer shutdown when i apply a big force,

 


You're not applying the big force to the computer, are you? Smiley Very Happy

 

Anyway, seems like a different problem. I'd say it's electrical and not software.

0 Kudos
Message 2 of 7
(2,734 Views)

wiebe@CARYA 

 

hi there, 

 

i'm pretty sure that i'm using intensity graph. 

 

any way take a look for the VI, i'm using 2016 version 

0 Kudos
Message 3 of 7
(2,729 Views)

Ok, that is an intensity graph.

 

I obviously don't have the data coming in. I replaced that data with a random array of 12 elements. That works as expected. Of course there is an up going "wave" through the image. Not sure if that's what you mean? If it is, simply update the images every 12th frame (when remainder from quotient & remainder is 0).

 

Most obvious problem when the image is shifting, is that you get the wrong number of rows (11 or 13). No telling without the data.

 

BTW. the string in the top shift register, and de 2D array in the shift register below keep growing for ever. So your memory will be filled until stuff breaks down (LabVIEW, maybe Windows).

0 Kudos
Message 4 of 7
(2,722 Views)

can you post your solution please. 

 

simply update the images every 12th frame (when remainder from quotient & remainder is 0).

i didn't get it well i'm afraid. 

 

Most obvious problem when the image is shifting, is that you get the wrong number of rows (11 or 13). No telling without the data.

see that attachment, just representing my finger over one point at a time. 

 

BTW. the string in the top shift register, and de 2D array in the shift register below keep growing for ever. So your memory will be filled until stuff breaks down (LabVIEW, maybe Windows).

good point never thought about it. 

 

 

 

0 Kudos
Message 5 of 7
(2,718 Views)

BTW. the string in the top shift register, and de 2D array in the shift register below keep growing for ever. So your memory will be filled until stuff breaks down (LabVIEW, maybe Windows).

 

 

that is a solution for the first problem. 

 

 

 

however, i was thinking about clearing the Q&R every 12 frames. this is what i didn't get yet. 

0 Kudos
Message 6 of 7
(2,709 Views)

>can you post your solution please. 

 It's hardly a solution, I just removed your serial read.

 

>>simply update the images every 12th frame (when remainder from quotient & remainder is 0).

>i didn't get it well i'm afraid. 

I'm not sure if it's the problem. Not sure what you want: 1) update the image line by line, or 2) update the image when it's complete (every 12 lines). Both make sense. You have 1) now, and it might be fine.

 

>>Most obvious problem when the image is shifting, is that you get the wrong number of rows (11 or 13). No telling without the data.

>see that attachment, just representing my finger over one point at a time. 

If this is logged serial data, the empty lines will be a (the) problem. The line has no data, but still produce an empty string, and the loop counter will increase. So you'll skip a row each image. 

 

You should do modulus 13, not 12. The array size can stay the same (12X12). Each 13th (empty) row will simply be ignored. This seems a hack, but should work as well.

 

A less quick and dirty solution is this. So you need a shift register to keep row count. When the string is empty, don't increment the row count. Also skip the replace in the array, and optionally skip the interpolation.

 

>>BTW. the string in the top shift register, and de 2D array in the shift register below keep growing for ever. So your memory will be filled until stuff breaks down (LabVIEW, maybe Windows).

>good point never thought about it. 

It's a classic memory leak.

0 Kudos
Message 7 of 7
(2,702 Views)