Statechart: state editing is extremely slow when used with labview classes

[dlanger]

I would like to use the statechart module in combination with labview classes (i.e., object-oriented programming).I have about 25 classes, which are heavily dependent on each other (via inheritance and because some classes have other classes as attributes).

The problem is now, that when I have an object of such a class as an input to a statechart, state editing gets unbearably slow. It takes more than 60 seconds to open a state configuration dialog and about the same time to save it again. I suspect that everytime I try to open a state for configuration, the whole class hierarchy is somehow loaded or processes.

Is there any way to avoid these long loading times? Further, I hope that NI tries to fix this problem for the next version of Statechart Module...

[aggieNick02]

There is one known thing that makes the state configuration dialog "unbearably slow" to open. If something in your guard/action code, or in your statechart typedefs, points to a missing LV file, this can occur. The way the configuration dialog is implemented can cause us to re-search for each missing thing for each guard/action when you open the config dialog. If you start LV and just open the statechart, does LV search for anything? If so, this is likely the cause.

If this is not the cause, some more detail would be very helpful (and if you can actually post or send the files you are working on, the turnaround/resolution is generally much quicker). If posting or sending the files is an option, please let me know. If you prefer not to post them publicly we can arrange to exchange them another way.

Thanks,
Nick

[dlanger]

Hi Nick

Thank you very much for your reply.

When I start LV and just open the statechart (and not the whole project containing the statechart) the loading dialog indicates that a number of files are loaded. But LV is not searching for any files it can't find.

I have now tried the following: instead of feeding objects of my classes into the statechart via the input cluster, I retrieve them inside the statechart actions from global variables and write them back to global variables after manipulation. Like this, opening the state configuration dialog is fast, but saving changes to state still takes a long time. Still, that is much more acceptable than waiting in both cases. However, I would prefer using the input cluster if that can be made faster somehow.

I can send you my files, but not publicly. How can we exchange them?

Best regards,

Dominik

[aggieNick02]

Hi Dominik,

Our statechart product support engineer (PSE) will post shortly on how we can get these files exchanged. Thanks much for your help with that.

The situation you are describing is odd so it will be interesting to see what is causing such a difference between when the class is in the cluster and when it is in a global.

Thanks,
Nick

[Angela M]

Hello dlanger,

There are a few different options for exchanging files.  If you feel comfortable posting your email, then we can contact you via email and work out some sort of file transfer.

The other option would be to open a service request with us.  You can start an email service request from the following website: Request Support.  This method does require having a service contract with us, but we can give you more direct support.  Just reference this discussion forum in the email and we will be able to find it.

Another option would be if you have any sort of example code that you could make public that reproduces the behavior, we can work with that.

Please let us know if you have any additional questions about this.

Regards,

Angela M
Product Support Engineer

[JKSH]

Hello,

I was wondering if this issue has been fixed in LabVIEW 2012? I'm considering using LVOOP objects as inputs/outputs to statecharts (although unlike the original author, I'll probably only have 1 object input per statechart, and its children won't have complex interdependencies)