04-20-2009 10:57 AM
A few weeks ago, when I was presenting at LabVIEW Developer Days, I was asked if it was possible to convert a text–based case selector to an enum one. The developer used text case selectors during the initial phases of development and wanted to convert these to enums in the final phases. They were currently doing this manually, with the usual attendent issues. What they really wanted was a right–click option to do the change.
I looked into the issue and found that the right–click option requires a change to LabVIEW core. However, it is straightforward, though tedious, to write a utility which creates an enum from a text case selector. It is also possible to replace the inputs in the VI, but this involves a large number of possibilites. Doing this in a robust manner would be difficult. So, I wrote the enum creator, which is attached below. It is written in LabVIEW 7.1. The block diagram is locked because it contains a large number of proprietary properties and methods.
I would recommend using it in the following manner. During development, create a typedef which is a simple string. Use this typedef for all inputs to the string case structure. When you wish to switch to the enum, run the utility. Close all LabVIEW code but the newly created enum. Overwrite the string typedef with the new enum. Reopen the code with the case structure and it should be good. In older code, you can manually replace strings. Note that string constants will need to be set to the proper enum value manually (use Edit»Find... to find them).
To run the utility, you will need to have labels on all structures which contain the target case structure. Enter the “path” in the "path" to case structure input. This “path” is a forward–slash separated list of the containing structures from the root block diagram to the target case structure. Frames for things such as sequences and case selectors are indicates with a **nn suffix on the structure name, where nn is the frame number. Note that for case selectors, the frame number is created in the order the frames were created. Reordering the case selector will reorder the frame numbers, as well. Open the included TestTarget.vi. The path would be “MyFlatSequence**1/TheForLoop/TargetCase”. The VI path is the location of the target VI on disk. After filling out these two inputs, run the VI. The enum will be created, but not saved. Close all your other VIs to avoid name collisions, then save the enum.
Have fun. Let me know if you have any suggestions. The Xylophone Project will return next time.
05-19-2009 02:12 PM
05-19-2009 02:35 PM
Thank you Dr. Damien!
andre.buurman@carya wrote:
To me the proper way would be to use a typedef enum for developement start and cleanup naming afterwards would be as simple as it sounds. It propagates through the code like a knife through butter. I know you know, but its for al the readers that don't know a might think the described method is interesting. In my opinion, if you develop like above its an interesting tool to automate a manual task, but if you have a choice, don't start developing in this manner is my advice. I hope it is of help to someone,
I am 100% with you Andrey. The above will help out for those poor developers that has to support code that came out of one of those LV shops that thinks that string driven state machines are "the cats meow.". There are plenty of the QSMs still out there and (baffling to me) people think they are still valid structures. Personally I think they should be filled along side of languages that "push" and "pop" to/from the stack.
Ben
06-06-2009 04:14 AM
Thanks for the tool Dr Damien 🙂 Tools like that are always a blessing whensupporting / upgrading code.
I agree with the above two posts also...however. I will always use type def enums for my state machines but i still find the string one usefull for certain jobs. One example is when it is driven from a text file which can be easily changed without having to re-build executables etc as hardware has been developed. But yes I agree, I stay clear of them when I can
Craig
07-14-2009 02:37 AM
Now with scripting released and the JKI right-click-framework, I wonder if there isn't a chance to actually get get this opened up and added as an utility for said framework?
Not that I would use it often myself, since I use strict typedefed enums for all my state machines and intelligent global variables since about LabVIEW 5 after a very brief phase of using strings for state machines. 🙂
Rolf Kalbermatter
07-14-2009 07:45 AM - edited 07-14-2009 07:45 AM
07-14-2009 08:38 AM
Thanks for the unlock!
I am a big fan of enums, so I got curious as to how you created the enum during execution, so I opened your .vi and had a look... and I am amazed!
Where does the "New VI" and "New VI object" functions come from? Is that Labview scripting? Whatever it is.. it's interesting!
07-14-2009 08:50 AM - edited 07-14-2009 08:56 AM
Jan_HeG wrote:Thanks for the unlock!
I am a big fan of enums, so I got curious as to how you created the enum during execution, so I opened your .vi and had a look... and I am amazed!
Where does the "New VI" and "New VI object" functions come from? Is that Labview scripting? Whatever it is.. it's interesting!
Yes it is LabVIEW scripting. A whole new world to explore but beware!!
You can spend days with it and forget about the real work you have to do! And it is a very advanced level of programming and for some of the workings you simply have to develop some intuition to get it working properly.
Rolf Kalbermatter
07-22-2009 10:23 AM
I have a problem here. I saw that the Frames (property node) does not execute at the Run-time. I saw help which said that the "Frames" property node is not supported by LabVIEW Runtime Engine and the Real Time Module. is there way to overcome it.
thanks a lot in advance.
07-22-2009 10:26 AM - edited 07-22-2009 10:28 AM
Most of scripting does not work in a runtime system and I would not know of any way to overcome that. It would require a compiler too which the runtime explicitedly does not have.
Rolf Kalbermatter