ShaunR

+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

Yes. It supports 2009 x32 & x64

That means it has only been assigned a generic class. If you right click on a control (for example) and "select IVI class" then it will return that class you choose.

There's a couple of property nodes TypeClass and SubTypeClass which will give you the class names. Is that what you are after?

It's bundled as part if the Vision Acquisition Software

Website is back so, so read the page. From what I could see, the OP must have already done that as it is working. I'm ot not really sure if x-domain is relevant to that anyway. All the XMLHTTPRequest would be doing is sending a "GET" to the server on the same domain as the page was served (just as if the page was refreshed....but without refreshing it). It's not as if it would be opening an 3rd party site in an IFRAME (which is where you get problems). I'd be interested to learn what problems you encountered and (probably more importantly) what you did to get round it.

Probably not..lol. I don't have much experience with streaming from the NI webserver (for example). I prefer other methods like TCPIP or websockets for that - they don't have such issues and (IMHO) offer better performance. But for normal HTTP requests (on the server side) it can be as simple as a PHP script on the corporate server that uses cURL to resend the request to the NI server and relay it back to the browser (easier than trying to get proxies and stuff authorised and set up by IT). As such, the corporate server is indistinguishable from a browser as far as the NI web server is concerned (and if you want , you can do caching and stuff too). It keeps IT happy since their portal is still the entry point and secure behind their firewalls and security policies, It obviously has an impact on performance - but it's not much for get/post methods through an Intranet, It also makes aggregation of multiple LabVIEW machines a breeze. It's one of the few scenarios where IT are actually useful