Trouble upgrading statecharts from 8.5 to 8.6

[Matt_W1]

I'm attempting to upgrade a fairly large project to 8.6 from 8.5. Two of Three statecharts have code generation errors for their xnodes (I can regen code fine in the diagram editor though). But I haven't done any heavy debugging yet. I suspect it might have something to do with the the two statecharts having a class in their inputs. I was wondering if anyone has had a simuliar experience before I spend a lot of time trying to hunt down the problem.

I got an earlier version of this code to work on the first public 8.6 beta, if that's helpful. I also attached a log from opening the 8.5 project and mass compiling it. I suspect that the xstuffprivate.cpp(2494) part is the problem.

[Matt_W1]

I've made a example project that shows the problem (see attached). The problem seems to show up when you have both a variant and labview class in the inputs of a statechart. If you remove either from the posted example and force code generation for the diagram (even though it doesn't think it's needed). Then the node for the statechart in test.vi will become executable. I'm going to try to find a work around. but if anyone has a sugestion on how to fix or work around this issue that would be helpful.

Message Edited by Matt W on 09-17-2008 02:40 PM

[Matt_W1]

The only work around I've found so far is to wrap all of the statechart inputs into a single class, and unwrap them when I need the inputs in the statechart diagram.

[aggieNick02]

We've reproduced the issue and are actively investigating. Thanks much for posting the example showing the problem. I'll keep you posted with respect to info and possible other workarounds. We have created CAR# 126856 to track the issue.

Thanks,
Nick

[Matt_W1]

It affects outputs as well as inputs, probably statedata as well. Wrapping everything in classes is looking to be a bit tedious in my large project. So hopefully a better fix comes around before I run out of other things to work on.

[Matt_W1]

I've gotten it to fail now with only one LabVIEW object, and no variant so I'm not sure if my work around will be workable for me now.

[aggieNick02]

Thanks for the updates.

It affects inputs and outputs, but not state data. The "difference" is a problem when the terminals of the run statechart node contain classes.

You will get the error if either of the following are true about your Inputs.ctl (or Outputs.ctl):

1. You use the base LV object (the one you find in the palettes), or
2. You use any class AND a variant

This means if you can find a way to easily stop using a variant and use some class besides the base LV Object class, you can workaround this problem. Let me know if this seems workable. You might need to create an artificial parent class for all of your classes (so that you can use this parent class instead of the base LV Object class).

Sorry for the problem. We can try to think of some more workarounds if this one is not viable for you (I know you would like to perform this upgrade without having to rework much of your app.)

Message Edited by aggieNick02 on 09-17-2008 06:02 PM

Message Edited by aggieNick02 on 09-17-2008 06:04 PM

[Matt_W1]

I don't use the base LV object in my main app, so that's not a concern. The variants can't be removed, but wrapping them their own class may be doable. Since they're only passed around in all but a few functions and are already in their own type def. So I'll see how nasty that'll be, it'll at least won't look like a kludge like my last work around. I'll reply if I that turns out to be too much trouble, or an inadequate fix.

[Matt_W1]

Wrapping the variants in a classes seems to have solved the problem. Hopefully I wont find any other bugs.

[aggieNick02]

Glad that you were able to workaround the issue without extensive recoding... we will be sure to publicize this as a known issue and give the CAR the attention it deserves.

Thanks again,
Nick