jgcode

You are still going to get an error Opening a reference to the Task if the device is not on the network. You would have to disable the entire workflow (Open, Read, Close resources) if you wanted to to that. Cheers -JG

I am down with Tim_S here, IMO that's a perfect use case for Global Variables - why? because anything else (FGV, MAPs) seems like much too hard work. I took this lead from Darren, for your use case he calls them WNRM Globals. The cool this is that the Global acts like a config screen for developers in edit time - I find that handy. You can even scope them if required. You just have to get past that feeling that they are icky to use Otherwise if it is a constant I will reuse - I will create a VI so I can mine it later for reuse.

The way I see it, if it was done - the End User should install all the latest packages so the entire Library is in vi.lib (which would be in the current version e.g. LabVIEW 2009). As for manually installing the code, I don't know, OpenG is designed to be installed using VIPM, if someone is doing some custom install I don't think we can handle all those use cases - I guess the End User would have to do what's necessary to maintain the installation then. In terms of your example above, I would not recommend having two versions of any code installed under <LabVIEW> just for the possibility of linking to the wrong code. VIPM only allows one version of the code to be installed e.g. A v1 or A v2 - assuming of course that in your workflow you would never create two separate package streams (e.g. A v1 and B v1) with code of the same names etc..

Just from quickly browsing the doc, is that was jcarmody has done (or similar) in his screenshot?

That's quite clever, and would be faster than RegEx.

