upgrade Mathscript LabVIEW 2009

[Beetho]

Hello

I have developped an application in LabVIEW 8.6 that contains a large MathScript node. it's time to upgrade to LabVIEW 2009 and i am facing problems in that. I have the Mathscript RT Module installed and activated on my computer.

I should emphasize that the application works perfectly in 8.6. After the first execution in 2009 version, i got 2 run-time errors: 

 -90031 : "unknown output variable". The variable is of string type. it's pointed in a red dot (see picture). I have never seen that red dot before...

another error in another node: -20104:  input parameter have at least one NaN element. What's a NaN element? this error occurs in a line that looks like A=median(B) where B is a row vector.

also in this second node, i have a lot of output variables pointed in red dots, the string outputs and some of the double precision as well.

What are the requirements to upgrade to LabVIEW 2009, as far as MathScript is concerned? are there issues to be considered? major changes i should be aware of?

Thank you very much

Sam 

[jattas]

Hi Sam,

There have been some significant changes to MathScript between LabVIEW 8.6 and LabVIEW 2009 both under the hood and in some of the visible features of the MathScript Node. However, these changes should not have broken your code. We'll have to do some investigation to see what is going wrong.

First, I'll explain one of the new features that you've noticed: the red dots that can appear on outputs of the MathScript Node. These are coercion dots which indicate that LabVIEW is converting from one data type to another at this output. They mean that inside the MathScript Node, your variable is represented as a different type than the one that you've selected for the output. You can see which type by hovering over the variable anywhere in your script and then looking at the context help window. These dots didn't appear in 8.6 or earlier because MathScript didn't have any concept of strict types until 2009. The dots are something to be aware of, but don't necessarily indicate problems with your code.

The -90031: "unknown output variable" error that you're seeing typically appears if the output variable is defined somewhere within your script that didn't get executed when you ran your VI. Is it possible that this is happening in your case?

The -20104: "NaN" error occurs when one of the values being passed to median in your B vector is "Not a Number". These NaN values typically occur as the result of invalid floating point operations like 0/0 or Inf*0. We'd have to look upstream to the point that B is defined to see where this NaN value is being generated.

Hopefully this information will get you further along to finding the source of these errors. If you're still seeing problems, feel free to post some of your code for us to take a closer look.

Thanks,

jattas

LabVIEW MathScript R&D

[Beetho]

Thanks Jattas

i am still confused about the coercion dots but since they don't necessarily indicate problems with the code, i'll keep the focus on something else to begin with. i beleive i should look for solutions for the whole upgrade. What i did not mention in the first post (because not sure if related to Mathscript) is the error messages i have on saving the VI before quitting, i also got those messages while loading the VI.

Attached are 3 messages that appeared (Please see pics). The result is obviously a borken arrow:VI failed to complie, Mathscript node failed to compile.
that would be a nice discussion with NI support but it's hard to explain these things on the phone. i am gathering every information that might be relevent for the migration.

thanks again

[jattas]

Hello again Sam,

The errors you posted indicate that something has gone pretty seriously wrong with the LabVIEW compiler. Unfortunately there's not much I can do to debug the issue without seeing your code. If you are able to post your VI here then I could take a look. If you'd prefer not to post it publicly, you could call NI support and share your code with them. If you point them to this discussion thread then you shouldn't have to explain too much; they will quickly escalate the issue to us in R&D. If neither of these options works for you, can you share a simplified version of your code that still reproduces the errors?

Hopefully we can get to the bottom of this quickly.

Thanks,

jattas

[kmcdevitt]

Beetho,

Make sure your MathScript is actually activated!

Apparently ownership of MathScript is confiscated when you upgrade from LabVIEW 8.6 to LabVIEW 2009.

I know this is for sure the case if your acquired MathScript as part of NI Developer Suite.

Does not matter if you were and still are on current SSP.

You may need to purchase MathScript again.

You should be able to check if this is what happened to you.

Verify that your MathScript is activated.

