CharlesB

Thanks for clarifying; performance isn't an issue for me, as it'll be used for configuration files loading, which happens at software start, so even if I get 1 or 2s hit it's OK.

You have to install it from VIPM (LV Tools Network), it's called "Class Retrieval". And it's indeed a NI package from Allen.

What's the path to the Class Retrieval library? I'd like to poke around and see what it can do!

It's in <vi.lib>/NI/Class Retrieval/.

Basically it is built around a FGV that holds a lookup table between class names and paths, and when ran from LV2013 it delegates this to the native VIs (that are password protected, since built into LabVIEW).

For pre-2013, if the class isn't found in the table, it asks uses LabVIEW's project introspection to find it, so your classes just have to live in the project. When ran from an executable, you have to preload your classes to fill the lookup table (there's a VI for that too).

OK I found NI's "Class retrieval" library that does the job, in the NI Tools Network, but the minimum requirement is LV 2012, though I'd need it for 2011

It could have been a matter of saving the library to LV2011, but there are password protected VIs like "2013 Get LV Class Default Value By Name.vi". This VI is precisely aimed at using builtin 2013 functionality when run from LV2013. For now I've came up with removing this code that uses 2013's bultin VI, and always use the pre-2013 workaround.

FWIW I need it for implementing class instance deserialization in the JSON API.

I'm looking for the pre-LV2013 version of this VI, that works from a FQN, does anyone have it?

I'm discovering this library, find it to be very mature, and the best replacement to the aging OpenG's variant config library, and more practical to use than AQ Character lineator, that requires to manually handle each field of your classes or clusters.

I'd have a suggestion to handle numbers with units: currently it's not recognized as such, and outputs the raw binary representation. I think it should at least issue an error, or represent the unit in the JSON string. I tried to look at what can be done for the latest case, but ran into two problems:

First, in order to serialize the unit you have to get a string representation of the unit (like "m.s^-1" for a speed number), which is quite difficult. You just get a cluster with base units and exponent, using vi.lib/Utility/VariantDataType/GetNumericInfo.vi. And also it's difficult, if not impossible, for the JSON representation to set the correct type back.

A solution can be to not output the unit string with number, and convert it to raw number in unit base, using the "Strip Units" VI from OpenG Data library. This is what variant config library does, in the  "SGL PQ".."EXT PQ" case of "Read key (variant).vi".

The other point I'd like to share is that I have some classes that I would like to serialize. Can we imagine the following thing, à la AQ Character lineator:

A class wants to be serializable, and thus defines methods "to data" and "from data", which take a variant as their respective input/output. Internally this variant would be a cluster representing private data. JSON API, when meeting a class instance, just needs to call the "to data" method VI and pass the resulting variant to "Variant to JSON", and serialize the real class name next to it.

On deserialization, JSON creates an instance from the real class name, and call its "from data" method VI.

This would require of course that these classes to inherit from a "serializable" class.

What do y'all think about this?

I'd like to add my vote for drjdpowell request, seeing all that all terminal labels moved when it's not the adopted style for labels creates kind of a mess on my diagram...

Also, I couldn't find source code, is it available?

I could find my way in the vi.lib/addons VIs, source is cristal clear so it was easy to find what to disable

Hi,

I'd like to add my vote for drjdpowell request, seeing all that all terminal labels moved when it's not the adopted style for labels creates kind of a mess on my diagram...

Also, I couldn't find source code, is it available?

Cheers,

Charles

I Found the relevant discussion for the "assign parent's data to a child" problem, which allows me to keep my design simple. Strategy pattern is a bit overkill here, and although Daklu's solution (manual copy of parent's private data) in this thread has its drawbacks, it's the simplest solution to me.

Making a new “MoveStrategy” class tree is my first thought also, but another possibility is to create a HysteresisCapableAxis child class that by default has a Move method that just calls the parent method, but that can also enable hysteresis (via some “Enable” boolean).  You can then enable or disable hysteresis without changing the class.

It's the pragmatic solution compared to a strategy pattern, but not satisfying from OO desing point of view. LabVIEW can be so frustrating some times...

