LabVIEW
convert string to float
Solved!
@muks wrote:
"Decimal string to array"
NOT decimal string to array. The name is misleading. By "decimal" NI means "base10" just like Hexadecimal means "base16." In other words, a base10 integer. The proper node to use is "Fractional String to Decimal" as described in another many previous posts.
I do have some suggestions.
Clean up the block diagram. Having wires going behind things and going backwards is akin to random indents in a text-based language. Just as random indents would split your brain between generating code and understanding it, so does unruly wiring and odd placement of nodes and subVIs.
Be better at dataflow. You do know more than the average non-LV developer, but there are still subtle things that indicate linear thinking. For example, all those conversions and re-conversions. Would it not serve you better to simply branch off at those points instead of using multiple conversions? And what does comparing the two tick counts to each other do? Dataflow indicates there are no data dependencies and either one could execute first, rendering the results meaningless.
Be careful using express VIs. They are definitely NOT designed with speed in mind. Just keep that in the back of your mind every time you decide to use one.
All those "islands" of code - do you want them to execute exactly once, because that's exactly what will happen. And when do you want them to execute? Before the loop does? After it does? At the same time? I realize a lot of it is just to generate fake data, but the way it is written, there is no data dependency and any of those islands can execute in any order - and the loop is just another island of code. I guess this kind of relates to point #2.
I guess that's it, really. I might re-think the states themselves, but that's just a preference thing.
@asnaev wrote:
well thx for the advices. I really need to clear my coding because some was made to experiment. Regarding the "islands" of code do u think i should try to synchronize some actions? the data aquisition its not complete, i will have to implement alot more.
I'd say you probably won't have to worry about synchronization if you incorporate the produce/consumer architecture into your code. The producer will produce data at the rate you want (within the capabilities of the equipment, of course) while the consumer will grab the data as it is needed.
The only isssue there is if the producer produces a whole lot faster than the consumer can consume the data. The queue buffer can get huge in a hurry. There are various ways around this, depending on what you can and cannot live with.
