I was wondering how I can add a delay or wait within a formular node? I was thinking to use a value which is pushed out of the formular node and use a standard wait LV function. But it would be nice to do within the formular node itself.
But I do you want to put a wait in a formula node to begin with? Formula nodes are designed for calculations that you'd normally want to execute as quickly as possible, but to use formulas that may be better written in a text based language rather than using native LabVIEW functions. I can't see a logical reason you'd want to pause in the middle of a calculation. ("Okay, I want to add 2 + 3, now I want to wait 5 seconds, okay now I want to multiply by 4.)
If you can tell us what you are trying to that requires a wait in the middle of it, we can probably figure out a better way to accomplish it.
The reason is because the formular node uses C type syntax which is just good enough to use it as a test to comms parser. However I was wanting to add some delays between the message creations and writing. I can of course specify these with an external timer and the formular node just generates the timer value. I could also just generate all the needed messages and buffer them in a prespecified order with the delays between the messages.
I know its possible to code raw "C" and use it with Labview some how, this maybe be a better option?!
So basically you're trying to use LabVIEW to write C code. What's the point? That's like asking how to use C# to write Java code.
LabVIEW has serial comm functions in VISA that work just as well as C code. I'd argue they're actually easier to use. If you can provide some more details on what you're trying to test and the basic process we can give you a pretty good idea of how to do it cleanly in LabVIEW.
To answer your question regarding "raw" C, there is no "C" script node. You'd have to compile the C code into a DLL and call the DLL from LabVIEW.
Yes I agree it seems a pointless exercise. Its all doing with resouce management. Too much work which needs to be split. I think the idea was to stay within Labview but somehow code the parser in C, using another person.
We basically have around 60 parameters that will be used to derived 3 sets of SPI messages (3 ports). Most of the parameters are either enabled or not with some floating point values. From my initial check of what needs to be done it looked easier in C than coding it it as a Labview design.
I think it would be faster and more reliable to simply write the parser in LabVIEW if you are going to use it. You are trying to do some very odd combinations that I think will bite you in the butt in the long run. Fromwhat you sescribed it sounds like it would be a fairly easy parser to write. Your approach seems like you want to drive nails with a screwdriver.
Mark Yedinak Certified LabVIEW Architect LabVIEW Champion
"Does anyone know where the love of God goes when the waves turn the minutes to hours?" Wreck of the Edmund Fitzgerald - Gordon Lightfoot
Yes I agree it seems a pointless exercise. Its all doing with resouce management. Too much work which needs to be split. I think the idea was to stay within Labview but somehow code the parser in C, using another person.
We basically have around 60 parameters that will be used to derived 3 sets of SPI messages (3 ports). Most of the parameters are either enabled or not with some floating point values. From my initial check of what needs to be done it looked easier in C than coding it it as a Labview design.
Most people starting out in LabVIEW think this primarily because they don't know about the functions. If you can provide some details as to what this parsing basically looks like then we can suggest how to to it in LabVIEW efficiently.
