LabVIEW
fgv with two types of variables
Solved!
The code by aputman is not good, because it is not predictable. It is a bad idea to change global functionality on first call. What if the first call is a "set" operation? The first array element would be lost forever and the calling code would not know about it.
All the "first call?" primitive needs to do is initialize on first call, then proceed with the requested operation (set or get)!
I would also recommend to output the appended array even during the "set" operation. Sometimes you want the new data immediately and this eliminates a second call.
As I already mentioned, a globally initialized shift register is the better choice here, because it includes the "first call?" functionality as well as eliminating the while loop, thus dramatically simplifying the code (bottom in image).
Anyway, attached are two possible implementations. Modify as needed.
abenigma wrote:
please bother to read the entire message and not just take a look at the picture.
OK, I haven't read your post here until now, but it deserves some comments. At this stage of your learning curved it is ill advised to play the smart a$$. It looks silly, especially if you re-read your comments a few months from now once you have more experience. 😮
abenigma wrote:as i already wrote, this will be a subVI and i need the boolean value to be read every time (the boolean itself isn't "near" and it doesn't look good if i wire it directly, i might be wrong, but this is the way i want it for now).
In a few months your aesthetic values will hopefully change and using a control reference in this way will look far worse to you. On a properly modularized and architected diagram, nothing is "not near". If things are far apart, your diagram is too big. First of all, property nodes execute synchronously, and are thus orders of magnitude more expensive. Some property nodes force the front panel to be loaded in memory, adding additional strain to the system. You also open yourself up to race conditions, for example what would happen if the boolean changes right after you call the subVI, but before the property is read? Also, using control reference this way prevents you from running the subVI standalone for debugging purposes, something you should definitely be able to do at this stage.
abenigma wrote:i know that the shift register needs to be uninitialized, that's what i wrote, i also wrote that if i disconnect, the wired become black (which is to my understanding means that labview doesn't recognize the data type of the wire).
Well, if you "know" that something is not right, but then attach a picture that shows the wrong thing, you are sending mixed messages. In fact in my first reply I suggested to use a globally initialized feedback node to exactly mitigate that problem. For some reason you ignored my advice. Let me use your words: "please bother to read the entire message". 😉
abenigma wrote:p.s. if i initialize inside (3rd state), from the way i understand, i would have leading zeros in my data arrays which i definitelly don't want/need.
Obviously, you understand wrong. If you look at the arrays, you notice that the first element is greyed out, meaning the the arrays in the diagram constant are empty. I recommend that you go over some of the online tutorials to become more familiar with LabVIEW in general before attempting any more complicated project.
@abenigma wrote:
P.S.. After taking a good hard look at the FB node (which looks much less cumbersome BTW), I imagine that it work in pretty much the same way as a shift register? (in terms of data being transferred between two calls of a loop?)
Yes, a feedback node works pretty much the same, but is a more recent addition to LabVIEW and in cases like this, much more elegant. Here it is globally initialized, a functionality that does not exist for shift registers (which always require a loop, even if it does not iterate as in this case).
A feedback node can be configured to give one earlier history value (n-1, n-2, etc.), but a shift register can be resized to give multiple histories at once.
It ia great to have both!
(While you are at it, you should also remove the "accepted solution" tag from this post, because the solution is wrong as already explained. Future users of the forum should be guided to the correct solution instead)
@abenigma wrote:
will I be able to dynamically set how many last/previous values I would like to read? (that would reduce a whole procedure from one of the uses for this FGV).
You can add another control for "output size" and insert an array subset right before the output terminal. You need to calculate the start index from the current array size in the feedback node and the value of the "output size" input. SImple math! 😉
Also be aware that the current FGV memory use grows without bounds and you computer will run out of memory eventually (depending of the set rate). If you want to keep a fixed sized history only (e.g. the last 1000 points), you can implement it as a fixed size history buffer that will be much more memory efficient and elegant.
abenigma wrote:also i can't find part of the elements you used in your diagram (understanding how little we were explained in everything related i am trying to read about what i'm using as much as possible).
Well, it is difficult to tell when you are not telling us what elements you could not find. I assume the in place element structure.
Take advatage of labels and add descriptive labels immediately after adding any control or indicator (numeric, boolean, numeric 2 and enum are too generic to be useful) Also make sure to label the elements of the cluster constant so you can use bundle/unbundle by name for self-documenting code.
Here's what I would do (see attached).
- Remember, you need to handle the situation where more data is requested than currently available, for example.
- As I already mentioned, I really recommend wiring the array output also in the "set" case. It makes the code more useful.
- Also note that you don't need to wire the size input of "array subset" if you want all data from the index to the end. Less code means less places for bugs to hide. 😉
@abenigma wrote:
btw, not wanting to be a smart a$$ (again), but you wired the index without a decrement, was that an honest mistake or am i getting something wrong? (the way i understood indexes in labview is that they start at 0 but an array of size 3 would have last element with an index of 2, is that correct?)
Well, instead of straining the brain and overthinking things, just do the experiment as in the attached example!
You will see that my code behaves correctly. Agree?
