Neil Pate

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.

Just to chip in here, I recently had the same problem (2013 SP1). Bundling in a "variable" wire did not cause the class output "cluster" to be updated. Bundling in a constant (in this instance it was a string) did cause the "cluster" to be updated correctly.

Probably entirely related, editing some code in this class would cause the IDE to hard-crash, so I figure I just managed to get my code in a state that was not consistent.

I fixed my problem by deleting the VI that caused the crash and re-creating it from scratch. I think the inconsistency happened when I renamed a class VI to something that had previously existed in that class.

Yes. you can have multiple services. but you can only have one listener. You need a connection handler to offload the endpoints and I guess the NI webserver doesn't do that (never used it, so don't know for sure). It is, however, trivial to write your own.

I think this is actually possible in the IDE, but not in built applications.

In LabVIEW (and perhaps all Web Services, I am not sure here) the connection string is in the form:

host_address:port/WebServiceName/QueryString

so it just seems to me that something is redundant here.

You can infact have multiple Web Services on the same port when running in the IDE, but then I suppose there is only a single application (LabVIEW.exe) that is bound to the port. However as soon as you have built applications this paradigm breaks.

Something to add (note, this is just something I "figured" out, it is completely uneducated and could be totally wrong) on the handle vs a pointer to a handle...

Dealing with a pointer to a handle is a mechanism that allows the underlying memory allocation mechanism to do stuff like defrag or completely change your memory allocation without affecting your running application. Your application has a constant "memory address" that is the pointer to the handle. Then any actual requests to memory always go through the lower level manager (i.e. LabVIEW's memory manager) which actually does the translation between the handle that your app knows about, and the actual physical memory address.

No doubt I am using all the wrong vocabulary here, picture me waving my hands in the air to get an idea that I only have a vague notion that I know what I am talking about. 

Think about it. How should the OS socket driver decide to whom to send incoming data if more than one process was allowed to bind to the same port? Another related issue would be that anyone could then bind to any port and eavesdrop the communication of another application without the need for a promiscuous capture driver involved, which needs administrator privileges to get installed and started, so if an attacker has those privileges you have much bigger problems than listening on a network communication.

Sure, your comments pretty much echo my internal dialogue. I can't figure out what the point is then of naming the web service? If all traffic to the IP address and port gets directed to the single instance of the web service why bother identifying it by name?

This NI document confirms my suspicions.