jgcode

.llb files are old technology and don't work well for distributing classes... ...There isn't really a LVOOP-compatible equivalent of llb files yet.

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 have this nagging feeling that there is a significant difference between the yellow node and the orange node, but for the life of me I can't remember what it is.)

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

I'm using OpenG Labview ZIP Library 4.0.0-2 (and also 2.5.1-2 with the same problem) on labview 2009 SP1.

I try to append a new file to an exixting zip file, using for instance the vi attached. When I run the vi on Windows, it works properly, and the output .zip file contains both input files. The problem arises when I run exactly the same vi in the cRIO 9012 RT controller. In that case the .zip file contains only the first input file and the error code 7 (message: ZLIB Open Zip Archive__ogtk.vi in ZLIB Compress Files__ogtk.vi->zip.vi) appears in indicator "error out 2".

I've tried to do the same using the ZLIP Open Zip, ZLIB store and ZLIB Close Zip, and I had exactly the same problem.

Does anybody have any suggestion to solve this problem?

Hi Joan

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

VxWorks Support (Additional Installation Steps)

For VxWorks support, after installing the lvzip package, you should ftp "<LabVIEW>\user.lib\_OpenG.lib\lvzip\lvzlib.out" to the RT controller into ni-rt\system.

.. still unsure about typedef'd clusters within a class, though.

Mutation history is not maintained is this case.

Thanks guys

I see it was only added as a feature request so I guess that's why it has not been included:

http://forums.openg....?showtopic=1117

Version 4 does not include the manual solution with a format specifier input on the read section or ini cluster either. However that would not be a good solution because then you would need to open the file and check what decimal sign is used in it prior to running the read * cluster function.

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

I had oglib_lvdata v2.9-1 installed previously (along with all the other old oglibs). The other oglibs updated as dependencies of OpenG Toolkit, but the lvdata did not get touched - though it indicated an update was available so I could easily do it manually.

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.

Unfortunately, the OpenG Toolkit package doesn't specify that it's incompatible with old versions of the dependency packages, so it won't upgrade them if they are already installed.

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

****************************************************************************************************

When I saw this release and the statement that all reported bugs had been fixed (including one described as a fix for custom decimal signs) I thought that the bug that prevents it from correctly interpreting floating point arrays in configuration files created on another machine with a different decimal sign had been solved as well, but that problem is still there, right?

I had hoped to be able to ditch my custom version of Read Key (Variant) that automatically detects what the decimal sign is in the file and adjusts the format specifier accordingly

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.

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.

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

I'm working on a harebrained idea for a set of reuse libraries targeted at LVFPGA development. This includes creating palettes for these VIs that only show up in LVFPGA. I have the wherewithal to do that, but unfortunately there are no auto-populating subpalettes of the LVFPGA root palette that only show up in LVFPGA. (User.lib shows up in all targets and contexts.)

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

The use of OO in this case is irrelevant -- you may decide to use it or not. What is key is the use of reentrant VIs. They are a much MUCH better solution than template VIs. Use "Open VI Reference" on a VI that has been marked as Reentrant to display multiple copies of the function.

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

Format Variant Into String__ogtk.vi doesn't handle timestamps, you get an "Unexpected Datatype" error, as the TDEnum reports it as a Waveform.

I have put in place a fix that seems to work without issue, but I can't be sure that it doesn't falsely detect timestamps when processing other types of data. Is this something that can be integrated into the release? Up to this point I just have to remember to copy my version over the OpenG version. It would be nice to not forget and break my code every time I move to a new machine!

-jed

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

I was wondering if there is a way of having an emum or ring control in an array which has different strings for each row?

The array element would be a cluster with two enum controls - the selection of the first would determine the strings available in the second.

Unfortunately I do need to use an array. If I figure it out I'll post back.

I realise what I asked is impossible, Friday afternoon wishful thinking.

The number of rows the user will need is not known at build time hence the array. Perhaps there is another way of getting what I want.

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

Well. We are about to argue about semantics.

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

Note that this invoke node will not clear tables or combo-boxes which I've always found infuriating

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.

I wouldn't recommend the library refnums for anything other than editor support. They were never intended to be in the runtime engine -- they got added in LV 2009 to support TestStand talking to LabVIEW, and, honestly, I think including them is a bit misleading. The library refnums all go through the project interface. The functionality that they were designed to promote is not the runtime reflection that an OO programmer might be looking for, but instead for the editor capacities that a LV add-on author might be looking for. They require a swap to the UI thread, which is an obvious drawback.

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.

Thanks for another idea!

Unfortunately this approach is to slow for my use case. My first benchmark showed about average runtimes of about 300ms for the file/project api and about 0.1ms for the flatten/parse version.

Since my goal is to analyze every message object sent inside the application, speed is very important.

Our use case for this is a complex object oriented messaging architecture, in which we want a debug module to be able to show the difference between "Module1.lvlib:Init.lvclass" and "Module2.lvlib:Init.lvclass".

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?