LabVIEW
VI of the Day (11/4/2009) - Formula Node
OK, I'll admit that on occasion I am a proponent of the "Formula Node", especially when trying to test complicated fit functions and derivatives. There is no denying that certain formulas are faster entered by keyboard than by mouse. But, at the end of the day, I still convert to G, I wish there was a way to have the speed of text formula entry, with the beauty of G code.
Enter LV scripting, when I first tried this for my Code Snippet experiments, I said that I would never use it to write LV code, but I was a filthy liar. Turns out, I had forgotten the key element, "Block Diagram Cleanup". If you think it gets a bad rap, just try to figure out programmatically how to place objects. With scripting, I can dump everything in one spot, and do a cleanup at the end.
Now for the code for the day, this is an alpha version of some code I threw together to let me enter a formula and get the corresponding G code. I am still cleaning the code (this version is password protected), but give it a try and let me know if you like it, and more importantly, find any bugs. A few kinks I know of, but I am trying to avoid proliferating special cases until the core works well. No For Loop support (yet), but I don't want to create a text language, just solve a specific problem. Just enter the formula, run the VI, and you either have a new VI or G code in the clipboard ready to be pasted.
If enough people are interested, I'll clean up the worst offenders in the code and post an open version here as soon as I can. This version is 9.0, a few changes between versions rendered the 8.6 version a little buggy, and 8.2 will not be happening since there is no BD cleanup. The code dropping works, but trying to untangle the mess is a little difficult.
I hope it is useful, it is still fun to see the action as the VI is being built. On the docket for improvements (suggestions welcome), are 8.6 support, For Loops, Snippet creation, Fit Function/Root finding function auto-build, array support and better UI.
OK Formula Node, send not to know for whom the bell tolls, it tolls for thee.....
VIOTD groundrules here.
First of all, I'm impressed by what you've done, even though I can't see it in action (8.6er).
Darin.K wrote:OK, I'll admit that on occasion I am a proponent of the "Formula Node", especially when trying to test complicated fit functions and derivatives. There is no denying that certain formulas are faster entered by keyboard than by mouse. But, at the end of the day, I still convert to G, I wish there was a way to have the speed of text formula entry, with the beauty of G code.
By "speed of text formula entry", I assume you mean the actual amount of time it takes to write the code, rather than execution time, correct? In my experience the Formula Node executes about 4-5 times faster than the corresponding G code.
Yesterday I decided to test which was faster with a long complicated formula I had worked on. I ran the formula 16M times and took the average time of 100 of these tests. The formula node averaged 264ms whereas the G code was at 1111.84ms. This isn't a huge increase, but it's something
This was the formula
elset191 wrote:Yesterday I decided to test which was faster with a long complicated formula I had worked on. I ran the formula 16M times and took the average time of 100 of these tests. The formula node averaged 264ms whereas the G code was at 1111.84ms.
Would you mind posting the benchmark VI?
Yes, formula nodes are often quite fast, but I just don't like text code ;).
- You also cannot really "probe" inside a formula node for debugging. Did you disable debugging on the G code for a more fair comparison?
- Did you loop inside the formula node or did you place the formula node inside a FOR loop for the 16M iterations?
- Was the G-code inside a FOR loop operating purely on scalars or did you use "thick" wires somewhere?
- Was the g-code optimal?
- Did you try the parallel FOR loop?
- Was there any constant folding?
Just curious... 🙂
Hi Tim,
atleast one "Sin&Cos" is unneccessary (aka duplicate) in your formula - as it's one of the slower functions your implementation is not "perfect" 
Maybe LabVIEW is clever enough to optimize while compilation...
GerdW wrote:Hi Tim,
atleast one "Sin&Cos" is unneccessary (aka duplicate) in your formula - as it's one of the slower functions your implementation is not "perfect"
Maybe LabVIEW is clever enough to optimize while compilation...
Hmm, you're right. It's been fixed. Any idea if that is significantly slower than doing sin and cos separately? That's how it was when I received the VI, but I changed it because it looks nicer.
EDIT: It's not faster to split them
