array(n elements) to string conversion

[antoker]

i got some questions about data conversion:
i have an array with n elements, witch i need to extract and convert to string in order to send data over udp vi. the problem is
that the vi is getting pretty big and i'm starting to wonder about memory&cpu usage. So can anyone check
this vi out and see if there is place for improvements.

[Kjell-E]

kult å se andre nordmenn som bruker LabVIEW! 🙂

I'll take a look, but I'm fairly new to the game so I cant promise any great results!

[Kjell-E]

Ok, I've got some immidiate thoughts here, but as always, I might be wrong in my statements.

In your VI's, you have 6 elements. First you build an array, then you index and take the array appart again..

From the vi that you have provided, you do not ever use the first array you create, and as such it is obsolete.

I've modified your VI and attached it here for you to see what I mean.

I have also changed your input-controls to save space on the block diagram by right-clicking and removing "show as icon", though this is a user preferance thing.

I'm going to take a look at the rest of the code and see if I can suggest any other changes as well. As for now, this is what I've done.

*removed obsolete array and array indexing.

[antoker]

hehe 😉

This array i created, with six elements is just for simulation purposes 😉
I'm building communication module for a ROV, so data comes as a N-elements array
from an usb-daq 6008, wich retrieves data from different sensors.  I  just  thought
that there is another way for converting an array of double to a single string (not array).


FF, var jo overrasket 😉 Takk for hjelpa.

Message Edited by antoker on 12-04-2005 12:54 AM

[Kjell-E]

I've done some more changes and hidden most of the code in a sub-vi. I've also shown how to make the code scalable, in case you suddenly need to accomodate 7 or 10 inputs.

In the new VI's, I've shown 2 different approaches to your code, but both are functionally equivalent.

As far as performance, you can always gain a little boost by going to File --> VI Properties --> "Execution" and deselect "Allow Debuging".

There might be other ways to optimize your code, but the thing you need to ask yourself is if this is really necessary.

If you go to File --> VI Properties --> Memory
you will see some "stats" for your current VI.

The one you posted originally, has a memory footprint of ~117.5k... as for cpu-usage, unless you are working with a significantly bigger project, you do not need to worry about performance at all, unless you are on a very very old computer.

That said, optimizing code is always important, and it is a very good way to learn, but sometimes one must be able to see when "enough is enough" and something is "good enough". 🙂

For comparision, the new VI I made for you, which includes 2 examples/different ways of doing it, takes only ~56.7k... though I'm not sure if you need to add the sub_vi to this or if it is already added.. the sub-vi is ~23.7k total..

Hope this helps you, and if someone else can take a look to see if there is any other obvious ways to optimize the code, then both me and the thread-owner will learn something more here. 🙂

[Kjell-E]

To me, it's the addition of + or - as well as space's that adds overhead...

Seems like a weird format to me, unless the recipient is a human?
But I dont have the whole picture here, and you probably have a very good reason for adding spaces and +'s.

you might want to take a look at the "type cast" and "flatten to string" (use the "search" in the vi-template to locate them), or even format into string.. I'll play some more with that... I have an idea of a completely different way of doing what you are doing... as to wether or not my new idea will be more efficient.. I dont know.. we'll have to wait for the big guys to get here! 😄

[Kjell-E]

Got a new version ready... this one does not need any sub-vi's and is scalable for "any" array size.

As for speed, I dont know.

If you know ahead of time how big your input array is, right click on the array and choose "fixed size" as this might help memory allocation and things like that.

Hope this helps you!

[antoker]

ok, thanks for the info.

[altenbach]

First of all, all that extra code to get the plus sign to show up can be handled with e.g. the "%+2.2f" format, no comparison operation or case structure needed.

Also, note that the input array is autoindexing, thus we don't need to wire the number of iterations. It will be automatic.

Here's a simplified version that does basically the same thing ;).