LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Symbolic variables in formula parsing VIs very limited

Solved!
Go to solution

I'm trying to use symbolic variables in formula strings in the ODE solver VI.  I want to simulate a long cascade of electrical components and solve the differential equations respecting their voltages and currents.  However I finally figured out why the ODE solver VI was giving me errors (thankfully I was able to open up the ODE solver VI and get some clues as to what was going on in the spaghetti code inside!).  I'll make another post to document those error codes and their meaning in another post for posterity, since it's not documented anywhere else (?!?).

 

I was getting an error because I tried to use a variable named "v10".  As documented in the help page on "Formula Parsing VI variables" (https://zone.ni.com/reference/en-XX/help/371361R-01/gmath/variables/), variables can only have a very VERY limited set of names, either a single lowercase letter (excluding the letter 'e'), or a single letter (except 'e') with a single digit.  That means there is a maximum of (letters in the alphabet - 'e') * (number of single digit characters or no digit) = (25) * (11) = 275 possible variable names. 

 

While I guess most people don't need more than 275 symbolic variables, if you need more than 10 you quickly run out of logical, clear variable names.  Yes I realize that trying to solve a system of differential equations with more than 275 variables is not a common use case and might take a very long time to finish, but that's not my point (plus ODE solvers are not the only use for these symbolic variables).  Why, when using a modern, high-level programming language in the year 2020, can I not use a variable with a convenient name?  And as many of them as memory will allow?  This seems like an embarrassing limitation to me.

 

I realize that I could make a script that generates a VI with all the variables and math that I need and use that VI reference with the "ODE Solver main" instance, in which case it seems I might not run into this limitation (haven't verified it 100% yet though), but that seems like a silly amount of work for something that I could easily do in any other modern programming language.

 

How hard is it to upgrade the formula parsing in these VIs?

0 Kudos
Message 1 of 4
(2,340 Views)
Solution
Accepted by topic author fffrune

Formula models are clumsy and parsing is also very slow in execution. Expanding the variables will not change that. I strongly recommend using the VI model instead? Why do you think that's more difficult?

Message 2 of 4
(2,336 Views)

I am wanting to make an arbitrarily long cascade of electrical components, meaning an arbitrarily long set of functions and variables.  I was thinking that I would have to make a script to generate all that arbitrary amount of code programmatically, however now that you made me consider it again, I suppose that those input variables and output differential equations are just arrays (of arbitrary lengths), and the input data (variant) could also be of arbitrary length...so if I am allowed to use a for loop in that ODE F(X,t) VI reference then maybe this could work.

 

The simple examples are just that--simple--so I didn't initially consider this extended capability.  It's definitely worth a try.

 

I'm still going to complain about the limited support for symbolic variables though! 🙂

Message 3 of 4
(2,320 Views)

I've tested my new ODE solver to my satisfaction, using the VI model is working great.  Thanks for your suggestion!

Message 4 of 4
(2,211 Views)