ShaunR

I've seen it a few times too. Fairly random "feature"

Just need to up the PHP memory limit a bit (I bet it's set to 32MB)

For those who may be interested, I finally found out what was happening. After working with NI and going back and forth, it was considered a glitch (apparently also happening in versions of LabView more recent than mine, 8.5). I discovered that putting anything on top of the chart (label, line decoration etc.) caused the problem. The lines and labels you see on my chart were added on top as decorations and lines. Removing them, resulted in perfect behavior.

Did they give you a CAR number for it or was there already one registered.?

Hello LabVIEW Community.

I'm gathering some research and would like to know the following:

1. Do you use LabVIEW Snippets?

2. How often do you create new snippets?

3. How do you organize your snippets?

Just general answers. I'm just getting a feel for how the community is using this feature.

Thank you in advance.

Ryan

I do sometimes use them to post to LAVA because creating a snippet is less hassle than uploading a VI. But as I use google chrome, they are just not worth the bother to use generally (open image in a new window, resize the browser, drag to desktop, find a diagram, drag into vi from desktop, restore browser). If a snippet is posted on LAVA it has to be something pretty special for me to try and get it in a vi. I normally just pass them by.

If there is a reason for the child class to be loaded into memory, then yes, all of the class' members will be loaded into memory as well. However, loading a parent class isn't a reason to load child classes, even if the child classes have overriding methods.

Indeed. But to call a child it must be laded at some point either prior to the actual call (pre-loaded) or when the call is executed (lazy loaded). Like you said. We don't have visibility of the mechanics. But from the quoted piece of text, it seems that the purpose of the dynamic dispatch table is to maintain a VI reference list. and the object passed determines from which VI reference the method is executed. I am speculating (in response to the OPs observations) that to get those references it must load the VIs. From that, I am suggesting, as it doesn't know which classes "will" be called until it actually happens. The algorithm pre-loads all classes than "can" be called to populate the table.

The alternative (I cannot see any others, but there may be one) is you place an object on the wire that indexes past the end of the list triggering some loading voodoo when the call takes place. As you say, you cannot load a part of a class, so the latter could be a long wait as it loads every method for the new class (and dependencies) - right in the middle of your code executing.

The former would explain the OPs obserevation. The latter would be a very good reason not to use DD-especially on real-time systems.

Agreed. If I'm going to make a web interface for a device, I want it to be open to not only windows desktops, but other operating systems, as well as IOS/Android/Whatever devices. Why would I develop a platform locked web interface when I can already develop a more open stand-alone application?

The Web UI Builder looks slick as can be, and I really think it's a push in the right direction (thin clients), but I don't think using silverlight was the way to go given how html technologies have evolved and non-desktop platforms are becoming more predominant every day.

Yup.

I think also that the explosion of Ajax enabling "desktop style" dynamic web pages that run in the browsers native engines has put the nail in the coffin of external run-times like Silverlight. Things like flash Java etc are really now only used as presentation tools rather than dynamic page content. Try and find a site now that doesn't have jquery for example. Sure it's not graphical. But JavaScript developers are the new C developers;10-a-penny and cheap.There are many data streaming sites now using JS push servers for things like real-time stock quotes.

In terms of graphical presentation (like graphs etc). I'm looking at Google maps. Not so much in using it as-is. But the technology. Javascript based with bi-directional feedback allowing zooming, panning, and overlays. All that a web-page requires is the DIV tag and a link to the javascript and the browser does the rest.

Now. If there were a tool (like the web-builder) that created javascript (like the embedded toolkits create c). I would be getting very excited. I could then use it to create front ends for my Labview websockets. Have to be free of course.

I'm pretty much in-line with Cat here.

I think "new" business is driven by latest features, gadgets and spin. But thats due to competition from other products. But I would tentatively wager that the vast majority of LabVIEW income is from SSP which, as it's name suggests is for value added Service and Support - a recurring income stream with almost no additional overheads or cost. I think most "real-world" Labview programmers (if they have any sense). Only upgrade to a later version if there is new feature that achieves common requirements that were impossible or at least very difficult in the older versions (very rare-but I would put the events structure in this category). Or a customer requires it. Version changes are a very high risk proposition and I think most opt for "better the devil you know". But that doesn't stop us paying our SSP for the exemplary service NI provides and to be able to pick up the phone and talk to real engineers who have real product knowledge. I, for one, pay my SSP for this. Not to get the new versions.

If I were to rate the importance (to me) of new features and reliability on a scale of 1-10. New features would be 2-3 and reliability would be 8-10. New features don't cost me time, money or reputation. Unreliable software does. Nor do I see them as mutually exclusive. Get the software reliable then add features. Adding new features to unreliable software only makes unreliable new features.

In times gone by, I used to be more cavalier about upgrades because a new version would come out, with very few known issues of any consequence and if something was found, a patch or new version would be very quick to follow-certainly within a project time-frame. Now, however, the cycle is very slow and I've yet to see a SP2 fixing my 2009 version before 2010 was released (which probably hasn't fixed bugs I'm concerned with but as sure as eggs are eggs will introduce new ones).

Nope, at least that's not my understanding. You don't have to know which child object will be used to override the base class at compile time.

<snip>

If child classes had to be known at compile time many plug-in frameworks would be impossible using LVOOP.

"Each object traveling on the wire carries a pointer to its class information (refer to the "What is the memory layout of a class?" section earlier in this document). That class information includes the "dynamic dispatch table," which is a table of VI references. Each class copies its parent’s table exactly. It then replaces the VI reference for any parent function with its own overriding VIs"

I'm thinking in the specific case of overrides. From what little I understand of dynamic dispatch in general cases. It seems no different from a polymorphic VI i.e it chooses the implementation at edit time).

But for overrides (which Is what I perceive to enable run-time polymorphism) The statement above seems to suggest that the class VIs are already in memory (For the table to have the VI reference it must, I'm assuming, have already loaded the VI's in the class with an equivalent of "VI Open reference" and resolved any dependencies). If it is, as I think you are suggesting, that it lazy loads from disk with a sort of "load on first call" then that would (whilst maybe convenient for plug-ins) have a dire performance impact in many cases. Maybe the "lazy-load" is the fall-back mechanism if other methods are unable to identify the call chain to populate the table (I think the project/class manager is doing a little bit more than we might think).

I suspect (but don't categorically know) that all the class VIs are actually loaded in the case of overrides and, unlike in the general case where it is known before-hand what VI's will be used;;all VIs that override are loaded just in case it may be used at run-time. I suspect also that you can't just load a part of a class (i.e just the VI's used in overriding) so that the entire class must be loaded. This view would seem to fit with what the OP is seeing hence my question about the use of overrides.

Requiring to package in a new format in a later version just to get normal performance is insane. Apart from that 2010 is 3x slower at loading sub-panels than 2009. I would expect a whole application of thousands of VIs to take less than 45-60 seconds to load (unless you are loading across a network) and that's if they are not in memory to begin with

Do your accessors override the base class by any chance? I believe dynamic despatch (required for overrides) might mean that depending on how you are calling the methods, all classes may have to be loaded even if they are not actually used since it is not known at compile - time which child will be used to override the base class(dynamic dispatch is just a VI selector after all and I doubt it loads from disk when you first call a particular method). Perhaps AQ can shed more light on that.though. There is some interesting reading here under The Design of Class Methods.

It could also be something to do with the fact you are using VITs and creating a new instance which needs to be cloned (can't think of a good reason why though). I would try what Daklu was suggesting and convert the VITs to VI's (re-entrant or not) just as a test to see if it improves. In theory, if the application has loaded the classes at start-up, then they should already be in memory so there should be no reason to re-load from disk so the only overhead should be the VIT itself (which should be quick).

Thanks, this is really usefull.

Do I need a terminal emulator to send these commands, or can they simply be send by the VISA-write function?

No. Yes.

Check out the attachment at the bottom of this thread.commands to a GSM modem using VISA

Hello,

I have to connect two computers for data transfer. However since none of these computers will have normal internet acces, the only way this can be done is through satelite communication.

I have two satelite phones available which can be connected through a COM port to the computers. I have been able to transfer the data with VISA, when the connection between the two satelite phones is running. However since I have to pay for this communication per minute, and data only needs to be send once every 10 minutes or so I have been looking for a way to make LabVIEW initialise the connection between the two phones when data becomes available, and terminate it again when the transfer is done. I can't seem to find any way how to do this though.

I hope anyone can help me with this.

Thanks

I'm presuming that when you say it's connected through the COM port. The phones have a built in modem (most modern ones do). In which case it is just choosing the appropriate AT commands. (e.g ATD+12125551212; to dial and ATH to hang-up)

Sounds similar to an issue I had once. The provider changed the server I was hosted on and required me to update my NS records to the new server. I added all the new ones but I missed deleting one of the old ones (although I could swear blind I got them all). The result was intermittent DNS lookups because there was a 1 in 3 chance the lookup was done through the old one..

The background colour property node accepts RGB and Alpha values between 0 and 1 (i.e 1/255).

+1 for test-stand.

However. There is an example of board testing using using OOP shipped with labview that will give you a good start (just put "object-oriented " in the examples finder)

The regular expression primitive is actually an xnode (the tell-tale busy cursor whilst it generates the code).

Once the code is generated by the xnode your string is passed to the regex function in the labview.exe (MatchRegExpEfficient). But. When it' returns, it is parsed in Gcode using several split string functions to split out to the terminals. So not only do you have a regex engine overhead (which may or may not be the same as match pattern - i don't think it is). But you also have 4 or 5 (more if you grow the terminals) additional split strings.. So at best, the regex function would be 4 or 5 times slower, even without the call to labview.

But match pattern (as blazingly fast as it is) becomes unwieldy and difficult to use on selective string matching (where something may or may not be present - like area codes in a telephone number). That's when you need the regex.

NB:

Your image shows 75k for the match pattern and 210k for Tons.

Thanks, I did searching before posting but couldn't find that thread for some reason. I tested it on Windows 7 32 and 64 and it worked as expected.

I remembered the discussion, but had google it to find it again

It seems to me that detecting the "Bitness" of the OS has to be OS dependant.

So you would have to write individual code for each OS (eg. using a CDS).

As long as NI does not provide such a property, your VI looks like a very usefull way to get this information (assuming we are on Windows, which is true in 100% of *my* use cases ).

BTW: You are talking about "Application.TargetOS". I think "OS.DetailedName" is much closer to what you are looking for (but still not close enough, since it does not talk about Bitness).

rolf posted a VI on this thread Determine 32 or 64 bit OS

It's the same method used in other languages and uses win api calls.

Must admit I I havn't had a lot of experience with DETT (labview tends to have very pungent code smells and my DETT tends to crash quite often ). But.....

If you put them in conditional statements you can turn them on and off from a conditional define in the project. You can then build with or without just by changing a value and the compiler will take care of the rest.

That is fine, but it fails to meet the design goals.

Indeed. One design goal was "I want each loop to have its own child class". So it could never acheive that.

You are using named queues. So, when you send a message, you must know the destination of the message and choose the right queue.

As you must do with the class. The software doesn't know the developers' intentions, and must have a method for the developer to instruct it to send to the correct destination. The class does this by the developer laying down the appropriate class constant. The queue, by the developer laying down the appropriate string constant.

Also, to add more messages, you must modify the execute function to add more cases. And, if you misspell the message command text, it will not work.

That is a nature vs nurture type of argument. I would be saying single maintenance point, reduced VIs to debug, less VIs to implement., more code re-use. You would (probably) be saying more re-validation, more chance of breaking existing functions and more code re-use in 10 years time etc, . Granted spelling is a weakness (tell that to the JKI state-machine...lol) but the the upside is you can do other cool stuff like construct messages on the fly, automatic re-routing and scripting with minimal changes to the posted example.

.

So, it might be smaller, but it really is not the same architecture and does not have the advantages that LVOOP gives you.

I'm not sure of what advantages you are talking about here (I don't see (m)any up-sides with LV OOP implementation for this - not the architectural implementation, the LabVIEW implementation mechanics).

