LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

extracting data from a 18byte data packet

Hello

I am a third year avionics undergrad and as part of our project I have been assigned the task of developing a wrapper function for an inertial sensor. I am new to labview but I think I am doing reasonably well so far.

The sensor has a rs-232 interface. So far I have made the VI write to the sensor requesting a data packet every 50ms(i believe that is done using the wait function within a case structure). The sensor should respond with a 18byte data packet. The problem I am having now is that I only want to access particular bytes of data in that data packet (in particular bytes 1,2,15,16 if the bytes are numbered from 0to17). Is there a way to do this or am I approaching this problem the wrong way?

Any help is appreciated.
0 Kudos
Message 1 of 21
(4,331 Views)
You can push your data through a For Loop and index it with a second array containing the indices you want, e.g., 1, 2, 15, 16. Use auto-indexing only on the indices array. The resulting output array will contain the data only from the given indices.


Message Edited by Bill@NGC on 08-23-2007 12:55 AM

Message 2 of 21
(4,314 Views)
Sorry I am very new to labview.
 
Your explaination makes sense except that my data is not already in an array to begin with, as is shown in your diagram.
 
Say I have 18 bytes of data in the read buffer of my serial read, how do I put that data into an array?
0 Kudos
Message 3 of 21
(4,287 Views)
In the string / string conversion pallette, there is a function called String to byte array.
Message 4 of 21
(4,280 Views)
I have only begun to test my code now but I am encountering a problem of a different nature. I think it has to do with setting up the com port. If I connect the error ins/outs together, an error will come up saying there is an error at the visa configure serial port property node and will not run. If i take it out the error goes away and runs but nothing comes out of the serial read.
 
Any help would be much appreciated.
0 Kudos
Message 5 of 21
(4,223 Views)

You did not provide the most important part to help solve the problem - the actual error code and message. You have a VISA Read after the VISA Write in the case statement. Assuming that you have all of this inside a while loop that's not seen, the VISA Read will always execute. Is there any data to be read if the true case is not selected? Assuming again you have an unseen while loop, your VISA Configure Serial Port should be outside the loop and only run once. That won't cause an error - it's just good programming.

Message 6 of 21
(4,218 Views)

Hi Yush,

      Your original post asked how to extract specific bytes from an 18-byte packet.  One way might be to cast the packet directly to a cluster of bytes, and unbundle the bytes by name - it's pretty clean.  But this assumes the packet is exactly the data you're expecting and if there's a leading character, checksum and/or CRC I'd add some code to check for it (before the cast.)  Actually, to examine/dissect the packet for correctness I'd use the string-to-bytes method RF described and forget this casting! Smiley Tongue (just add it to you bag of tricks...)

The posted .png shows some ambiguity re execution-order - theoretically, the writes for Reset, Scale, or Zero could occur AFTER the 'G'O Smiley Surprised .  I'd wire all these settings in a sequence! Smiley Wink 

Cheers!

Message Edited by tbd on 09-27-2007 12:30 AM

"Inside every large program is a small program struggling to get out." (attributed to Tony Hoare)
Download All
Message 7 of 21
(4,203 Views)
Does it matter if there is no data to be read for the false case?? Right now I have things going straight through when the false case is selected. Would the bytes at port be a better option so that it can account for both the true and false cases?
0 Kudos
Message 8 of 21
(4,193 Views)

Hi Yush,


@Yush wrote:
Does it matter if there is no data to be read for the false case??

It could matter but the consequence of returning zeros (the default of the cast) depends on the context, the enclosing diagram - Dennis's "unseen while loop"! Smiley Surprised

The .png looked like example code and it wasn't obvious (to me) that the "Start" was necessary in order for data to be available ( maybe once started all that was needed is Read.)  It also seemed the "Read" ought to be by itself, in a loop instead of doing the Config AND Read repeatedly.  There ought to be a VISA Close somewhere too. Smiley Wink

If the value of "Start" determines whether data will be available, then why call Read if Start=F? - no need for bytes-at-port then.  If there's a Read alone in a while-loop, polling for data, then sure use bytes-at-port - or just let the Read time-out and throw an error - maybe you'll want to know if the device has stopped sending data?

Cheers!

"Inside every large program is a small program struggling to get out." (attributed to Tony Hoare)
Message 9 of 21
(4,185 Views)
For completeness I have added in the section which connects to the output of the serial read from my first bit of code. There are no unseen while loops that you mentioned, but I do sort of understand what you mean when you say that the serial config should be outside of the rest of the code which should be enclosed in the loop.

In regards to why I've put a start button in, my logic was that the user should be able to tell the program when to start polling and when to stop. The sensor should respond with a packet of data whenever the G command is sent. I take it that you assumed that there were unseen while loops which shouldve taken care of this problem?

While we're here I may as well mention another section of the code which I believe will have problems. The idea is that the actual piece of data is represented by a 16bit signed integer in 2's complement form. The data is sent as 2 bytes and I want to concactenate them somehow to 'recover' the piece of data. You will see in my code that I have indexed the 2 particular bytes of information I need, converting the first byte to a byte integer (signed I presume though it doesn't say explicitly) and the least significant bytes as an unsigned byte integer, then converting to a hex string, concactenating them before converting back to a number. Is this the right way to go about it?

Another thing I don't fully grasp is what happens when I choose to run the VI continously. Does it just cycle through the entire piece of code over and over from start to finish?

Also, one thing I noticed in your code tbd was that none of the resource name outs of the visa write blocks were connected to the visa read resource name in node. Should I be doing that as well? (Right now I have connected the resource name out of the 'start' section to the resource name in of the serial read)

As for the error code which came up when I tried to run the VI, I am currently not at the lab but I will try again tomorrow to see if the error comes up again and take note of it.
0 Kudos
Message 10 of 21
(4,169 Views)