Hi,I’m a new programmer and I was following a tutorial and it kept using a certain vi,but i couldn’t recognize it or find it in the tool pallet.Can someone tell me what it is and where to find it
Feedback node. Located in the Programming -> Structures pallet.
That is called a feed back node. It stores the last value fed in so that you can compare a variable or value to itself. It is found in the Structures pallet towards the bottom right.
Thank You
Oh one more.Sorry for the nuisance
No need, that’s why we’re all here; to help.
That is a Boolean> True/False. Depending on which letter, T or F, has green behind it tells you which is running. (i.e. Green-background T means it’s running True).
The feedback node is found in the Structures palette. It points from right to left by default. The diamond underneath it is how older versions of LabVIEW marked the initializer terminal; this year it looks like an asterisk which becomes a cursive i when wired.
The green T/F is a Boolean constant from an older version of LabVIEW. It would alternately highlight the T and the F when clicked on. LabVIEW 2012 instead displays it as a single square with either a T or an F in it. You’ll find the T and F constants in the Boolean function palette.
Now I’m trying to insert a process much like this which will set a servo to 90 activate a relay forward and then set both of them back to their natural position
but it seems to be running too fast and starving the drive system any pointers
http://team358.org/files/programming/ControlSystem2009-/LabVIEW/ButtonTimedAction.jpg
Unless we see what you’re actually doing, we won’t be able to give much in the way of help. Show us your code, not the example you’re emulating.
If you place the code into teleop, it will prevent teleop from running frequently enough. Try moving it to Periodic tasks.
Greg McKaskle
I can’t be the only LabVIEW developer that despises the use of the feedback node, can I? IMO, while feedback nodes can make a diagram cleaner, they actually make it harder to understand, as compared to using the equivalent shift register.
I attempted this and it still says it is starving the drive loop
You can attach your vi’s directly to a post.
Show us your Teleop.vi & Periodic.vi, and any other vi you might have added code to.
The code you posted looks fine as long as it’s in Periodic Tasks.vi (it would not work in Teleop).
I can’t be the only …
I also learned LV long before there were shift registers and in many ways prefer them, but I now use both, typically for different things. I really like the compare to last with a shift register, but otherwise typically use shift registers.
Greg McKaskle
I almost never use feedback nodes, but I find myself using feed forward nodes quite frequently. They make more sense to me because the flow of the code keeps moving forward. If I’m in a loop, though, I’ll always use shift registers.
Here are my tele op and periodic vis neither has much extra really
Teleop.vi (25.9 KB)
Periodic Tasks.vi (31.1 KB)
Teleop.vi (25.9 KB)
Periodic Tasks.vi (31.1 KB)
I looked at the code and I don’t see anything wrong with it.
Basically, the starvation occurs if you don’t call the Arcade Drive VI every 100ms. Having the VIs open (front panel or block diagram) can cause this. Try closing a few windows and see if that helps.
Seeing the starvation message is completely normal on non-built code (not saying it’s good though). If you see it all the time after you build and deploy your code, then you have an issue.
Even with the message, can you drive the robot around? Do you notice it?
@Greg McKaskle: I really like several of the changes that have come about since the birth of the idea exchange a couple years ago. Things like shrinking the boolean constant, changes to local variable graphics, integrated labels for structures, better alignment of vi.lib vi’s I/O and so on.
For my non-FRC applications, I REALLY like the JKI string-based state machine template.
Is “feedforward node” generally accepted terminology for a feedback node that simply has the arrow direction changed to make the wiring cleaner? If so, it seems unfortunate. The function of the node remains the same regardless of arrow direction.