Neil Pate

Like Lewis I also took the exam today, however I chose not to use the sample templates. Same result though, I and also ran out of time 

Glad that helped you. I also prefer the fact that it creates a single setup.exe file, rather than the way the NI installer creation creations (I think) .msi 

Inno setup makes it quite easy to run other things as well as part of the setup, so you can install (for example) .net or the LabVIEW runtime etc.

Wow, interesting program! I downloaded it and am looking through the documentation/examples. I'll give it a try tonight! Any "gotchas" I should be aware of? It looks like I can modify some of the example files and run them from the same directory as my built application.

I use Inno Script Studio to generate the actual installer. There is nothing I can actually think of that caught me out, other than it just took some time to figure everything out (like admin rights, banner graphics, unlocking directories etc).

I recently had a lot of problems with using the App Builder to create an installer. In the end I gave up and used Inno Setup and was pleasantly surprised.

Mike, not sure if this will help you, but if you add

NI_Appbuilder_logging=TRUE

to your LabVIEW.ini file then you will get a comprehensive build log for your .exes and installers. If your installer is failing to build just scroll down to the last line and see if there is a more verbose error message there.

The log file is in the same directory as the .lvproj

Hi Lewis,

I am also taking my CLED next Tuesday (you taking yours in Newbury, right?) and will probably not be using the sample projects, although I may borrow bits and pieces.

You are probably right in that the exam will be quite a close match to the sample project, but I think you would have to spend too much time modifying it to meet the new requirements.

The offending call would be NI_WebServices.lvlib:PNG Data to LV Image.vi. It converts a byte array to the LabVIEW imagedata.ctl cluster typedef. Without that VI, I think the only built in way around it will be to save the data to disk and use the Read PNG File.vi method. Not sure if this would be too slow for you.

 

Why the memory version of the PNG converter is in a non-base library but the disk version is is beyond me. Ridiculous if you ask me.

It would be nice if all of the VIs in the NI_WebServices.lvlib were not password protected. 

Would you mind saving it for LV2010? That is all I have at work so can't open this vi.

Thanks,

Greg, I do not have 2010 installed either, but here is a picture maybe you can recreate it from this?

Looks neat. Am going to tinker with this .net control too if I get a chance.

Just a heads up, I know this was just a proof of concept, but you probably don't want to be creating all those objects inside the loop.

In the same vein, services like Dropbox can also prove problematic though not quite as intrusive.  I sync many projects with my laptop via dropbox and during builds LV generates files and wants to delete them and rename them. The problem is that my machine/internet/dropbox service is running too quickly about 75% of the time and accesses the file during the build process which generates an error or just slows things down in general.

I had so many problems with Dropbox (and SugarSync) trying to sync source/builds across machines I gave up completely and now just rely on my VCS.

Tim,

Sorry I have just looked at the screenshot I posted, there is a bug in that the case structure downstream of my variant cache lookup has a False constant wired to it. This was for testing purposes when I was comparing the speed and correctness of the new algorithm. This constant should actually be replaced with the output from the variant attribute lookup.

Neil

Hi Tim,

I have already cloned the repository, I just wanted to be polite before pushing back my changes.

There is actually logic checking the dependency cache, its just before the case structure. If the attribute lookup is not found then it is added, this is how items get in the cache.

At the moment I am totally snowed in with work, so I do not think I will get time for several weeks (probably longer) to tinker with this anymore. Unfortunately for the project I was going to use it in has several thousand VIs and performance with this is just a bit too slow, so I ended up writing my own for my particular use case. I am most interested in being able to interact with clone VIs, so I used the FGV method and add the VI names to a cache when they are launched. This works really very well for my application, so is probably about as far as I need to take it for now.

I think that my problems may have started after trying to change the folder location of my class hierarchy of VIs and supporting files.  The project displayed conflicts.  I couldn't figure out how to resolve the conflicts, so I was forced to put everything back in its orginal folder location on my machine.  It's a dangerous situation that we can't smoothly relocate nor rename OOP VIs, files, and folders.  NI needs to test and debug all common code maintenance maneuvers with OOP.

 

I could probably fix my problems by reconstructing all my classes and their VIs, but that is a huge amount of work for what I've built.  For this project, it looks like I'll have to stick with only accessing object elements using the Property Node.

Joe, I was able to fix my issue by re-creating the single VI that was not working properly. Thankfully I have only seen this issue on one occasion, but now several others have also reported very similar problems. This is not a very satisfying situation where you no longer have faith that the code is actually going to do what you tell it to do... 

Eeesh Neil,

 

Did you ever get to the bottom of this or just re-create and move on. I've got the same issue here this morning (least I think it's the same). Constant bundled in updates the cluster, wiring in a "variable" does not. Probed the wire, input data is valid. 

 

Re built the VI and moved on. I had seen crashes too when making changes to the class so perhaps like you we've managed to upset LabVIEW.

 

I'm moving on the next issue but this is leaving me with a prickly sensation on the back of my neck, all is not well somewhere.