I really wish I could create this child object from a base class. 

I'm designing a generic motion system, where an motion axis is an class, with Move/getPosition/Home etc.

I want to extend its behavior to handle backlash. It requires to extend the move method, so if I don't want to modify the original Axis class to keep it simple and generic, I make an HysteresisAxis class that overrides the Move method, in which correct move commands are issued to correct backlash. Fine.

But how do I extend it dynamically? Meaning that given an existing Axis object, I want to enable hysteresis handling by creating an HysteresisAxis object from it? Without manual copy of the private data fields?

My only answer is the decorator pattern: the HysteresisAxis actually holds the Axis in private data, and override home, getPosition, etc to invoke the Axis' method. The problem with it is that it requires to recreate all Axis methods as dumb methods that calls the decorated axis, which is a bit far from inheritance original idea...

Is there any way to clone an object into its child class, or some other solution to my problem

Thanks for your insights

Charles

This is the kind of code someone using icons ended up with... IUsually when someone uses icons they don't really know LabVIEW

Is that real code??

That's great news, "clear all errors" seems very useful for handling errors in cleanup VIs

I see that SF already has it, is it OK to download it from here?

My 2cts: the controls provided by the the "Missing" System Control Suite include system buttons with pictures.

It's very unlikely I will release this version as a package deployed to vi.lib. Doing so prevents customizing the existing state classes to meet the specific application requirements. It's possible to add plumbing that allows overridden core state classes to be used in place of the core state classes, but it adds complexity to the implementation (which is already difficult for many to understand) and I don't see much value in that feature. Putting the state machine template in vi.lib works best when you have many state machines across several projects with similar behavior. Single developers or small groups working in a relatively small domain are likely to be able to do that. As a developer creating code for other developers, I need to keep it as flexible and easy to use as possible.

