05-21-2020 05:51 AM
Sadly for me it's the same behaviour. Initializing the shift register is what i tried in the first place but it didn't work for me, thats why i began fiddling around with it.
05-21-2020 06:24 AM
@MT_at_home wrote:
Sadly for me it's the same behaviour. Initializing the shift register is what i tried in the first place but it didn't work for me, thats why i began fiddling around with it.
This is NOT the same that you had in the first place. In the first place you had initialized the shift register with data, as altenbach pointed out, which were likely the extra data points that you referred to but never explained exactly which ones were extra. Can you explain exactly the problems that you are seeing now since what you are showing here is different from your original? One thing that I see immediately is that you still have race conditions due to your persistent refusal to take the advice given to get rid of the local variables. Run your program in highlight execution mode (the light bulb on the block diagram) and watch how data flows through your program. This may give you some clues to your problem.
05-21-2020 07:06 AM - edited 05-21-2020 07:56 AM
By unwanted double datapoints i mean that the same y-Values are plotted twice, once where they should be and a second time at the next x-Value.
Like seen in this plot.
I can't figure out why i get the point at 0,1/0, the correct one is 0,1/25 and the point at ~0,08/25 is the one which shouldnt be there, ~0,8/28 would be the correct one.
By using the highlight mode i figured out that my Kraft-Value isn't calculated yet while the Schichtdicke-Value is already there and written to the array and plotted, thats where the initial mismatch of 0,1/0 came from.
The same things happens when "Schichtdicke" changes, in the first iteration with the new "Schichtdicke" simply the old "Kraft"-Value is used instead of waiting for it's recalculation.
By following your advice and using wires instead i was able to fix that.
Is there any way to make it look better than wiring across everything? It's just not easy to look at and keep track of.
05-21-2020 08:16 AM
If you wire correctly then wiring is the easiest to look at. Could you post your current code so that perhaps we can help direct you in how to make it look tidier?
Also, it is unclear from your last post as to whether you are still getting the extra data points after changing from global variables. Could you verify that you still have this problem?
05-21-2020 08:34 AM - edited 05-21-2020 08:35 AM
I was able to get rid off the double datapoints by avoiding local variables where possible.
For cleaning up my wiring i rearranged it a little now and read about using bundle/unbundle to keep it cleaner.
Maybe it's just my preference coming from text based programming to use variables and references with read and right.
You might be right, that generally it's easier to understand with neatly arranged wiring how things go.
Thx 4 the advice so far.
05-21-2020 08:46 AM
@MT_at_home wrote:
I was able to get rid off the double datapoints by avoiding local variables where possible.
For cleaning up my wiring i rearranged it a little now and read about using bundle/unbundle to keep it cleaner.
Maybe it's just my preference coming from text based programming to use variables and references with read and right.
You might be right, that generally it's easier to understand with neatly arranged wiring how things go.
Thx 4 the advice so far.
I think that a lot of it has to do with a different mindset. I have found that it is often difficult for people coming from text based programming to wrap their head around dataflow in LabVIEW. Yes, bundling is often used to keep the number of wires minimal. I often create classes to contain the data, and functions for the various tasks within the class. This makes my top level block diagram very clean.