Sorry Chris, never got the the bottom of it. I am glad I had read this thread before it happened to me as otherwise I would have thought I was going crazy!

I have a suspicion (based only on a tiny bit of evidence) that the problems arise when renaming class VIs. I am pedantic about having the VI name match what the VI is actually doing, so will often rename a VI as my code/API iterates. Now normally this does not cause any problems, however I have seen instability when I rename a VI to something that a different VI used to be called. It's like there is some form of stale code path somewhere that gets invoked.

I did not try cleaning out my VI Object cache, that may have helped...

Also, in the past (LV2011) I had some success with a crashing class by erasing the class mutation history. Again I did not try this this time as it was just quicker to recreate the offending VI from scratch and move on.

I usually unbundle and then rebundle. It depends... sometimes I do but it depends on how deep in the call hierarchy the code exists in.

If I have a Manager type class then I normally like to not expose the inner working (i.e. private classes) so that the "Block" class never actually gets exposed to the outside world, i.e. there is no get/set "Block" accessor in Executive Functionality. This can be a pain though as it often feels like you are writing the same method for various levels of the hierarchy. 

Yeah I also think something is fishy. I know Registry IO is cheap, but I would prefer it not to be going on all the time. Perhaps will try and re-install/repair the License Manager

Didn't know about that option in the LM!

Just checked it, and mine is blank (as I would expect as this PC has never been part of a volume license scheme).

Hmmm....

Just curious, does anybody know why LabVIEW.exe is querying some Flexlm License Manager registry keys (which do not even exist on my PC) very regularly?

See attached picture.

Hi all,

If I get time I would like to refactor "Get All VIs in Memory.." that and its parent VI to remove a lot of the duplicate operations and array manipulations. For now though an easy performance boost is to cache the VI Dependencies. I have used variant attributes as a quick and dirty cache, as shown. I get approx 50% speedup for large projects (> 2500 VIs). With a bit of thought I am sure it can also be applied to the other temporary arrays that are used in this VI.

Comments? The VI attached is saved in 2013.

Get All VIs in Memory Including statically-referenced Reentrant Clones.vi

Today I learned you can pass an I32 into the To Upper Case prim. Did this totally by accident.

Has anybody ever used this feature before? 

I always put File-->Exit on every application that has a menu-bar, however my personal preference (as others have also said) these days is to handle the Panel close event so I put in both.

To me the only no-no is a big fat Exit button on the GUI.

Hello,

 

I have successfully built my application with the application builder. The application is a plug-in architecture where I have paths to different .lvclass files internally in the .exe file which I have set to "always included" in the build. The different classes will be loaded dynamically

 

When I run the executable on my development machine it start up and everything works fine. But when I want to run in on another machine with only the LV runtime installed I get the following error

 

Error 22A8 "Error requires full development system to be solved"

 

How is that? anyone know what that mean? I don't find much information about this when I search on the internet so i'm kinda stuck now.

 

Im using LV 2011 sp1.

 

Best regards

Thomas

Have you tried running the executable on your PC but with the source directory renamed to something else? This can help diagnose if some VIs/classes etc are not being included in the exe but are on your disk so the built application works fine. Also try move the exe somewhere else (on your PC) as if the application has relative paths to source code VIs it should then fail.

Below the top-level cluster I tend to have objects (or arrays of objects) whose methods do the “heavy lifting”.  The typical “state” will unbundle only a couple of things and call a couple of methods.  So I am doing something similar to what you do.  But the problem with the top-level cluster is that it is a grab-bag of everything; UI details mixed with INI file details mixed with analysis details.  It’s not cohesive.  

 

Because the objects/typedefs that make up the top-level cluster ARE chosen to be cohesive, it is rare to need more the a couple of them.  If you find you’re unbundling six things, that’s a good reason to stop and consider if some of them really should be a class/typedef.  But because they really naturally go together.

OK point taken. I think my uses of the JKI template are much more localised (maybe the word I am looking for is specialised, but even this does not really convey what I mean, perhaps what I just mean is "simple") so my private data in the shift register is a bit more cohesive. I do not have a cluster-saurus with myriad elements.

I actually never do that.  The main cluster is a set of data related by being “stuff this QSM needs”, rather than being a cohesive single thing.  Even when 90% of it is a cohesive thing (and then that part can be an object), there will be extra bits of data (update flags, say) that don’t belong in it.  So I never make the full cluster a typedef or object, even though it is mostly composed of typedef/objects.  

So what do you do when you need to execute a reasonably complicated bit of code which requires various bits of "data" in this cluster (i.e. a portion of code that screams out to be made into a sub-VI, which in my opinion is virtually anything non-trivial)?

Do you unbundle the specific elements and pass them into a sub VI? I know it may be frowned upon, but by having the cluster typedef'd I then just pass the whole thing into/out of a sub-VI. Of course you could pass in a non-typedef cluster but we know how that is going to end...

It would be nice if the template could include a typedef for the main cluster on the shift register, I normally end up creating one.