LabVIEW
Filter signal problem
You are using Insert Into Array to insert at the beginning. Then proceeding to take the beginning of the array and cutting off the end.
First, there is no reason to use Insert Into Array which is the wrong function to use about 95% of the time. When you want to put an element at either the beginning or the end, use Build Array. Much simpler.
But by putting it at the beginning, you are building your array in reverse. It is much more logical to put new data at the end of the array. Plus I think you'd want filter to work on the array working forwards rather than backwards.
@RavensFan wrote:You are using Insert Into Array to insert at the beginning. Then proceeding to take the beginning of the array and cutting off the end.
First, there is no reason to use Insert Into Array which is the wrong function to use about 95% of the time. When you want to put an element at either the beginning or the end, use Build Array. Much simpler.
But by putting it at the beginning, you are building your array in reverse. It is much more logical to put new data at the end of the array. Plus I think you'd want filter to work on the array working forwards rather than backwards.
Thank you for hint,
But I think here is better solution: array is created on each iteration, but only 1 element is delated (instead of 100 as in your example).
The only "obscure" detail - the staircase step is about 75ms instead of 100ms as imposed by lower loop delay (please, see the screenshot below).
Any ideas ?
That way works. Delete from Array provides two outputs. One is the deleted part, the other is the array that is left after the part marked for deletion is removed. So changing the inputs and using the other output gives the same result.
Delete from Array can be tricky because you can put in special constants to expand its capabilities such as a negative index or negative length. Leaving one input, or the other, or both unwired can give different results even from if you just wired up whatever the default input would be. So those things combined with looking at the function from the opposite direction (i.e. "delete" what you actually are looking to keep) can be more powerful than looking at it straight up with positive values. For me, I can't ever use it without experimenting to make sure it is giving me exactly what I want.
As for your graph, when I ran your VI by draggin and dropping the snippet to a new block diagram, the steps occurred 100 apart, not the 75 you are showing. Double check the properties of the graph. Maybe you have a dT value set in there that is different from default. That when I copied in the snippet, it may have just created a "default" waveform graph.
I didn't find any dT option. Where is it ?
Another question - filtered signal doesn't evolve as original signal: original signal "floats" from right to left, whereas filtered has left end always attached to origin (please, see screenshot below)
Do you have the same behavior on your VI ?
Mine still looks like 100. Try attaching your VI instead of a snippet so I can be sure I'm running the exact same thing as you are.
The property I am talking about is actually called offset & multiplier. Part of the X-axis properties.
I didn't know there was a second plot. The visibility was turned off. But yes, it starts at 0. That's because the filter inherently starts from a zero condition. You need it to remember the last state so the new iterations through the filter will be based on the previous iteration. Wire a True constant into Init/Cont input so that it maintains that state. (The default is False or Init which re-initializes that filter on every call.)
