LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Most efficient hex string to number conversion



@Perl Peril wrote:

 But I've never seen the symbol in Altenbach and tbob's code. What does it do? Is it only in labview 7?




  • Reverse 1D array looked different in older versions of LabVIEW. Function is the same (array palette).
  • Join Numbers is in the "Advanced..data manipulation" palette. Check the LabVIEW help.
  • Index array might not be resizable in older versions of LabVIEW. Don't remember. Maybe you need four instances with explicit indices.
0 Kudos
Message 11 of 22
(1,695 Views)

Oh, excuse me, my mistake. Credit where credit is due. Sorry to both fahlers and tst.

0 Kudos
Message 12 of 22
(1,696 Views)


@tst wrote:

SOME ORDER, PLEASE!!!!
tbob's and Altenbach's second solution are identical to mine, so you can read my post.
The optimized code was not mine but Franz's (Way to go, Franz, 5 stars).


Sorry, tst, I did not see you post, only looked at the pictures ;).

  • Yes, yours is the same. 5 stars for tst 😄
  • tbob indexes backwards which seems to slow it down by a few percent. probably not significant
  • fahlers is clearly slower on my computer for some reason. (this might be different on a big-endian computer i.e. non windows) 😉
0 Kudos
Message 13 of 22
(1,689 Views)
Sorry, altenbach, my first timing statement was incorrect: my solution was only 3-4 times faster than your first solution, but it is 9 times slower than your optimal solution (maybe mine's the winner in terms of real screen estate). You're the Champion!!!

-Franz
0 Kudos
Message 14 of 22
(1,677 Views)
tst said:
---------------------------------------------------------------------------------------------------------------

SOME ORDER, PLEASE!!!!

tbob's and Altenbach's second solution are identical to mine, so you can read my post.

----------------------------------------------------------------------------------------------------------------

 
This is becoming a "race" condition...Smiley Very Happy
- tbob

Inventor of the WORM Global
Message 15 of 22
(1,667 Views)


@tbob wrote:
This is becoming a "race" condition...Smiley Very Happy


This is always a problem with mutithreaded forums.  😄
 
The real problem is the fact that all solutions (even the original) are probably fast enough if the instrument really sends only one little-endian U32 at a time. All the other stuff, e.g. communication overhead is probably the real time hog.
 
Perl Peril , If you notice slowness due to the conversion, it probably means that you are converting tons of data points.
How is the original data organized, e.g. do you possibly get an entire array at once from the instrument? In this case there might be better solutions to directly convert a long string to an array of U32 numbers. Do you have more details on this?

Message Edited by altenbach on 08-08-2005 01:28 PM

0 Kudos
Message 16 of 22
(1,652 Views)

Altenbach,

  Do I have miore details?  Of courseSmiley Very Happy, I'm writing the entire software interface!

Anyways, the instrument dumps lots and lots of data onto a UDP port in packets, each of 16384 bytes.  The data is organized so that the first 16 bytes are header information (such as packet #, and start chars), the next four bytes represent a number for field A, the next eight bytes are 2 numbers for field B, the next four numbers are for A again, and it repeats until the end of the packet.  Typically, I receive around 250 packets for each data file and all of the packets must be interpretted together to produce a spectrum.  Currently, I wait for the first packet to be at the UDP port and then use a for loop to read off the remaining packets as specified in the headers.  During the transfer, as little processing as possible is done so that we will not miss any packets (no hand shaking in UDP).  The data is left in string format, and is simply concacenated together.  All of the processing is then done (like what you have all helped me speed up) but must be done quickly so that the processor is free for the next data file.

  If needed, I'll attach my actual vi's, but they may be hard to understand without an actual description of the entire instrument and data formats.  Also, we are restricted here by a non-disclosure agreement.  Thanks for any help you can offer,

PP

Oh, I forgot to mention that the ultimate goal is to plot the data for the user on a chart (I've been using a simple array)

Message Edited by Perl Peril on 08-08-2005 03:48 PM

0 Kudos
Message 17 of 22
(1,644 Views)
OK, if you can concatenate your strings that they only contain U32 data in the form of ABBABBABBABB.... You can probably do the entire conversion in a few easy steps.
(For example, have a look at this recent thread: http://forums.ni.com/ni/board/message?board.id=170&message.id=135879 . You still need to do the endian conversion, but overall your problem is easier because all numbers contain the same number of bytes.
0 Kudos
Message 18 of 22
(1,631 Views)

Thanks Altenbach,

  That information does seem useful, but I can't view the VI's!Smiley Mad I'm using Labview 6.1

If anyone has some free time and labview 7, would you mind posting the VI's in the thread Altenbach has suggested, as pictures?  Thanks in advance,

PP

0 Kudos
Message 19 of 22
(1,593 Views)
Here is one of the vi's converted to LV 6.1:
- tbob

Inventor of the WORM Global
Message 20 of 22
(1,576 Views)