Leaderboard

I've taken to using Globals wherever I need something in multiple processes. When the values need to be configurable (which tests to run, test limits), In my JKI State Machine I read an ini file to get the values then write them to the Globals (and to the test data, to keep folks honest). If the value doesn't need to be flexible I set the default value of the Global. There's a good illustration here.

Yes, you and Tim_S both described just using a VI with a constant on the block diagram (wired to an indicator, of course), and I don't see any reason why that wouldn't work fine, especially in-lined. Sounds good to me, at least! I'm just a little slow today! :-)

Very cool - I like this very much so I will post it here:

Something I've done in the past is to drop the constant value on the block diagram of a new VI, then save the VI as something like "Constant - Spreadsheet Password.vi" and that's that. This does have the downside of requiring one VI per constant, but you could just as well merge all of them with a case structure and a typedef'd enum.

It seems to me this is exactly what I described, with the exception that technically you can still edit the constant value. You can even make the icon small and everything!

OK, this might not be the answer you want, but why not use a configuration file (and then wires)? Isn't that really the better answer? (Then you never have to update the value in the code.)

I feel this is the best way to represent a project constant. It is obvious in the calling code that you are accessing a constant. Using globals, FGs, imply that data is being stored and changed. Even if you put a comment in the FG or global it still doesn't guarantee abuse of the constant, and an outside developer is left to finding all instances in the event that something goes wrong. An inline SubVI with a constant IS an immutable object. So what is the best way to represent an immutable object (I.e project constant)? how about with an immutable object?

There is precident in the document. Version 1 of the GUID uses a timestamp to help reduce the probability of collisions. In this case though, the prospect of a "valid" GUID comes up, in that it can never contain a timestamp in the future. This version though typically uses the 48-bit MAC address, not the IP. I've updated the VI I wrote to generate GUIDs. It now supports version 1 (timestamp) and version 4 (random). I'll look into adding support for version 3 (MD5) on the weekend if there's interest. Maybe even version 5 (SHA-1), though I don't think we have access to a platform neutral SHA-1 algorithm in LabVIEW? Also note in the version 1 implementation, I created a multicast MAC address out of thin air. I don't believe there's a cross-platform way of getting the MAC from LabVIEW, correct? Regardless by setting the address to multicast, the random number should never collide with a real NIC's MAC as the RFC recommends. The files are now in a zip because in addition to Create GUID.vi, there's also a new VI to create properly resolved timestamps, and a GUID typedef. I also apologize for for derailing this review. I just think that if you're going to have an Is GUID.vi, it should be consistent with whatever means you have of generating said GUID since there is no standard adopted for formatting. I'll also pose the question of do we want the Is GUID.vi to validate version 1 GUIDs, insomuch as it would return false if the timestamp is in the future? GUID LV9.zip

Greg, we have successfully used Beckhoff EtherCat Bus Coupler + IO Modules with cRIO Controllers in some projects. What type of hardware are you using exactly? Did you download the latest XML files for your modules from the Beckhoff site? Are you using the latest drivers from NI? Regards, Swen

I've used functional globals, however I've used and read good argument for using global variables. Global variables can contain constants kept in controls with the value set as the default. You then have one VI to go to for all of your constant values. I would recommend the FG over the global if you are going to access the value frequently, but if it's something that you are going to read once during initialization and never again (e.g., IP address of target system) then a global would be appropriate. If it's a value that never changes and you don't load, a VI with a constant in it could be set to inline, thus providing the same (similar?) overhead as a constant with the benefit of changing the value one place. Tim

rendering utrasonic scans in 3-space. With skins This I call "Cscan on the surface. This shows the data rendered inside the wheel Extreme zoom in, sector of wheel reduced threshold looking at flaw from inside wheel Another CScan on surface but challenge of the web illustrated. This was all implemented using LVOOP so that I can add new surfaces for other applciations when the need arises. Ben

I don't think you give that impression. It's not even close to complete (the four-hour time limit would be a killer), but I can show the statemachine with a case that is; the "Main Menu" when the user selects the "Fast Cash $50" option (see attachment). I found the ATM problem to be obviously calling for a state machine; it practically defines all the states for you. The problem equally seems to call for some LVOOP, again practically defining all the classes: "User Console" and "Account Database", with children "Simulated Console" and "Simulated Database" (ready for the eventual replacement with "Physical Console" and "Enterprise Database"). If I were to use a JKI-SM (though I wouldn't be allowed the template on the exam), I might instead have had "Macros" such as... "// Main Menu Card Slot >> disable Keypad >> disable Menu State >> Main Display Message >> Main Menu Wait for User Input Process Main Menu Input" ... with the "Process Main Menu Input" calling (if the User pushed this button) "Fast Cash $50", which would call "Withdrawal >> Complete". The QSM version would not be terrible but would be clearly poorer than a true SM. But this problem is very clearly definable as a statemachine. Most programs I write involve "do the task requested before returning to idle", with the complexity of the task being more easily broken down into sub-tasks than states. For complex tasks, JKI-style macros are quite clear and they're quick to write compared to wiring up subVIs. The subVI option is clearer than JKI-SM frames, and I can appreciate some of the other advantages you point out, but the real reasons I've started to use subVI's more and more lately is the advantages of OOP classes and dynamic dispatch. BTW, what do you think of the provided example solution to the ATM example test? The one where it's done with Action Engines. -- James