Leaderboard

Howdy, I wanted to post what I have been working on lately in order to get some feedback. There has been some discussion about managing a large number of states in a state machine neatly. Jim Carmody came up with this brilliant solution. This particular implementation is also based on the JKI State Machine mainly due to the fact I now seem to be using it all the time (I have become addicted). I have been working on modifying the architecture of the state machine to accommodate a large number of states by introducing sub states. I also want to do it in such a way I can upgrade existing code quickly and easily. If a group of states (e.g. UI) gets too large, I will move all UI states to their own case (owned by the separator case). This seems to be neater and easy to read then having to scroll the state drop down menu when the number of states starts getting large. Plus the states are all grouped, so it is quite natural for them to sit together (IMO) in an owner case. The JKI Syntax lends itself really nicely to this. So I wrote a parser that is a wrapper for the JKI Parse State Queue.vi. If no sub states are configured with the parser, then the VI behaves exactly the same as the JKI parser. With respect to the state machine, everything else stays the same, so no code gets changed as such, just its location really. I guess a disadvantage to this is readability from the point of view that I have now have increased the nesting of case structures. But so far adding depth the the state drop down menu on the block diagram works fine. I am sure other people have done this before, anyone care to discuss the advantages and disadvantages to such a design? Cheers JG JKI State Machine with Sub States (LV8.2).zip [LabVIEW 8.2]

Hi We use a central MSSQL production database, where we have all software listed, plus a change log what have been changed between all versions. So every time the application starts up it check if it's Software Part Number and revisi0n is the latest one, if not it displays all changes between the versions and gives the user an option to upgrade. If they decide to upgrade I start another LabVIEW exe-file located on the network (instead of using a batch file) and closes the current application. The Upgrade application, takes a copy of the current version and stores it locally in an OldVersions-folder, and then download the next version (using the database as a reference). When it's copied the application in place it starts it up. It also gives the user an option to revert back to the old version if the new version has some problems. To get this working smooth fully, we have a Configuration Management tool (simple LV app), to help out with creating new versions in the database and upload, commit and tag every release. Cheers, Mikael

Any control represents as many as 5 copies of the data. Default value -- the value of the control by default. Operate value -- the currently displayed value of the control. Execute value -- the value actually in the FPTerminal. This may update several times before the data is passed to the control itself unless Synchronous Display is enabled. Transfer value -- the value last moved from the FPTerminal to the Operate data. The transfer data copy is made by the executing thread so that the execution isn't locked by a transfer to the UI thread. Can't copy directly to Operate data since the UI might be in the middle of a redraw when the transfer occurs. Extra value -- created only when VI Server Value property or a local variable gets involved trying to copy the data back out of the control. The comments here are talking about the extra data.

Don't forget - if all you want to do is use "Get" and "Set" instead of "Read" and "Write", you can just modify the default values for the appropriate controls on "...\LabVIEW 2009\resource\Framework\Providers\LVClassLibrary\NewAccessors\CLSUIP_LocalizedStrings.vi". That being said - this is a great addition that will make automatic updating of the icon possible. Thanks, Jaegen