LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

New to labview - doing a serious project

"
 
//DAQ System
unsigned int sensor1;//extremly important these are unsigned, since with bit shifting its posible a negative bit could be assigned.

void main ()
{
usart_init(115200);  //256000 The fastest capable rate  for PC's ...(9600 baud rt snd 1 stop bit.)
ADCON1 = 0;  // Configur all ports pins as analog. VDD as Vref.
TRISA  = 0xff;  // PORTA is input except last two pins.
TRISD  = 0; // PORTD is output for sensor1.
TRISb  = 0;    //all port C outputs for sensor2.
 
          do{
    sensor1 = Adc_Read(0); // Get results of AD conversion from PORTA.F0 (1st sensor)
    usart_write(sensor1>>2);  // Send 8 most significant
            

            }while (1);
           
}
"
These are very simple codes im using in the PIC.   Of course for multiply channels I need to make a case statment to create a multiplexing effect.
...:::Cheers:::....
0 Kudos
Message 31 of 46
(1,484 Views)
I might be misunderstanding something, but I'm not sure why you're varying the baud rate the way you are. You should define for your PIC what baud rate you want to be sending the data at, and that baud rate will have to be the same on your application (LabVIEW) side. If the baud rates are mismatched you won't be able to receive the data properly.

Are you defining the baud rate for both sides, or just on the LabVIEW end only?
Rasheel
0 Kudos
Message 32 of 46
(1,443 Views)


Sputnikrent wrote:
I might be misunderstanding something, but I'm not sure why you're varying the baud rate the way you are. You should define for your PIC what baud rate you want to be sending the data at, and that baud rate will have to be the same on your application (LabVIEW) side. If the baud rates are mismatched you won't be able to receive the data properly.

Are you defining the baud rate for both sides, or just on the LabVIEW end only?



I always make sure the baud rates are the same on both sides.

 

...:::Cheers:::....
0 Kudos
Message 33 of 46
(1,419 Views)
Well anyway I can still use the half range input... since its still in proportion to the real channels values....
 
I will just use make 255 proportional to 5 Volts (65mm)   and 128 prop to 0Volts (0mm)..
This works nicely...For one channel
 
Now im working on multiple channels....
 
 
At the moment 2 channels. Using multiplexing method... As ive shown in the .doc.
Does anyone have any ideas about why this method I have chosen to use doesnt work???
 
Its basic... Yet the values in labview get mixed up.  Channel one would be shown in channel two, etc..
 
Any help again would be appretiated
...:::Cheers:::....
0 Kudos
Message 34 of 46
(1,411 Views)
Here is a more clearer diagram and explenation.
 
 
 
 
Smiley Happy
...:::Cheers:::....
0 Kudos
Message 35 of 46
(1,392 Views)

Instead of posting a partial image (or one hard to read) in a .doc file, please just post the actual VI. Click the Browse button below the message body. Simple and direct. You can post a word doc there as well instead of linking to it.

From the brief look that I did, your array indexing of the serial read appears to be all wrong.

Message 36 of 46
(1,364 Views)
 
 
 


Dennis Knutson wrote:

Instead of posting a partial image (or one hard to read) in a .doc file, please just post the actual VI. Click the Browse button below the message body. Simple and direct. You can post a word doc there as well instead of linking to it.

From the brief look that I did, your array indexing of the serial read appears to be all wrong.




This is the LabView file.
 
Please emphasis.
 
 
Thanks
...:::Cheers:::....
0 Kudos
Message 37 of 46
(1,344 Views)
 
 
 


Dennis Knutson wrote:

Instead of posting a partial image (or one hard to read) in a .doc file, please just post the actual VI. Click the Browse button below the message body. Simple and direct. You can post a word doc there as well instead of linking to it.

From the brief look that I did, your array indexing of the serial read appears to be all wrong.




This is the LabView file.
 
Please give explanation to why its wrong.
 
 
 
...:::Cheers:::....
0 Kudos
Message 38 of 46
(1,344 Views)
One problem you have is you are just reading in a series of bytes endlessly in a loop.  (How do you stop the program?  You have a False constant wired to your while loop stop terminal.  The only way to end this program is by pressing the abort button.)  How do you know which byte represents channel 1 and which represents channel2?  If you wind up with a 3rd or more byte, it just gets thrown away.  If your reads get out of synch with the device that is sending data, you would easily wind up reading the 2nd byte first.
 
You have some complicated and convoluted structures going on with your feedback loops.  Try using shift registers instead as they are easier to read.  But I don't think you need either shift registers or feedback nodes in your case  A boolean condition of =0 and then =True, just means the same thing as equal to zero.  You are keeping track of an index value and resetting it when it is somewhere around 80 (not sure because you are always acting on the last loop iteration data).  Are you sure you always have 80+ bytes worth of data in the serial read in order to eventually be able to index that high?
 
If you are just interested in 2 bytes, the first and the second, then just put a 2 in front of your serial read for the number of bytes to read.
Message 39 of 46
(1,342 Views)


Ravens Fan wrote:
One problem you have is you are just reading in a series of bytes endlessly in a loop.  (How do you stop the program?  You have a False constant wired to your while loop stop terminal.  The only way to end this program is by pressing the abort button.)  How do you know which byte represents channel 1 and which represents channel2?  If you wind up with a 3rd or more byte, it just gets thrown away.  If your reads get out of synch with the device that is sending data, you would easily wind up reading the 2nd byte first.
 
You have some complicated and convoluted structures going on with your feedback loops.  Try using shift registers instead as they are easier to read.  But I don't think you need either shift registers or feedback nodes in your case  A boolean condition of =0 and then =True, just means the same thing as equal to zero.  You are keeping track of an index value and resetting it when it is somewhere around 80 (not sure because you are always acting on the last loop iteration data).  Are you sure you always have 80+ bytes worth of data in the serial read in order to eventually be able to index that high?
 
If you are just interested in 2 bytes, the first and the second, then just put a 2 in front of your serial read for the number of bytes to read.


At the moment I stop the program by hiting abort execution in labview.
 
The only way I know to identify each channel is , by knowing the order the PIC is sending them. that is ch1 then ch2, bak to ch1 etc..... Yes doesnt sound like the best idea,
I was thinking one way I can do it is by sending a identification tag byte before sending the channels data... for example..
 
Usartwrite("A");
 
Usurtwrite(Sensor1);.
 
 
 Yer , I changed the visa read number to 2, and and with a reseting limit to 1. So its just ch1 and ch2 alternating "1" and "0"....
 
But still having touble with channels not getting mixed up.. I was thinking it could be reading the data to fast .
...:::Cheers:::....
0 Kudos
Message 40 of 46
(1,320 Views)