LabVIEW
let's rock... altenbach...
With all respect, I provoking you... here you make some affirmations...
"Exactly! I would strongly recommend that you don't post all these flawed and offtopic code images full of race condition, local variable overuse, generic labeling, deeply stacked sequences, value property overuse and Rube Goldberg constructs in general. It really has nothing to do with the topic of this thread and is thus not helpful. Yes, one can use a chart to only display the last 100 points, but here we also need to take the FFT of the last 100 points of data that streams forever and I don't think it is a good idea to read out the history data with each iteration."
here... https://forums.ni.com/t5/LabVIEW/Waveform-Graph-showing-entire-data-history/td-p/4146679/page/2
Speak / critics / academic words... well... sustain what you say. demonstrate that you are best that a guy that have nothing in comun with LabView and make this .vi in 3 weeks. you have 3 weeks to make it SIGNIFICANTLY BEST !!! let see in what time a LabView guru it make this... better and... how better !!!
here you have the .vi... think that will be a copyright protected program, will be a comercial program, I risk and I sacrifice them, I'l put it here to see... how good are you.
we do not speak about this sub routine... here you help me. for the moment I don't change it with your recommendations.
make you... a sinonim of this... in another way. be best that a greenhorn. 😉
let see you... I bet that you don't make it 30% better !!! I make this and I DON"T KNOW LABVIEW. you have a life... in... LabView.
LabView 2020 please (I love NXG look 😉 )
P.S. you need a .csv file... I edit the message and attach the.csv file
So, you're asking one of the best developers around to rewrite your program for free? 🙄
As for "30%" better... measured by what metric? Your opinion?
I would argue that someone could easily make it "30% better" in just a few minutes by fixing any one of the many issues. For example:
- Giving your controls / indicators meaningful names
- Preventing your program from hammering your HDD by reading a file every loop iteration
- Not hammering control property nodes every loop iteration
- And fixing... well, whatever it is you're doing here
And, if someone wanted to spend an entire hour on this and convert it into a simple producer / consumer architecture with an event structure it would become a couple orders of magnitude better. Cramming everything into a single loop like you've done makes adding new features or even following the logic to debug something extremely difficult.
But hey, maybe your taunt will work! I personally don't think anyone is likely to be goaded into doing work for you for free. Maybe if you were to make a friendly wager, as voted by the community here.
@BowenM wrote:
So, you're asking one of the best developers around to rewrite your program for free? 🙄
As for "30%" better... measured by what metric? Your opinion?
I would argue that someone could easily make it "30% better" in just a few minutes by fixing any one of the many issues. For example:
- Giving your controls / indicators meaningful names
- Preventing your program from hammering your HDD by reading a file every loop iteration
- Not hammering control property nodes every loop iteration
- And fixing... well, whatever it is you're doing here
And, if someone wanted to spend an entire hour on this and convert it into a simple producer / consumer architecture with an event structure it would become a couple orders of magnitude better. Cramming everything into a single loop like you've done makes adding new features or even following the logic to debug something extremely difficult.
But hey, maybe your taunt will work! I personally don't think anyone is likely to be goaded into doing work for you for free. Maybe if you were to make a friendly wager, as voted by the community here.
please... not elementary things... I specify that this .vi is not "polished", I just make it work... 😞 this things I have it on my list... I know it, I say it to altenbach that I know... this elementary things...
@xipxid wrote:
Speak / critics / academic words... well... sustain what you say. demonstrate that you are best that a guy that have nothing in comun with LabView and make this .vi in 3 weeks. you have 3 weeks to make it SIGNIFICANTLY BEST !!! let see in what time a LabView guru it make this... better and... how better !!!
Sorry, I have nothing to prove here. We can talk once you have almost 45k posts, 30k+ kudos and over 2000 solutions here in the forum.
Looking at your code, I would delete it, study the requirements document, and start from scratch. It is completely botched. And no, I would not do the work for you, because I don't get paid for it and you would get all the credit. And yes, I could make it orders of magnitude better and I would not need 3 weeks! Maybe 30 minutes. It would do the same more efficiently and with 20% of your code.
Some quick comments to get you started:
- Almost none of your terminals are wired and you do almost all of it with local variables. There is no reason for that. You seem to use front panel element as classic "variables" of text based code. In LabVIEW, the wire is the variable. And no, having disconnected terminal inside a deeply stacked sequence frame makes no sense. They could equally well sit outside the main loop.
- If your radio button is on item1, you are burning 100% of one CPU core, reading the same file over and over as fast as the computer allows. How often does the file actually change?
- Why would you need to read the radiobutton three times in parallel, twice vial local variables. can't you combine some of these case structures into one?
- How many "disabled" diagram constant with the same value do you really need? One should be enough! You are allowed to branch a wire.
- All property nodes that exist in both cases of a case structure belong after the case structure. Half the number of nodes!
- Most likely your "Lastval reset" will occur first thing on a new iteration of the while loop. I assume you want it to happen as last item of the iteration. All four of your top-level case structures execute in parallel and there is no way to predict the order of execution.
- You can probably eliminate all (or most) local variables by wiring the actual terminal in their place.
- Give all controls and indicators reasonable name (Numeric 1 ... Numeric N is NOT reasonable! etc.)
- You don't need to convert a scalar to an array with one element to wire to a chart.
- It is pointless to convert two scalars to an array followed by array to cluster (and you did not even correctly se the cluster size!). Just wire them to a bundle node instead. Half the code!
- Same for the strings. Just wire to the terminal. No need for locals (image below)!
- It is recommended to avoid excessive overlapping controls and indicators. Very taxing on the UI system.
- Shouldn't your shift register be initialized?
- No, tip strips don't need to be rewritten with every iteration of the loop. You can define them at edit time. No need for property nodes.
- What's the point of interpolating twice in a row?
- Most of your booleans (e.g. sitting in frame 1 of the sequence) are never used anywhere. Why are they there? Future expansion? Your code will not scale well!
- ...