I like that idea - I tool that I can point at a VI to refresh the license as well as edit the Tags (to avoid syntax errors) whilst I was working on a VI; and a build script to automatically update the license so it is current would be handy. Attached is an example of what I am thinking. I tried to avoid duplicating information and making the license as only as big as it needs to be (if a tool is being built for this it won't be any more work doing this). Anyways, the main point of this thread is that these Tags can be read back as a way to help End Users attribute copyright to the authors. I think the editing tool would be handy for non-OpenG developers, if we were to develop some convention or standard in the Community for reuse - that would be cool. I see a few parts to this concept: Tool for editing Tags during development Script to update/generate license (run as build script) Tool to parse Tag information (and e.g. save it to disk) for reuse VIs in a Project API to read back information, user can then format Thoughts? openg_licenseExample.vi Code is in LabVIEW 2009

I can take the alternation metacharacter out if no one likes it in there - no dramas. (Unsure if it impacts performance or not).

I know there is this format related to the Project: Any others?

Yes RegEx is slower but your code with Match Pattern does not pass the Test VI? I don't think Match Pattern supports Quantifiers? I am not sure? (I always find myself looking up Match Pattern help as its different to RegEx) Can anyone confirm - can we use MP for this (it is much faster). Anyways here is the fix from using any alphanumeric to specifying a character class based on Phillip's post. (Sorry, I cut, pasted and edit from the GUID thread - thanks for pointing that out) I had to update the original Test VI to fail MD5's that contain [A-F] range (see new VI attached). Is an MD5.vi TEST - Is an MD5.vi Code is in LabVIEW 2009

I don't know if I want to be using VI's in the resources folder? (It's not because of linking etc... we can handle that dynamically). I am pretty sure we could come up with our own.

Of course! Thx! Does it always have to be lower case hex only as per these examples?

Hi Ano Ano Can't you just use an Array of Tasks and a For Loop and configure the Array of Tasks at Run Time? This is assuming you have enough time etc. to read and handle data for each device serially. If not, maybe you will have to look at spawning clones that run in parallel (where the number of clones is determined at Run Time)? This will make your code a bit more complex. Cheers -JG

Thanks for the support Val.

Attached are some prototype VIs to add such functionality to the String Package if people would care to comment. Generate Random ASCII Alphanumeric Characters: Generate GUID: Test GUID: Additionally there is a Generate Random ASCII Printable Characters functions included as well the the support VI for generating the lookup tables etc. GUID.zip Code is in LabVIEW 2009

I propose that we use RegEx and clean up the BD. Not sure of the best way to handle the error, above is an example to maintain the VI's interface. Is an MD5.vi Code is in LabVIEW 2009

I propose that we use RegEx and clean up the BD. Not sure of the best way to handle the error, above is an example to maintain the VI's interface. Code is in LabVIEW 2009 Is a GUID.vi

Thanks for you reply Mike, If that is VI that you would like too see (currently does not exist) in OpenG then we can definitely look at this? Community, please comment on the addition of such a VI to OpenG as well in this thread (in relation to the attached VI). Cheers -JG

This OpenG Review is active. Community, This VI was in the Candidates folder for the String Package. It has been sitting in there for a while therefore, I have just gone ahead and posted as is (so the license will be migrated on confirmation from the author etc...). What are you thoughts on this VI? Would you like to see such a function in OpenG? Can you optimize the code? It may be better suited in e.g. Comparison Package? Should it be rejected? Kind regards Jonathon Green OpenG Developer Is a GUID.vi TEST - Is a GUID.vi Code is in LabVIEW 2009

This OpenG Review is closed. See Summary Post here. Please start a new thread to discuss new changes to this VI. Please PM me if there are any issues with this thread. Community, This VI was in the Candidates folder for the String Package. It has been sitting in there for a while therefore, I have just gone ahead and posted as is (so the license will be migrated on confirmation from the author etc...). What are you thoughts on this VI? Would you like to see such a function in OpenG? Can you optimize the code? It may be better suited in e.g. Comparison Package? Should it be rejected? Kind regards Jonathon Green OpenG Developer Is an MD5.vi TEST - Is an MD5.vi Code is in LabVIEW 2009

Yer, I like to ask all the big questions... The question was raised here (among other things, but I want to focus on installation directory only) and elsewhere on whether OpenG would be better suited in vi.lib as per the NI requirements for developing third-party APIs etc... Why is OpenG installed to user.lib? That's simple, it's a historical thing. Now due to changes, notably NI opening up vi.lib, things have changed. It also turns out user.lib is so 8.0's (ha! get it?) and vi.lib is now the preferred and more professional approach for installation of third-party APIs. I tested this in LabVIEW 2009. It seems LabVIEW handles the transition quite well, so I think this is doable. You can test it yourself by doing the following: Create a Test.vi Link Test.vi to (any) reuse VI in user.lib Save and close Test.vi Move the user.lib reuse VI to the same level in vi.lib (do not edit any folder or file names) Open Test.vi and watch LabVIEW link to the moved reuse VI I have even played with changing folder names and LabVIEW is able to link to the correct VI. So we could even review if we wanted to change _OpenG.lib to _OpenG or OpenG as per the NI recommendations for Company Name. So what would a change like this mean? I envisage the following for OpenG Developers and End Users: On opening a project with OpenG, the OpenG VIs will be missing, LabVIEW will conduct a search and automatically find the new VIs in vi.lib quickly and with no user interaction All OpenG packages will have external dependencies upgraded to be the latest OpenG packages (so all linkages are correct for that package) This update of OpenG Libraries will be atomic i.e. available to the public all at the same time (as per 4.x release) Thoughts?

From the Trim Whitespace review we decided not to implement the remove non-printable characters feature from Fast Trim due to reasons of maintaining high cohesion etc... in the original VI. However, from that review and other posts (e.g. here) this VI my be a nice addition to the String package. Please vote or leave feedback if you would like to see such functionality in OpenG.

This OpenG Review is now closed. Please start a new thread to discuss new changes to this VI. Please PM me if there are any issues with this thread. Review Summary Trim Whitespace (String).vi Code is in LabVIEW 2009

Here is another example I just saw today. It would be of interest if anyone who has experience in using these licenses can comment.

Is 8.0 even compatible with vista? http://zone.ni.com/devzone/cda/tut/p/id/5539 I am not sure, I have only used 8.2.1 with Vista/7.

I won't argue with an NI Eng... ...but I am pretty sure I have used the older cDAQ (with M series board and therefore STC2-based timing) and inserted a module with inbuilt timing and exported the clock so I can do Buffered Counter Input on Slot 5/6 with a DIO module. I implemented a plug-in for Signal Express as it didn't allow Buffered Counter Input even though MAX/LabVIEW support it. I thought it would have been similar with Buffered Counter Output. I am not sure if you can set something up like that with the hardware you have, but I think that is a workaround for STC2-based CompactDAQ?