LabVIEW
My First VI
Well, coming here is an excellent start! At the main LabVIEW forum page, you'll see some training links at the top.
If you are using the company's LabVIEW license, LV 2020 still has an active SSP. Ask your manager if it's okay to take the training associated with it. Those are golden. (But make sure to ask your boss because it's the company's license, not yours. They'll probably say, "I didn't know that training came with the license - go right on ahead!")
And don't be afraid of coming back with stuff that you've tried and ask questions. We don't bite too hard. And browse all the topics that look interesting to you. And even some that don't!
I can't look at it right now because I don't have LV 2020 here at work.
After taking a peak at your code I would definitely suggest starting with the beginner tutorials. There are a lot of basics that are missing. It's by no means the worst LabVIEW code that I've seen, but could definitely use improvement. You should learn about making subvis in order to eliminate duplicate code. You should learn about different code architectures. A state machine is likely to be a better architecture. You should also be mindful of datatypes. There are a lot of red coercion dots in your program.
Seems you spend a lot of time with this, and the good new is that next time it will take you 20% of the time and 20% of code to do the same better! 😄 Front panel looks nice! Diagram is impressive for a beginner, but shows that you should probably start with the tutorials first. Don't jump into the deep end before taking swimming lessons.
Some generic advice:
Try to avoid express VIs. They hide and complicate code and are hard to debug.
Be aware of race conditions! The most obvious is your "init all to default" There is a nonzero chance that it will clear your paths before the code has a chance to read the terminals, and this is not something you would want. Typical programs don't need that node at all.
Your "decode" button has no label, which potentially introduces a lot of ambiguity on the diagram. You can hide the label on the front panel (right-click...visible items...), but don't change it to an empty string!
Can you quickly summarize the math you are trying to do. Looks like angles and distances. Maybe the two input inverse tangent or even using mostly complex data would simplify things! There are also much simpler way to unwrap an angle. No case structures and comparisons needed.
Hi miranello,
good job so far!
More generic advice:
Try to put stuff, which is done repeatedly in a loop, once before the loop. Example: in the inner FOR loop you call SwapBytes again and again. You might do this just once after reading the file content…
Use the provided functions to simplify your code. Examples: there is a "+1" primitive, so there is no need for Add with "1". There is a combined Sin+Cos function. FormatIntoString can be used to format more than one input value, so there is no need to call it 3 times when saving the results…
Don't duplicate code: create that code once as a subVI and call that subVI several times! So there is only one place to test&debug instead of several places in a mainVI! Example: "AngleCorr+ATAN+RadToDegree" is called 3 times in your VI…
Learn about usage of the error wires! Most "complicated" functions provide errorIO connectors, like the file functions. Use the error wires for handling errors and to force DATAFLOW.
Always make the "style/radix" indicator visible for string/numeric constants when you don't use the default style (normal display, decimal numbers). This way your code is much more readable.
Datatypes have been mentioned. Whenever you change the representation of a numeric, LabVIEW will need to make a datacopy and convert to the new representation.
Here's a quick example of what you do and what you should do instead:
In this code fragment, we want to run a FOR loop as many times are there are TRUEs in a boolean array and monitor the progress.
TOP (your code):
Boolean to 0,1 outputs I16 so the sum will be incorrect if the result is expected to be larger than 2^31-1. Thus we need to convert to something with more bits. The result is an integer, so DBL is definitely wrong. You can see the red coercion dot at the N where LabVIEW trims it down to I32 again.
For the progress, you divide the I (I32) with your DBL, multiply with a 100(DBL), then shove it into a progress bar that is U8. Look at all these coercion dots. You code has the measles! Since N is always larger than [i], there is a change that your progress bar ends at <100%, confusing the operator.
BOTTOM (Better alternative)
The correct choice is I32, because that's all the N of the FOR loop accepts and also the maximum array size. It is guaranteed not to overflow! We use "i+1 so we are guaranteed to end at 100%. We multiply by 100 first so we can do an integer division later. We change the progress bar to I32. No everything is the same datatype. No coercions!
@altenbach wrote:
For the progress bar, I rather not repeatedly do the math inside of the loop. Instead, I set the scale range maximum of the bar to the number of times I will iterate. I am subtracting 1 here because i starts at 0 instead of 1. The bar will fill up as the loop iterates and be full at the end.
@crossrulz wrote:
For the progress bar, I rather not repeatedly do the math inside of the loop.
Yea, but that math is typically peanuts compared to anything else (and if the loop is very fast, we don't need a progress bar!). 😄
(I am not sure about the cost of changing the scale, because that involves a (synchronous?) thread switch to the UI thread. The coercion is somewhat ugly too...;)) My code could be wrapped into a tiny inlined subVI with i and N as input and progress as output.
The fun starts if you want a progress bar for a parallel FOR loop. Since [i] will be all over the place, you need to jump through some flaming hoops anyway. 😉 (Here is an early draft).