But I'm not here to derail your thread. Just add a bit for us non-POOP heathens. So we can probably leave it at you're designing a LVOOP messaging scheme and I've shown a functionally equivalent classical alternative for what you have so far.

By the way its Rhythm not Rythem

OK. you get a point for being a smart arse

Cool. I have done stuff where the Main App sends Status Messages to the Splash Screen. Can you go into detail about how the hierarchy works here?

Does the Splash Screen load the modules, then open the Main App so th modules stay in memory, then the Splash Screen goes out of memory etc... ??

Cheers

-JG

Pretty simple really.

The two main points are that the main VI's FP is hidden and it sends a message to the splash to tell it it's loaded.. You can either allow it to load in the background, or load it sequentially (I prefer the latter in case hardware checks fail).

The splash screen itself just loads a config file (usually a section in the main app coinfig), iterates through the file list, dynamically loading (but not closing the ref) on each iteration. You can wait til finished or not depending if you want it sequential or background loading. When it gets to the last one in the list it shows it's panel if the "ready message was received (queues work best for that) As each module is loaded, it remains in memory so you get incremental loading of sub-vis and when the splash closes, any that are only used by the start-up modules will be disposed of and any that are used by the main app will remain (that's why I don't like namespacing and generally prefer llbs or directories over lvlibs).

