LabVIEW
Scaling time axis on a chart
Solved!
I'm not sure what is wrong.
I do thing it's a bad idea.
Changing the multiplier continuously, will only represent correct values for the most recently added samples at best. The rest will be completely wrong. If you have 1000 samples at 1 ms, that's one second. If you change it to 1 second, all the data will get this multiplier, and you'd be looking at 1000 seconds of data. I don't see how that's going to work.
If you have variable timed samples (dT changes), you should consider an XY graph. Downside is that each channel needs it's own timestamp, and that you need to keep your own array. Upside is that it will work.
Search LabVIEW like a graph! You should really spend some time doing courses. There are tons of tiny things, and quite a few big things that need to be done different. Probably not what you wanted to here.
As for the problem, I can run those VIs. Can you delete everything that is not relevant, and make an example that shows just the problem?
Sometimes when the Big Picture seems to go astray, wiring a Tiny Example can "prove a point". Here is a demonstration that (in principle) your method should work (assuming that your Refresh Rate is constant and not so fast that the rest of the stuff inside the loop can't keep up).Scaled Time Axis Demo
Bob Schor
@PTimmer wrote:
I have absolutely no idea why but the code started working. Thank you for your feedback. I am sure as i am a total beginner in labview and coding in general a lot of things are not very efficient or elegant.
It's not just about efficiency or elegance.
Bugs hide in code. The more code, but especially the messier the code, the more bugs will hide. Bugs can be in clean code, but they usually can't hide. So they are easier to find.
@PTimmer wrote:
Could you give me some more precise examples what i should do differently (especially the big things) and maybe point me towards those courses you are talking about?
The small things:
Left to right wiring, straight wiring, use some build in functions iso lengthier replacements (=0).
bigger things:
Start using sub VIs. One big VI will outgrow your project soon.
Start using some architecture. A state machine, queued message handler, producer\consumer, maybe even actor framework.
You can't keep developing by simply adding things to one VI. People tried before. Most fail. But at best, you have a program only you will understand.
I know most of these (not the wiring though: no excuses for that!) are only possible with experience. So, get experienced would be the advice.
There are functions for:
Equal?(x,0) -> Equal to 0? (x)
Select (0,x,1) -> Boolean to 0,1 (x)
Or ( Not(x), y) -> Compound Arithmetic (x, !y)
You didn't do too bad, but these still scream 'beginner'.
Case defaults can be removed. For instance empty arrays or 0's inside a case can be deleted. NI style guide says you shouldn't IIRC, but it's better AFAIC.
You have some VIs, and that looks good (can't look into them of course). You should do the same for the serial device. Imaging how your code would look if the rest was in sub VIs. That is everything that makes sense, everything that could potentially be reused, and does (only) one thing.
You still have duplicate code. The Get Array Element\ Fract\Ext String to Number\ Case \ SubVI seems 4 times duplicate. More then 2 call for a for loop. And maybe a sub VI.
Some feedback nodes should be shift registers. They will introduce problems if\when you start looping this code, as the init only happens once, not every time the loop runs.
Use the correct types You have a few doubles, that seem to be indices. So, make them I32 integers! That not only removes coercion dots, it's also much clearer to read.
Those indices (Gas 1, Gas 2, ..) should probably be something stronger. Like a type def'd enum.
Use CTRL+ALT+Drag to remove all the empty space. You'll have a much better programming experience once the VI (every VI) fits the screen. And having a bigger screen doesn't count.
