Shaun Hayward

One thing that I've started doing with the DVR-inside-LVOOP scheme is using an IPE Structure to (un)bundle the DVR reference outside of the IPE that (de)references the private data. I like this a lot because it keeps the object/reference/data wire in straight line without any branching -- it seems to have the best "style". Note that I named the DVR "ref" to keep the (un)bundle nodes small in width.

What do you think?

Looks nice - I frequently do the same thing - using the IPE structure more for style than its pure function - it is a lot less messy than index array followed by wiring the original array and the desired index across the code to the Replace Element function.

Shaun

I've got a bit of a strange thing happening (just in case it's the culprit, I'm on Vista Business)...

If I open up a VI's icon, copy a selection, go straight to another VI and try edit it's icon (to paste the copied selection), I end up with the wrong icon in the editor:

http://screencast.com/t/l8LZAe8Ee

When I open the icon of the second VI, there is a very brief moment where the correct icon is shown before it is replaced with the previous VI's icon. Its also worth noting that clicking OK causes the previous VI's icon to be applied to the current VI, and that I do not get as far as Edit->Paste on the second icon.

Any ideas?

Thanks,

Shaun

PS. X-Post to NI Icon Editor discussion as this seems to happen with both this and the regular NI icon editor: http://decibel.ni.com/content/message/8079#8079

The original icon editor is property of NI so we can't (and shouldn't) host it here, and I don't think a page exists where you can download it separately from the LabVIEW install.

Ah, I'm guessing that's why the link dissapeared from the original thread then

Quick question: Could you add to the downloads a link to the original icon editor in case people want to uninstall your version?

I have also seen different behavior between USB-rs232 and RS232 in the computer.

I've also got to agree with Clio75 - we have had a lot of issues with various USB->RS232 adaptors (as have several of my customers). Internally, we now stick to a particular chipset that we have found to be the most reliable because overall its just less headache. (in our experience has been that the FTDI based adaptors seem to be the most reliable, although I'm not saying this is going to be the same for everyone!).

One more thing, for what it's worth, in a previous life, when LabVIEW was not even part of my vocabulary I we also came across similar issues with a variety of hardware/software platforms - whenever someone had a problem with a COM port, the first question was "are you using a USB adaptor?"

Shaun