At some point of the day I thought about asking user to give an intermediate base class that inherits SM's base class, but that's impossible and nobody will bother. We reach the limit of LabVIEW OO model (why don't we have template or duck-typing ?).

It's just like any other template code available in LV... except this template includes several classes the work together whereas most other templates fit on a single block diagram.

OK. I'm just not used to this paradigm (copy and paste) for giving librairies. Template updated? Download update and re-customize it....

IThe template doesn't prevent having multiple or nested state machines in an app. Just give each containing library a unique name.

True

Can you post it?

Attached.

II agree everyone tends to use their own messaging system. Unfortunately there isn't a clean way (I can think of right now) to allow users to inject an arbitrary messaging system without modifying the core code. The states *have* to get signals from external sources somehow, be it queues, notifiers, DVRs, etc. That said, I'm perfectly willing to discuss alternatives.

You mean something like interfaces ?

Seriously, I think it's better to ship code with standard queue (thus no shiny error cluster message), if users have their framework they can use it instead.

Also, IMHO the model you use in slave queue is a bit complex, maybe you can give people just an input queue to trigger state changes and they'll message what they want on output. In my case for example I already have Model VIs (in terms of MVC) that message the stuff out to View.

I'm no guru enough to make a nice stuff, and by short of time I think I'm gonna use the SimpleSM.vi you posted, which perfectly fit my need for a simple and clean SM. I'm frustrated by the nice stuff you can get on C#, but LabVIEW just can't enable us to build such a quick and clean thing.

Maybe a simple thing would be to provide the SM with a dictionary of state->trigger->next-state? Would be glad to help but sincerely out of time

LDSM.zip

Hi there,

It's great to have a simplified version of the object-based SM.

A few comments on the last version you posted:

- I would definitely go for a vi.lib version. Having to duplicate the SM base code is counter-intuitive and will keep people from using it. This is also useful if you want to have several SM in the application, or even nested SMs. The work required to switch to such a version is not difficult: I already done it, for now I'm passing the initial state as an argument to Execute.vi, and modified "create base state" to take as argument the state type you want to create.

- Binding the SM to a particular messaging framework is not great, also. Not that the lapdog one is bad, but people are surely using their own one, so we should let them choose. This way you have a SM framework doing only SM, and people add messaging with customizing the base state, or something like this (surely there's better way)

- These 2 points allow to make a true VI package

I'm still working on making a simple example without messaging and "library-based", if anyone is interested let me know

Wow, thanks! I was working on a generic SM based on your code too, and just finished when I saw your answer Never mind, it got me diving in the code. However I think the attachment is still the old code

I downloaded and looked at the code, it looks great!

I have a few questions, though:

• Transitions seem to be handled in Entry and Exit actions. But what if I want an action to be executed only in a from one state to the other? (i.e. a transition action)
• I will use the SM from the GUI, which will trigger state changes. Can I use the SendMessage method for that? I ask this because it is currently a private method of the SM
• What needs to be done if I want a more generic SM class that will be inherited, in order to be reusable from one case to the other?
• Have you considered to make it an OpenG package?

Charles

If you're comfortable with objects I posted an object-based state machine here. I've refined it a bit since that post but the principles are sound.

Thanks, I had found it since. See some questions I asked on this thread.

Got it here too. Strangest is that it happened twice. In the same week.

I build the executable quite frequently (not continuous integration though) and never got it before.

The project is quite big (700 VIs not counting vi.lib and OpenG), so finding the error was a pain since building Exe takes 10 mn.

First time was solved by replacing a subVI (which was just updating a cluster) by its code and deleting the subVI.

Second time (happening on a simple VI with a global variable) was solved by unchecking "disconnect typedefs" and "remove polymorphic VIs"

I'm source-controlled so I can give the snapshots of my project when the bug happened, if NI guys want it for repro no problem.

This problem needs to be fixed for real, it's giving pain to a lot of large projects, from what I saw on NI forums

I realize that the thread had diverged on different errors, so just to precise that this is about error 1502 (cannot save VI in bad state)

I agree with last two posts; needing also a "real" state machine, I have looked into the Statechart toolkit but not satisfied and quite expensive. Is there a template or an example of this, with JKI SM or something else?

Got it here too. Strangest is that it happened twice. In the same week.

I build the executable quite frequently (not continuous integration though) and never got it before.

The project is quite big (700 VIs not counting vi.lib and OpenG), so finding the error was a pain since building Exe takes 10 mn.

First time was solved by replacing a subVI (which was just updating a cluster) by its code and deleting the subVI.

Second time (happening on a simple VI with a global variable) was solved by unchecking "disconnect typedefs" and "remove polymorphic VIs"

I'm source-controlled so I can give the snapshots of my project when the bug happened, if NI guys want it for repro no problem.

This problem needs to be fixed for real, it's giving pain to a lot of large projects, from what I saw on NI forums

Hi,

This package looks interesting, however not compatible with LV2010 (wires are broken when wiring the event).

Best,

Charles

Since you only want the enter key navigation disabled while the user is typing in the string control, use an event structe to detect when the use is typing in the control (key focus), and then set the key navigation of the button to nothing. Then, when the string control looses key focus (another event in your event structure), set the key navigation of the Boolean back to its original state.

Thanks :thumbup: , that's what I wanted to do, but I couldn't find out how to change the key navigation of a button at runtime... Now I found

However I don't find the event that tells me that the control has lost the focus?

Thank for your help

Hi Charles:

Are you using the Prompt user for input express vi?

If so, open it up, (right click>Open front Panel)

right click on the OK button>Properties>Key Navigation tab>

Under the "toggle" pulldown, it probably says "Return" select "none"

Work your way back, save the express vi (You'll be converting it to a regular vi, need to give it a name.-- See the documentation for Express Vi's for details if you need them.)

Should solve your problem (if I understand what the problem is ).

Best Regards, Louis

Hi Louis,

This is not ideal for me, because I still want to fire the OK button when the user hits the enter key while not having the focus in the control

Thank you anyway

Hello,

I have dialog with a multi-line string control, and a button allows to validate the dialog. This button is linked to the enter key.

But this way, the user cannot put multiple lines, because if he hits "enter", the button is fired and the dialog closes! :headbang:

Is there a way to bypass this? like deactivate the "enter" shortcut while the user enters text in the control? I tried but didn't find how.

Thanks for your help!