The key really is dynamic loading which means the splash is very quick to show regardless of the number or size of modules it needs to start up. Comms from the modules can be anything you like, queues, events even pass a string ref via thier front panels when you launch them. I tend to use named queues though (see my Non OOP version of the .Message queue and replace the A,B with the vi name or Dispatcher for my most used architecture which revolves around 1 VI).

Pretty basic I know, but it works.

I have other apps where the Splash Screen can create a log of the session, checks for driver version (DAQmx, dotNET) etc...

I would like to add more features into the reusable code that I have in these other applications when I have the time.

Good idea about using a VI tree!

I do something pretty similar (without the vi tree). Only I also have a "config" file that tells the loader what to load (I usually have modules that need to check 3rd party hardware as well as DAQ etc, and feed that back to the splash so you see "Loading....[module name]") - they change from project to project)

Nice! I leave town for a few days and this is what happens...

10 points for trying, but my wife beat you to this about 6 months ago

I bet she gave you a better dress-sense than I, too.

An for all the heathens out there. Here is the NON-LVOOP version (just changed the VIs)

.

Even I was shocked at 1.13MB for the classes implementation (the nonlvoop is only 108K)

You can write to the description of all (or one) of the vi's in the llb when you build (run a separate VI or link in with the builder). It's a shame the VI revision number or history isn't as flexible......., then it might actually have a use.