I get the same thing (using Outlook '07 as my RSS reader) - my Deleted Items is getting huge!

Thanks guys! That's very useful to know :-)

Shaun

Hi Adam,

Does the same thing hold for user.lib / instr.lib, or if we use these shared libraries without providing custom destination will we end up with a huge hierarchy. e.g:

Will it be:

A:

application.exe/main.vi

application.exe/subfolder/subvi1.vi

application.exe/vi.lib/vilibVI1.vi

application.exe/user.lib/_OpenG/openGVI.vi

application.exe/instr.lib/Instrument Driver1/initialize.vi

or

B:

application.exe/Users/ShaunH/Documents/Projects/MyApp/main.vi

application.exe/Users/ShaunH/Documents/Projects/MyApp/subfolder/subvi1.vi

application.exe/vi.lib/vilibVI1.vi

application.exe/Program Files/National Instruments/LabVIEW 2009/user.lib/_OpenG/opengVI.vi

application.exe/Program Files/National Instruments/LabVIEW 2009/instr.lib/Instrument Driver 1/initialize.vi

(I REALLY hope it's A)

Hey guys,

I have cracked it - fixed the solution and potentially found something that may have been causing the issue...

1. After installing LV 2009, I ran VIPM to put the OpenG stuff into the new version. Doing this, It seemed that not all of the packages were installing properly, so I gave up with the intention of looking further when things are a little quieter in the office.

2. Looking in the QuickDrop folder, I noticed some of the VIs had different dates (which was I thought was a little odd), and more importantly there was a VI called QuickDrop Launch Window - BACKUP.vi

3. I opened the QuickDrop main launch window directly (dropping it as a subvi to avoid the run when launched effect) and tried to view the BD (and couldnt due to password protection). When I couldn't I deleted it and was prompted to save a couple of files... one of which was called Enable VOice COmmand and appeared to be something associated with LV Speak.

4. I put two and two together, removed the QD Launch Window and the Enable VOice Command VIs, and renamed the BACKUP file.

5. QD now works with shortcuts! :-)

All three are there and none have a broken arrow.

Shaun

I found the August '09 driver CD on NI's ftp site at ftp://ftp.ni.com/support/drivercd/2009.08/ which has a lot of 2009 compatible drivers (I dont have a RIO to hand so haven't been able to check your specific issue).

Shaun

I've put a call in to NI already (and an app engineer is also looking into this), but thought I would ask here as well:

For some reason, on my Vista system the new quick drop ctrl+D/t/u shortcuts are not working...

For example, if I click on a subVI (so that it becomes selected), press ctrl+space to launch quickdrop and then press ctrl+d, instead of the desired affect I simply see a letter D appear in the quickdrop string control (with the autocomplete finishing the line as DAQ Assistant).

Any of you guys have any ideas what might be wrong?

Shaun

Thanks

Does anyone know where the version of DAQmx that supports LabVIEW 2009 can be downloaded from?

On the ni.com downloads site, the newest version seems to be 8.9 and when that setup is run (after the whooping 1.2Gig download) it states that it supports LabVIEW 8.6 etc but not LV2009.

Thanks,

Shaun

It is also part of a lvlib's protection mechanism - In an LVLIB you can specify that a VI is "private", ie the VI can only be used as a subVI in other VIs that are also part of the library. Therefore, the VI in question needs to know what library it is a member of so that LabVIEW can check with that library where the VI is allowed to be used.

I tend to leave it on for that very reason - under normal circumstances every single error should be trapped and either dealt with internally by the VI (if its expected - ie EOF error etc), or sent out on an Error Out terminal. However, it's all to easy to forget to wire an error terminal (esp. when deadlines loom and your trying to code at warp speed - and yes, I know no one here does that... ever ) and the automatic error pop-up can really speed up tracking those things down.

Shaun

I would do one of two things depending on whether I simply needed to obscure the data, or properly protect it:

1. (simplest) Byte-Shift file

Once you have closed the config file, re-open it as a binary file, and add a known offset to each of the characters (convert the string to an array of U8's, add the offset and then convert it back to a string). This will make the file pretty much unreadable which should discourage people from messing around.

2. (most secure) Encrypt file

.NET comes with a whole bunch of cryptography functions which LabVIEW can call, making it possible to implement formal encryption methods without having to code them yourself from scratch (http://msdn.microsoft.com/en-us/library/system.security.cryptography.aspx). This method takes a bit of understanding of how .NET works and how to work with it in the LabVIEW environment (and also means that the application will be Windows-only) but results in properly secured data.

Which ever method I chose, I would probably write the data to a new, encrypted file, and then delete the original (or, if I was using the LabVIEW XML Schema functions, I would avoid writing the unprotected file in the first place and do the offsetting/encryption in memory before writing the file). I would probably also wrap al of this in a new VI called "Save Config Data.vi" or something so that the rest of the application does not need to worry about how the data is being written to file.

I hope this gives you some ideas.

Shaun

When building an installer in LabVIEW 8.6 on a Vista machine with UAC turned on that includes additional installers (such as DAQmx, VISA, etc) LabVIEW will ask for the DVDs each time you build the installer regardless of the "cache this distribution" check-box.

This has been filed with NI as CAR#164405, and I havent had chance to test it yet, but an alleged workaround is to either:

A) Disable UAC, or

B) Run LabVIEW as an Administrator

I hope you guys dont end up in the embarassing situation I ended up with a couple of weeks ago...

(final integration at a customer site where an installer was the main deliverable, installer started asking for DVDs despite "caching" them before I left the office, and I realized that I ended up with a Q4 08 instead of Q1 09 DVD that was put in the wrong pack by mistake)

Shaun

that's far too addictive to be linked to on a public forum!

... I ended up loosing 45mins of my life last night - damn you flash games!

QUOTE (Aristos Queue @ Apr 28 2009, 02:38 PM)

The property node does exist, but it doesn't work in the runtime engine.

You can get the version in a very strange way... take an instance of the class and flatten it to a string. Then read http://forums.lavag.org/Flattened-LVOOP-Class-t11256.html&p=47637#entry47637' target="_blank">this post for instructions on how to get the version number out of the flattened string.

That's the only mechanism I can propose that will work in the runtime engine.

I thought of another option... you could read the XML file directly. The class version number is stored in plain text in the .lvclass file.

Wow - you responded quickly - thank you very much!

That seems to have got me out of a bind, and in case it helps anyone else, attached is the VI I put together (LV 8.6).

Out of curiosity, do you know which method (file or flattened object data) would be faster / more efficient? (I'm thinking that it probably depends on how big the class file is vs how much data the current object is carrying around with it)

I have a LVOOP based plugin architecture (ie my customer can supply different drivers in the form of LLBs depending on what hardware they ship with the software)... Now, I would like to implement a method of my base class called GetDriverVersion (or something to that effect) so that my plugin-in manager can display to the user what version of a particular driver they are using (for debugging purposes / making sure the driver matches the hardware).

This led me to thinking about the class version numbers - it seems to me to be logicial to use the class's built-in versioning so that I only have to set a number once and that number will also help with transitioning to new versions etc. However, I cant seem to find the property node (at least I would presume it is a property node somewhere). Am I looking in the wrong place / anybody have any ideas where this information may be hiding?

(oh, and whatever method I use has to be supported in the run-time engine)

Thanks,

Shaun

In a holder on the back page of the course manual should be a CD with all of the necessary VIs etc for the exercises.

Shaun

We use a really simple svn server (that is still free) called VisualSVN. It allows us to specify permissions on a per folder level (it may even allow per file... I cant remember) and supports Active Directory and groups etc (so we can, for example allow all Programmers read-only access, all managers read-write access, and individual developers read-write as needed). Then, for network transport it uses https so that's encryped and finally, it uses the same usernames and passwords as everything else so our developers dont have to try and remember even more passwords.

With this approach the actual data is not accessible directly - it is kept on the server and only the user account that the VisualSVN application (and local/domain administrators) can actually write to the data.

It works with all standard svn clients (although they do sell one targeteted at Visual Studio guys) as it is basically Subversion, Apache, a few bells and whistles tied together with a friendly GUI.

http://www.visualsvn.com/server

Shaun

QUOTE (Mark Yedinak @ Apr 8 2009, 12:45 PM)

No, I will have to give this a try.

If you typecast an enum to a u16 and wire it to a case structure you don't get the string values of teh enum so the cases are simply 1,2,3, etc. Therefore you lose the readability. Also when I have typecast a U16 to an enum it always seems to retunr the value of teh first enum rather than the actual value input.

One thing I have found when casting an integer to an ENUM is that if the two are not the same representation (ie both U16 or whatever) then I get the problem you describe (always equals the first item)... So, I woud say double check that both the integer are the exact same data type.

Shaun

Hell yeah! It's currently way too much of a pain in the butt!