jgcode

Agreed, the alternation character is unnecessary. It'll work just the same, but it changes the logic of the expression (though it may have no performance impact).

The Match Pattern node does not support finite quantifiers, but dot and star work as expected. Because string length is an O(1) operation, maybe this is worth considering:

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

I think that the update of this information could very easily be automated during the build process.

What if there were a special package that OpenG Developers had installed that included a dialog for editing these tags and performing other, similar/related activities?

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

My only comment is that the Regex doesn't need the pipe. I don't understand why Match Pattern doesn't work, but it definitely doesn't.

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

I'd recommend adding a VI to create a GUID, and then have Is a GUID.vi follow whatever format is used in the create function, while also being able to interpret whatever format(s) LabVIEW might present.

I know there is this format related to the Project:

Any others?

A Regex would be slower, I would ignore the error (if using Match Regular Expression) and the \w will include non-hex characters.

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

There is a function in LabVIEW to generate a GUID. See this post.

http://lavag.org/top...dpost__p__32909

Maybe an OpenG wrapper VI to call this function?

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.

and the \w will include non-hex characters.

Of course! Thx!

Does it always have to be lower case hex only as per these examples?

The problem is that I will not have a steady number of these devices connected to the host PC. Depending on the experiment 1-4 devices (and possibly more in the future) need to be connected to the host PC.

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

This all sounds like a very good plan.

Thanks for the support Val.

If there is a VI that creates a GUID, it's a good thing to have.

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

If there is a VI that creates a GUID, it's a good thing to have.

So is there a VI that will do this in string package?

//Mike

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

I have read CC support the new-BSD etc.. for software, so this still leaves me confused.

I have seen it pop up with respect to LabVIEW

Here is another example I just saw today.

It would be of interest if anyone who has experience in using these licenses can comment.

I tried to install labview 8.0 on my laptop ( vista window).

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 got official reply from NI engineers:

Buffered counter operations are only supported on STC3-based devices (i.e. X Series and CompactDAQ).

Your M Series is an STC2-based device and so does not have support for buffered counter outputs. Any updates to the counter output characteristics on this board have to be software-timed.

If you do need deterministic counter updates, you could either switch hardware or implement a workaround using the digital output with a pre-defined digital waveform.

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?

I don't see a problem if I don't use any VIs written by name1 but mention him in such a leagal document. Wouldn't it be the a similar situation as using a dll and never calling any routine written by developer1?

So you want us to maintain and make available a full list of developers names regardless of which VIs are used. That could be done.

What do others think?

I think the license should have the VI name and toolkit name.

Can you please comment as reason why you would like this, that would be very helpful.

Also if this information was in the VI Description as a Tag would that suffice?

Team LAVA Requirements and Recommendations for publishing code through LAVA onto the LabVIEW Tools Network are now available in this Article.

LAVA is a facilitator and as such we...

View the full article

Do you think this is something that the developer editing the VI can document and maintain when they make changes to the VI?

Or it could be another Tag?