LabVIEW Statechart unusably slow

[dxydas]

Hi,

I am recently having issues with the time it takes to save as well as compile a state machine created with the Statechart module (ver. 2015). Saving the statechart takes a good 20-30 mins, while compiling uses over a gigabyte of RAM and takes ages to complete.

I am wondering if this is because I have hit some limit on how complex it can be, or if there is some underlying issue/bug. The state machine is fairly complex, with probably ~60-70 states, and calls to various sub-VIS, but nothing that would be considered extreme. The .lvsc file itself is 10MB.

The only relevant search hit I have found on the forums is this one, however my statechart does not point to a missing LV file, the project has no dependency problems, and I can compile and run VIs which start the statechart (synchronous). It simply takes an extremely long time to save. Early on in the project, when the statechart was not so large, it would save much faster.

Note that the save time for other individual sub-VIs in the project is perfectly normal. This only happens if I try to save/re-compile the statechart, or save the containing project file.

Does anyone have any knowledge on this?

[Ben]

No personally but in general...

Can you edit the State Chart with the project closed?

Do you have auto-populating folders turned on?

Ben

[dxydas]

Hi Ben,

Thank you for the quick reply.

I can open the statechart file directly outside of the project.

If I open the statechart file directly, and then close it without making any changes, I will still be prompted to save, and if I save again it takes an equally long amount of time to finish saving.

As for auto-populating folders, yes they are turned on. I disabled them but it doesn't seem to speed things up.

As a side-note, I notice the occasional messages referencing VIs with long numerical values such as this, when the project is loading:

I am not sure if these are problematic VIs, or some internal implementation that the Statechart module uses, but either way I cannot see these files anywhere on disk.

The only file visible on disk is the .lvsc file.

[dxydas]

Hi Ben,

Thank you for the quick reply.

I can open the statechart file directly outside of the project.

If I open the statechart file directly, and then close it without making any changes, I will still be prompted to save, and if I save again it takes an equally long amount of time to finish saving.

As for auto-populating folders, yes they are turned on. I disabled them but it doesn't seem to speed things up.

As a side-note, I notice the occasional messages referencing VIs with long numerical values such as this, when the project is loading:

I am not sure if these are problematic VIs, or some internal implementation that the Statechart module uses, but either way I cannot see these files anywhere on disk.

The only file visible on disk is the .lvsc file.

[dxydas]

I tried another test whereby I made a copy of the entire project, stopped folders from auto-populating, deleted about 90% of the statechart (even deleting took its toll on my PC), and the project is back to behaving as usual, i.e. reasonable load/save times, low memory usage.

I think the way forward might be to break the one large statechart into multiple small ones, and have states in one statechart call other statecharts where needed, instead of using sub-diagrams.

By the way, my PC is an i3 with 8GB RAM, although I will eventually deploy these statecharts on a cRIO 9038, so I hope it will be able to cope!

[RichardInfinite]

Have you tried playing around with some Statechart Code Generation settings (right click statechart.lvsc -> properties)?

Disabling debugging will help, and then you can play around with Vi settings. 

Inline subvi's will "improve performance but increase memory footprint".

I haven't tested these myself but it might help loading/saving of the statechart. 

http://digital.ni.com/public.nsf/allkb/a2e77b505f0ebb3986258094003c53dc/$FILE/readme_Statechart.html

Good luck!

[dxydas]

Hi there,

Thank you for your feedback.

State machine debugging was already disabled. I tried also disabling inline settings, but I'm afraid it did not make any difference to statechart code generation and saving (actually loading is not a problem). I have also noticed that editing state actions or triggers is also particularly slow, for example it often takes 5-10 seconds to open/close the configuration window.

Why oh why are these weird configuration windows used in Statechart?

Not only are they un-resizable and slow, but very prone to crashing LabVIEW entirely (e.g. if the Esc key is pressed at certain configurations), with no way of recovery. This, combined with the slow saving time, means a trade-off between either waiting ages while regularly saving, or risking a crash while working on a statechart.

[RichardInfinite]

There's another great way to crash it if you click on edge of a wire to branch, right click to cancel, then try and wire again quickly.

One thing we have found recently is the triggers enum of the statechart. It's not a true enum as you edit it from a dialogue box not a .ctl 

But if you create a new project and have just the trigger in it it'll load in everything that has any relation to the statechart in anyway in memory - not as a dependency!

If you load the statechart it will load it's vi's, that may call a trigger, that will call the statechart that will.... Circular loading dependency.

We've had great success making a duplicate trigger enum.ctl and using that if we ever need to call a trigger in a vi. Then cooercing it to the statechart trigger just before running it. This has helped our overall project loading times a great deal, but couldn't tell you if it has directly helped the statechart loading. 

[dxydas]

Hi,

Your comment on the crashing is indeed a very annoying part of the Statechart. In a similar way, if you press Esc to cancel a wire routing, the window gets highlighted with a dotted line. If you then dare to accidentally click-drag, LabVIEW will crash and all changes in the Statechartwill be lost and unrecoverable! This also occasionally happens when undoing/redoing, although it's not repeatable.

Thanks for your comment on the triggers. Unfortunately in my project I am using triggers very sparingly, if at all, as all transitions happen with guards; they heavily rely on tags set by the LabVIEW CVT, which is very useful. I have definitely noticed that slowdown is related to Statechart complexity - the less states/guards/actions implemented, the faster at saving/editing it is.

My previous approach of calling one Statechart inside the static reaction of another was a bad idea, for the fact that when the reaction exits, of course the other Statechart stops running, hence all its exit actions don't get executed.

My current fix is must simpler: one VI runs all synchronous Statecharts necessary in individual loops. The loops of lower-level charts are paused/resumed based on tags set by higher-level charts. Lower-level charts also have a guard on exit, which can also be triggered by tags set by higher-level charts. The only complexity is that you have to check for tag high->low and low->high transitions. Example implementation attached for anyone that might find it useful.