Kevin. 

[Beetho]

After communication with the NI Support, here's some facts and solutions:  

For error run-time error -90031 reported, the issue is if a MathScript Node
has an output that is doesn't get defined when you run your script you get
this error. This was not the behavior in LabVIEW 8.6, which was that the
undefined output would return default data for the output and report no
error. You current work around is to

a) split the MathScript node into multiple MathScript nodes and move the
"if" statements outside of MathScript and into LV case structures. That way
each MathScript node always computes each variable.
b) define default values for these variables at the top of the script

It is true that there are outputs in the Mathscript node that does not get defined on every loop iteration and this is made on purpose. In the current version (LV 8.6) to prevent these outputs from returning back to default, i use shift registers, so if some output doesn t get defined, it preserves its last value, and this is exactly the behaviour i want to produce. For this reason, i cannot define default values for these variables on top of the script because i loose the last value. 

what i can think of - for those variables that does not get defined- is to define the outputs with the same variable name at the top of the script ( variableA=variableA) On the left of the = is the output and on the right it's the value that is saved in the shift register. I don't know if that works but i would try it before embarking on major reprogramming as suggested in solution a)

Other facts to be aware of 

1) replace instances of "variableName = [];" with "variableName = rand(0)".

2) place a semicolon after calls to user-defined .m files. These are the
function calls that appear in purple.

[jattas]

Hi Sam,

I worked with NI Support to look at the code you sent in and track down the issues that you were seeing. Your solution of passing previous values of variables into the MathScript Node using shift registers is a good one. Every variable that you do this to does not need to be initialized at the top of your script. However, there are a few variables that are not being passed in from a shift register. If you pass these in, it should get rid of error -90031 just as initializing them at the top of the script would.

Also, I'm not sure if your contact in NI Support mentioned this, but the two suggestions you posted at the end are workarounds for bugs in the LabVIEW 2009 MathScript compiler. I'm sorry that you had to be the one to help us discover them, but thank you nonetheless! The CAR IDs for these bugs are 189683 and 189851. If you check back when we release the next bug fix edition of LabVIEW (currently targeted to early 2010), hopefully these issues will have been addressed and the workarounds will no longer be necessary.

Please let me know if you still see problems after making these changes.

jattas

[Beetho]

Hi Jattas

i am a bit confused about initializing the variables on top of the Mathscrpit. my idea of passing previous values to input variables of Mathscript though shift registers is to avoid the default value of the Mathscript output, in case that output does not get defined somewhere in the Node. 

My question: is this solution still applicable in V2009 ? because what i understood from Joshua's reply is that in 2009, outputs should be defined in the Node in all cases, i assume that my first solution is not enough coz there are cases where the output is definded in a if statement that is false, for example...

Did NI wanted to avoid a bug or a logical error by not allowing outputs to be undefined and thus take back default values ?

[jattas · Accepted solution]

Hi Sam,

You can define variables either by wiring them in as inputs or by defining them within the script of the node.

So your solution is still applicable in 2009. In fact, it sounds like the correct solution to get the behavior that you're seeking. I think that the reason it isn't working is that there are still a few output variables which need to have your solution applied to them. These output variables are currently not being wired into the MathScript Node from shift registers and are only being defined in if statements that are false when your code runs. So if you wire these variables into the MathScript Node, the errors should go away and you will no longer see default values.

Initializing variables at the top of the MathScript is another way to get rid of the error. However, it sounds like this is not the best solution in your case because you want the variables to receive the same value that they had the previous time the MathScript Node executed. The best way to do that is with shift registered wired in as inputs to the node.

The reason for the change in behavior between 8.6 and 2009 is indeed to help users find bugs or logical errors with their code. The new behavior makes it less likely that code downstream from the MathScript node will try to use an output that has an invalid (default) value.

I hope this explanation makes things a bit clearer. 

Thanks,

jattas

[Beetho]

That's very clear

I could make it run without trouble

Thank you very much