ShaunR

"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).

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

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)

Just right click and select "generate code". Nothing clever. Even I can do it

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.

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

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.

Indeed. One design goal was "I want each loop to have its own child class". So it could never acheive that. 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. 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. . 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.

OK. you get a point for being a smart arse

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).

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)

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.

Or you could just use a string (SCPI format works well) and save yourself 3 weeks work.

I want one of those VIs! I can use it when my "mute manager" vi fails. But I know what you mean. I find it a bit "irksome" (not only in labview but in other languages too) that it is assumed you have 3rd party dependencies installed.

It's always good to give a background on what you are trying to achieve. I means you will get a more focused answer. So. You just need single pulses (an event generator) rather than a pulse train. There are quite a few ways you can do this in labview. But I've modified the example to just give one pulse as you are familiar with the vi. It's fairly straight forward. Set the OP high. Wait a bit. Then set it low. For ryou incoming pulse. Take a look at DAQ events. (There is an example). You can then wire the digital out to the digital in and check to see that you can create and detect the pulses.

That example is to demonstrate manually toggling single lines. I think you are trying to generate pulses. Yes? Look at the "Cont Write Dig Port-Int Clk.vi" in the examples. Change the "Pattern" to 0 and 128 and then run the vi.

Surprising! Set up the "mod_expires" then it'll be really humming along. LAVAG NEW LAVAG OLD

And here's the one for IMAQ