jgcode

Upgrading to LabVIEW 2009 We decided to upgrade the sources to LabVIEW 2009 in an effort to keep OpenG current. The great thing about packages is that if OpenG users are programming in an earlier LabVIEW version then the newest release, all previous releases will still work. Upgrading allows OpenG to take advantage of new features as well as to unit test in a later version to increase quality and identify any issues early. This is a standard progression as OpenG 3.0 migrated sources from 6.1 to 8.2 for the same reasons.

Hi All This thread has been created to blog about information relating to the OpenG 4.0 Release. It will contain what we did and why we choose to do it and anything else we find interesting. Please feel free to add in any comments or feedback about the release. I will just keep adding to this thread. Cheers Jonathon Green OpenG Developer

Thanks for the kind words Jim, it was a pleasure Hi Greg, this (LabVIEW ZIP Library) is a known issue, but we have now documented it.

Please continue discussion on this issue so as I would like to add support for timestamp and release an iteration in the near future. Cheers -JG

Dear OpenG and LAVA Communities, I’m happy to announce that the OpenG 4.0 release is now available for download. OpenG 4.0 is a synchronised release of all packages that form the OpenG Library: The release includes the following features: Fix to all outstanding bugs (at design time). Package sources upgraded to, and tested in, LabVIEW 2009. Packages now built using VIPM 2010. I will be posting more about this release in the near future. On behalf of Jim Kring and OpenG.org, thank you. Jonathon Green OpenG Developer Installation Open up VIPM 2010 and if not configured to do so press Check All Package Repositories for Available Packages, then choose one of the two options below: Install the OpenG Toolkit package - this package will configure your system to install all the latest packages as well as remove any non-Library packages no longer required (don’t worry it won’t remove any VIs you are using). This is recommended for new or basic users. Manual installation - upgrade required packages on a package-per-package basis. Note: OpenG Builder is not part of the OpenG Toolkit and therefore will need to be manually upgraded (if required).

Hi Stobber LabVIEW has functionality to allow reuse VIs to only show up in specific context's (e.g. RT/FPGA). This article: Developing a VI Based API may help? Cheers -JG

AQ, can you go into detail here? Also, do Template VIs have a specific use case wrt instantiation of stuff?

Thanks for posting this bug and your code update jed. This issue will have to be further investigated however, You can track this bug here: ID: 3303663 Cheers -JG

Hi Martin You can do this and I have done it before. Here is a screenshot of an example: You just have to use Rings (not Enums - FWIW I don't use Enums as display elements anyways, only as application data) and don't use Strict Type Defs for the Rings, Cluster or Array as then you cannot change the Ring's Strings[ ] property (it throws a Run Time error if I remember correctly). In the example the UI element is an Array of Clusters where one element is a Ring. I just use VI Server Refnums to populate the Rings at Run Time (e.g. on changes in the Applications etc...) and they can be different even though they are in an Array. Cheers -JG

No, more like details -> Tables will default correctly using the IN (you said they wouldn't above).

That is not quite correct. Tables will be cleared (or rather, set to Default) using that IN as their datatype is a 2D Array of Strings. Combo-boxes have a String datatype so that will Default the 'selected item' (which is what the datatype refers to) not the actual list data in the combo-box which is persistent and accessed through e.g. Strings[] PN. IMHO this behaviour is expected and should not be changed.

To be honest, I was surprised it worked in the run time (yes, my previous use cases were scripting). However, I always enjoy reading about these LabVIEW tidbits.

Yes I forgot to add the footprint is large, and then reread your use-case, sorry. On a side note, since the Class is already in memory maybe there is a way to get e.g. a cache'd reference rather than open a new one?

A bit late to the conversation I know, but why can't you encapsulate the reference to get the desired effect (assuming Class exists on disk)? I remember I had to do something similar when scripting once. Don't know it it helps? Cheers -JG Here is an example project The VI's API accepts a LabVIEW Object as an input Behind the scenes it just uses a Class Reference but that is encapsulated Here are the results I also tested it as a build and these properties are available in the LV Runtime. FQN_LV2009.zip Code is in LV2009

The outputs of a node (subVI, primitive, structure etc...) are not available until all inputs have been received and the node has finished executing. From a design point of view, if the two tasks are truly parallel, and therefore independent of each other, why couple them inside the same subVI? Not a feature I have played with a lot: but would inling the subVI solve this issue. Therefore, I don't think the two examples are exactly the same code because in (2) you have always enforced sequence order. And yes, I would not want this to change

I disagree that they are pointless. In the sample exam encapsulating the keypad buttons into an xcontrol makes complete sense. And IMHO is the correct architectural choice wrt to designing the UI for that part of the example. Of course you could code and example without them and still have it work, but in this case, I think an xcontrol is a 'better' choice.

Thanks! Was looking in the wrong spot Thats great.

Thanks guys, I am definitely here to learn too, Where do I find this option? I can't see it in the Variable Properties Dialog?

I was wondering want people's thoughts are on the behaviour of the Shared Variable Value Change Event. If this variable is written to on e.g. a RT target then it will cause a Value Change Event. In this case, as the program loops it updates all variables, with the latest data. In the video you will see that the value of the ALARM WORD does not change (stays as zero) however, an event is still fired. The problem is that this was happening for a large number of variables (500-1000+) and seemed to be stressing out the Variable Engine (even causing it to crash). Now the behaviour seems correct compared to doing the same thing with a e.g. ValSig node on a simple BD. But for Network Comms I don't see the point in the Event occurring if the value has not updated but has just been written too with the same value. Regardless, (assuming that there is not one already???) do you think there should be an option to filter this behaviour? We ended up doing the filtering in the code on the RT side, but a configuration option would be cool. Cheers -JG <object id="scPlayer" width="1168" height="711" type="application/x-shockwave-flash" data="http://content.screencast.com/users/jgcode/folders/LabVIEW/media/d8bb4fe1-a57c-47c1-989c-b80b42238d3c/bootstrap.swf" > <param name="movie" value="http://content.screencast.com/users/jgcode/folders/LabVIEW/media/d8bb4fe1-a57c-47c1-989c-b80b42238d3c/bootstrap.swf" /> <param name="quality" value="high" /> <param name="bgcolor" value="#FFFFFF" /> <param name="flashVars" value="thumb=http://content.screencast.com/users/jgcode/folders/LabVIEW/media/d8bb4fe1-a57c-47c1-989c-b80b42238d3c/FirstFrame.jpg&containerwidth=1168&containerheight=711&content=http://content.screencast.com/users/jgcode/folders/LabVIEW/media/d8bb4fe1-a57c-47c1-989c-b80b42238d3c/LV_2010_-_DSC_-_Shared_Variable_Events_Issue.swf&blurover=false" /> <param name="allowFullScreen" value="true" /> <param name="scale" value="showall" /> <param name="allowScriptAccess" value="always" /> <param name="base" value="http://content.screencast.com/users/jgcode/folders/LabVIEW/media/d8bb4fe1-a57c-47c1-989c-b80b42238d3c/" /> Unable to display content. Adobe Flash is required. </object>

Allow 45 Degree Free Labels

Thanks Vugie that link looks great, I will go through it in detail. Essentially I have some diagnostic screens that I want to make pretty. They show a summary of bits and I thought 45 degree labels would be easier to read. But they don't need to be free labels.