jgcode

Unfortunately not this year But definitely next!!

My sentiments exactly. Congrats guys! [:beer]

Thanks guys!

Have you seen the Simpsons episode with Bill Gates? I am thinking something like that

I don't have it right of front of me, but you 'should' be able to popup on the io constant and select which class i.e. DO.

Did you check the manual? - DAQmx will definitely work. The drivers are free and should be included with the device or can be downloaded from NI's website.

I just posted in my NI thread a link to your post. Let's see if we can get someone to revisit this issue, track it down and get it fixed

I reported this bug: http://forums.ni.com/t5/LabVIEW/Unit-Test-Framework-Crashing-LabVIEW-Project/m-p/1110768 And got CAR 220428 for the icon issue but NI could not replicate the crashing issue when removing a test from the project file. It is the same issue you have? Did anyone get a CAR they can post? This bug is very annoying.

You should check out the latest VI Shots podcast.

Three words: Kill the cat

I also like to use the same as you - Library containing Classes e.g. But when I distribute it looks like this: As you can split it all up - I just think of llbs as a folder. For development I like to set things out pretty much like this: Where modules (under src) are Libraries, Libraries of Class, or single Classes or traditional modules (e.g. MFVI's) etc... Curves is the name of an application, each application in the project (only 1 in this case) gets its own directory at this level (i.e. they share Shared VIs, Reuse VIs, and Modules).

I disagree - (yes, llb's are old) but I like to distribute a single class (or library) as an llb. Of course, multiple classes (or libraries) would mean multiple llb's for that distribution.

I believe it is to do with the reentrant\thread setting in the Call Library Function's configuration dialog.

Hi Joan Are you including the correct support files on the RT system?

Mutation history is not maintained is this case.

Thanks guys

Thanks, there is a link in there which points it to the Feature Request Tracker (as opposed to the Bug Tracker), and the OpenG forum has your VI, I can follow up and post back in the near future. The Bug Tracker was cleared in this update - but I need to find out some history on the FR Tracker (I am new here ) Cheers -JG

Greg thanks for your feedback - much appreciated, it seems LabVIEW Data was missing from the dependencies of the OpenG Toolkit. So I can do a fix for that and I will update the LVTN post too. I think I have a workaround for that - VIPM does not allow you to specific a relationship with incompatible packages in that direction: However, we could make the value of the dependency packages comparison operator to be equal: Which forces an upgrade - if this is what we want to do? (ignore portio in screenshot, I snapped this before I had finished): I will ping you offline to discuss further. **************************************************************************************************** Here is the OpenG Toolkit Package post updated for the above reasons LVTN 'OpenG Toolkit' Package One package you may or may not have seen is the OpenG Toolkit package. Chris Bolin from NI was the original author and released v1.0.0.5 on the LabVIEW Tools Network (LVTN) as a way for new users to easily download the base OpenG Library - very clever. OpenG has now extended this package and used it to allow a user to quickly configure their LabVIEW installation with OpenG 4.0. This means that VIPM automatically installs the new packages and automatically removes the redundant ones, even handling the renamed oglib_buttons package - a clean way to handle things, and was the installation method I personally used. Note that all older OpenG packages were uninstalled for the upgrade to work but we are going to try and fix this to make it better (watch this space). The great thing about this is that anyone who clicks through the LVTN to download OpenG will automatically download the latest version. Yeah, we're smart like that **************************************************************************************************** Hi Mads - what is the ID of this bug in the Tracker?

We Fixed Bugs Too! At the time of design we fixed all outstanding bugs in the Tracker for all packages. We also made use of another new feature of VIPM 2010 - Release Notes. Release Notes allows you can check out the upgrade in detail when you add the package in VIPM or when you popup and select Get Info on a package in the main window. It includes the ability to easily track fixes via their SourceForge IDs - if you file OpenG bug reports this is similar to getting an NI CAR#.

Installation Issue - OpenG LabVIEW ZIP Library As GregsSands pointed out here there is an issue with the OpenG LabVIEW Zip Library installing. When you install the other Libraries, if OpenG LabVIEW ZIP Library installs with an error you have to re-install it again. It is a known issue that I have reported here so I won't go into detail again other than to say that we are also looking for a workaround to fix it.

All The Packages Below is a list of all packages that have been updated that are part of the OpenG 4.0 Release: OpenG Application Control Library OpenG Array Library OpenG Boolean Library OpenG Buttons Library OpenG Comparison Library OpenG Dictionary Library OpenG Error Library OpenG File Library OpenG LabVIEW Data Library OpenG LabVIEW ZIP Library OpenG Large File Library OpenG MD5 Digest Library OpenG Message Queue Library OpenG Numeric Library OpenG Picture Library OpenG Port IO Library OpenG String Library OpenG Time Library OpenG Variant Configuration File Library OpenG Builder OpenG Toolkit Note that OpenG LabVIEW ZIP Library, OpenG Port IO Library and OpenG Builder are the only packages not upgraded to and tested with LabVIEW 2009 as part of this release. There are a few reasons for this relevant to each package therefore, the sources for these projects remain as per their previous release. However, the palette location was required to be changed in order to be consistent with the OpenG 4.0 release. As a result OpenG LabVIEW ZIP Library (oglib_lvzip) and OpenG Port IO Library (oglib_portio) versions' were both bumped up to 4.0. OpenG Builder (ogrsc_builder) - not considered part of the OpenG Toolkit - was incremented using the Fix version number only. It was also decided that some of the packages would be merged. These were mainly palette only packages - don't worry i.e. this does not relink VIs or anything like that! The following packages are redundant and have been merged as follows: ogmnu_appcontrol_plus is now available as a sub-palette in OpenG Application Control Library ogmnu_classic_sync is now available as a sub-palette in OpenG Message Queue Library nilib_rectangle is now available as a sub-palette in OpenG Picture Library As mentioned in a previous post, ogsrc_dynamicpalette is also redundant. One package was renamed in order for automatically generated palettes to be in alphabetically order - ogctl_buttons was renamed to oglib_buttons.

Using VIPM 2010's Custom Category Feature One of the new features of VIPM 2010 is the Custom Category which, is an easy way to provide a top level category palette for a Toolkit (not just OpenG’s – but your own too!). OpenG decided to use this awesome new feature however, it creates a consequence that I need to point out in case you come across it and think its a bug: When an OpenG 4.0 package and an older package are installed together, two palettes will appear in the Functions (or Controls) palette. Which would look something like this: Being a neat freak this one annoys me but of course this does not create any functional issues - more aesthetic or organisational ones. This is why the OpenG 4.0 release was synchronised. The benefit of releasing Libraries in individual packages is well known however, to minimise this annoyance we released them all at the same time (assuming a lot of users would upgrade at once). This issue was identified early on in the OpenG 4.0 process and we decided that we wanted to incorporate the Custom Category feature and that it would be better to handle it now, as we upgraded to VIPM 2010, rather than later. Previously, the ogsrc_dynamicpalette.ogp package was a dependency of all OpenG Library packages and handled installing all menus etc... Now, each package will create the top level category palette if it does not exist - or replace it if newer, making the ogsrc_dynamicpalette.ogp package redundant (with respect to OpenG 4.0). Anyways, I really like the Custom Category feature

Upgrading to VIPM 2010 This feature does not have a direct benefit to end-users of OpenG - but its dear to my heart as we sure spend a lot of time working on it - I learnt to appreciate the time it takes to make edits to an SVN Repo over the web The driving force behind migrating from OpenG Package Builder (OGPB) to VIPM 2010 as the primary package building application was that package building is now available in VIPM 2010 Community Edition i.e. it is free! This is huge in itself, but it now means that the OpenG package building process is a lot easier and will benefit from new features over time. Don’t get me wrong, OGPB is a great product, has its use cases and OpenG currently still builds select packages using it, but this will make it easier for Developers join up and help out by using a familiar environment. The OpenG projects' disk hierarchy was changed to better support the migration from OGPB to VIPM 2010 (where a project forms an individual release e.g. OpenG Application Control Library). A lot of thought was given to this new layout so that the disk hierarchy can be scaled in the future and would also be easy to navigate for new Developers. Additionally, older OGPB etc... support files have been cleaned-up and/or removed. On a side note, changing from OGPB (which have .ogp file extensions) to VIPM (which have .vip file extensions) packages creates no problems as VIPM considers this an upgrade (as long as the file name has not changed and the version has increased) - this was a very important point in upgrading the packages. So in summary, the transition was very manual, but its all done now, and adding to it is as simple as, so it was well worth the effort. Check out an example of how we upgraded a project here on the OpenG Wiki.