Mads

This looks like a smart take on of what NI has posted as a "Current-Value-Table Reference Library". They have used functional globals to store the data instead of queues which makes it easy to access the list of available registers, debug etc. One of the weakest points of their implementation is the slow search it uses to look up the "Register Name" (they could use a binary search instead or use the search capability of variant attributes to dramatically improve this, but your approach gets that part for free from the queue functions). Perhaps the two efforts could be joined? PS. The polymorphic VIs do not have the "Allow Polymorhpic VI to Adapt to Data Type"-flag set so they did not work as I expected in my LV2010.

No, I'm not thinking about the System Replication software. In our case the PAC will be typically be a few thousand meters subsea so it is definitely risky. The startup executable needs to be a bootstrapper which will unload and load the main code dynamically. That way we can ensure that we get another chance if the new software fails...

Your window manager could monitor key events, and regularly check the FP.Open status of all VIs in memory. The default state of the window manager would be to poll the positions of the open front panels (and only those), keep a log of their correct position and move the windows back if the position has changed but has now settled* (and they are still open). (Ideally there would be a window move event for this that you could set an event structure to respond to, but there is not...). If the user hits F2 the state is changed to an ignore mode until F2 is pressed again - in which case the monitoring state will automatically correct the positions back to their original values again... On start and every 1-5 seconds from then on the window manager will run through the list of VIs in memory and update the list of VIs it should monitor. I did a quick test now with 750 VIs in memory and checking their FP.OPen property only took about 40 ms on my machine so it should be doable (the CPU load was not bad either). It is not required that you know which window is currently active. * You could reset the position immediately when a change was detected but that would probably look extra messy so I would rather wait another cycle to ensure that the window has settled, before resetting it...

I need to make the same thing for PACs and the PAC only runs one application so it will have to replace itself (because no network interface will be available - the new app will be transfered on a serial link). I thought I had seen a framework for this somewhere on ni.com earlier, but I cannot find it now. On the PAC it should be rather simple though. All this functionality has to do is to pick up the new file(s) once it shows up (or it is asked to), move them to their proper location (replacing the old executable etc.) - and then do a soft restart of the device (it does get a bit more complicated if such a restart is not permissible though; then the main app will have to be a dynamic launcher that graciously jumps from the old to the new code without interruption). The part that transfers the file is a separate issue.

Kudos just added to that idea. Thanks Ton.

How are you supposed to add an xcontrol to your user.lib / LabVIEW IDE? If you just copy the xctl file and its support files into user.lib the user.lib palette will get populated with the support VIs, but not the control? Should it not be possible to add an xcontrol to your library of controls just as easily as adding a standard control? In my mind the xctl file should contain everything and should show up as a control on your palette when dropped into the lib folder, but is there any such functionality today? PS. There are many x-controls that could have been part of OpenG e.g. (like the IP address string control, the intellisense string control (I think I picked that one up here once, but it is gone now)...but perhaps its due to a lack of support that they have not become that commonplace in toolkits etc.?

As others already say here your app needs admin access. I normally add the file association from the installer instead as it will always have the necessary access anyway.

Because if we did not then surely nothing would happen? The two options you mention are nicely formulated. In the long run I hope NI will implement the first one, but the second one would be fine too. As part of the first option you mentioned a third one, that's my straw of hope here: Perhaps there is an option where another type of method is developed, one that would have limitations in other respects, but which would solve this particular problem preliminarily (until a more fundamental rewrite has become inevitable, one that also allows for an optimal solution to this issue).

As LabVIEW programmers we are all fairly used to find ways to get around limitations in the development environment and G as a language, however at times those limitations and bugs are just so fundamental that it gets depressing. The graph axis bug that was introduced in LabVIEW 2009 was one such case: if you wanted to use graphs and upgrade to LV2009 you had to rewrite all your code so the scale markers would show up correcly, or wait for months to get the first revised version of LabVIEW (because even fundamental errors like that are not patched instantly....). The good thing about that example though was the fact that you could actually make a fix yourself. Well, now I'm depressed again, and this time the problem is much worse. There are ways to come around this one too, but man - it should not be necessary. I'm a bit surprised it has not been commented before, because it is not really anything new - but once you run into its consequences it is extremely frustrating... The problem: The run method (and related methods like set control value e.g.) runs in the user interface thread - and that thread is blocked if e.g. the user opens a contextual menu somewhere in your application . The consequences: In short, LabVIEW is unable to reliably start an asynchronous background process on demand. - You can try to dynamically scale your software by instatiating a VI and run it with the run method (with Wait until done set to false), but if you need it to always happen within a reasonable time your application cannot have a user interface. It can not, because if it does then the run method might be stuck indefinetly if the user happens to e.g. open a contextual menu... So when does this actually become a problem? Well, in my case its most painful impact is that all client-server interfaces I have in my applications are unreliable because they, in order to allow an undefined number of simultaneous clients, create session handlers dynamically. A client might do a transaction that takes a lot of time, and with multiple simultaneous clients even quick transactions would add up so handling the client transactions in sequence is not possible. Hence the use of dynamically created parallell running session handlers. This works fine, but if the local user of the server should happen to open a contextual menu my server(s) effectively become unavailable to any new connections. One minute my servers are there...the next they are practically off-line to all new clients because the local user happened to open a menu...and if we're really unlucky he might leave the PC in that condition and never return! An unacceptable situation, plain and simple. So how do we get around this? Well, either we stop making software that both has to scale to outside requests, and have a user interface...or we predefine a maximum number of parallell processes and instatiate them in an idle condition at startup. Neither one of these make me proud or happy. PS. When I first noticed this I posted two ideas to the idea exchange (here and here). They do not have any illustrations that catch people's attention, and as it turns out neither of them are very precise, so perhaps a new one should be formulated and illustrated - but it's kind of depressing too that so few people realise their impact.

I understand. The optimal solution if you need the functionality that you descibe is probably to split the splash into an optional GUI (the visible splash screen) - and a loader. The latter is the top-level VI of the app, and it will hide itself and do the necessary prechecks etc. in the background. The loader will only launch the visible splash screen if this is enabled. The "GUI" of the splash screen then also becomes a VI you can use as an About Box e.g. :-) Mads

A small tip about splash screens: Having the splash screen launch the main program is not always ideal as it prevents you from disabling the splash screen if needed (we have to do this for customers who run our apps on terminal servers e.g. - to save bandwidth (or at least many prefer it that way). A more flexible solution is to launch the splash screen from the main instead - but hide the main until the splash screen has closed. To do this optimally LabVIEW should offer us the possibility to set the run-time state of VI windows to "Hidden"...but that's not available so the next best thing is to set it to minimized...and then hide it immediately by running the necessary method (hardly noticable...unlike if you had shown the window in normal size and then hidden it). This way the main program can check if it is supposed to show a splash screen or not - and if it is - it will hide itself and then launch the splash VI....if it is not - it will just normalize or maximize itself and continue. Mads

Yes, but it is not the most elegant way to do it as it may produce a flickering window on the screen - and it will force everything to stop at the instant it is run. A tidier way to do it is to make sure all internal processes are terminated properly and then close every window the application has opened. When the last window is closed the application (and its use of the RTE) will stop. Mads

Do anyone know where the 2010 mobile module has gone? I saw some talk about discontinuing it...but has that happened, or is it just not ready yet?

If you set the installer to run the batch files they will run with the same access level as the installer, at least that's what my experience is so far. We use batch files to install our app as a service. If run on their own they have to be run by the Administrator...but that is no issue when they are run by the installer.

If you are working on Windows (and probably on other OSes as well) you should store the files in a system folder - and use the Get System Directory VI to get the path to it in both applications. Storing files together with applications that are installed in the Program Folder is not permitted on Vista and Windows 7 (no write access, this was true for earlier OSes as well, but back then everyone had the bad habit of being an admin...). The choice of system folder is not straighforward though...you could use the user's document folder or application data (hidden) - but then the location will vary with the user...or you can use the common ProgramData folder...but then only the server will get write access, the clients will only have read access unless you use a tool to edit the access rights. The latter would not be a problem if the server was in fact serving the data to your clients via a data link (TCP/IP e.g.)...and that would be more flexible than to require access for the clients to the local files, but I assume that's out of the scope. Here is a related discussion about where to store files on Windows. MTO

On the 3D Picture Control\Helpers palette there is a nice VI that is called Sensor mapping. This VI enables you to import a 3D model, place sensors on the model - and then generate a picture with the readings shown as an intensity plot overlayed on the 3D model. This is *almost* what I would like to use in a new application; except for the fact that the sensors should not be treated as points, but lines. It would also be nice to be able to import a wider range of 3D drawing formats (ideally it should be possible to create some simple 3D models with the app too, but that would just be a bonus). Is there anyone who finds such a task familiar? I'm tempted to oursource this part of the coding as we have enough work to do on other parts of the application, but if anyone has any tips or examples on how to e.g. modify the intensity mapping code in the sensor mapping VI that could be enough. Mads

Here's a good site to look at: http://blogs.msdn.com/cjacks/archive/2008/02/05/where-should-i-write-program-data-instead-of-program-files.aspx The discussion on the page highlights some of the problems people have with how things work in Vista/Win7.

The problem with the public application data folder is that only the user that first ran the program will have access to the configuration files the application created under ProgramData. One might say that the data is not really public...ironically enough. So if a second user logs in and you want that user to be able to see the same application configuration and maybe also do things that will affect it - ProgramData will not work unless you change the access properties of the files in programData. There are plenty of web sites that discuss this dilemma, and it's the reason why I suggested this idea on the idea exchange. This is why we normally use the user's application data folder instead if it's a user-run program, but we use the ProgramData folder if it's a service that always runs under the same user. Mads

The PDA module allows us to develop for CE-embedded on tiny SBCs. CE is not really (just) for cell phones...so I really hope they will continue to support that at least. NI is already generating C code and .Net assemblies though so perhaps it's not such a leap to support Win7 Mobile.

I'm looking for a low power single board computer that can run LabVIEW applications and is suitable for integration into a measuring device. Is there anyone who has experience with LabVIEW on small SBCs with e.g. Windows Mobile? The two basic tasks for the SBC is to communicate on RS485 with an external board, do some number crunching on some data from this external board and store the results for later retrieval using TCP or another serial link...The power consumption should at least be less than 6W. We have been looking at sbRIOs or the possibility of using the cards inside a PAC unit..(more compact than sbRIO)...but the form factor is too large and the prices are much higher than e.g. an SBC running Windows Mobile or XPe so it looks like we'll need to find a suitable SBC instead. Mads

Have you tried switching between themes? Perhaps if you set the theme to Classic and then back to Vista it might refresh the controls.

As people here have already mentioned you can still use an OO-like approach: I've made several systems in LV 7 and older where you have multiple units multidropped on different types of communication links. The user configures a set of channels and can add units on each channel. Based on the configuration I instantiate the necessary channel handlers and unit VIs (Open a reentrant reference to the VIs, or use VITs, and run them with the run method without waiting for them to complete...Use a notifier or user event to control their termination, config reload etc.)). The unit "objects" have a generic que based interface to the channel handlers; each channel has an output que and each user of the channel have an input que. The unit configuration tells it what channel it is on, and it uses the channel tag to get a reference to the channel's que. The unit can then send data to the channel using the channel que - and the channel will return data on the unit's reply que when the reply is available (using the tag of the unit embedded in the message it received on it's que). The ques pass clusters that, in addition to the message data and the tag of the user object - contain parameters like timers, expected reply length (if no reply is expected then the channel handler knows that and does not wait for one), errors etc. Unless you make a general plug-in based framework with sub-panel based configuration windows etc. it can be difficult to make the system flexible enough to fit *all* types of protocols and units though. One way I've solved such cases has been to write plug-ins (launched by a general "plugin launcher") that handle certain types of IO outside the standard IO architecture. In many cases these plugins just "translate" the new protocols to one of the "native" ones and hook up to the rest of the system on a standard channel.

The multicolumn listbox has two different modes - it can either be a scalar and tell you which row the user has selected, or, if you allow the user to select multiple rows - an array of the row indexes that are selected. You switch between these modes by right-clicking on the control and selecting "Selection Mode". If you write to the value property you can select rows programmatically, if you read it you read the indexes of the rows currently selected. The active cell is used to choose which cell you will be editing programmatically. If e.g. you want to change the background color of the cell in row 2, column 4 - you create a property node where you first set the active cell to 2,4 - and then (just expand the property node to have another property underneath the active cell property) - write your new color to the background color property... I suggest you show contect help (Ctrl+H) and hover the mouse over the control and its different properties, the help window will teach you how to use it, much better than we can do here. Check out the examples that come with LV as well, Help->Find Example->Search tab->enter listbox as keyword...or try searching on ni.com.

Sure, making VIs that accept all of the related objects is not a problem...but you still need to create the object, and that means that the callers must either deal with that directly (which we want to avoid, they should just hand off a Notifier name and a user event or que ref of any type)...or you need to make one object creator for all the data types and join them into a polymorph VI. The latter makes the new "Notifier with History" limited to the number of types you have VIs for in the polymorph creator VI (another thing we do not want). The primitive notifier on the other hand has an obtain function that will accept ANY data type, not just objects of one of the correct classes. I'll probably make my Notifier with History limited to just strings this time...that will at least give more or less the same behaviour as the old Notifiers/Ques that used to be string-only too.

A side note - but anyway: I did some experiments today just to see how I could implement this "Notify with History", and I played with the idea of using LVOOP for this. For some reason I half-expected to be able to produce unlimited polymorphism this way, ie. in this case the ability to create a notifier of any data type, but to have the top public VIs (obtain notifier, wait on etc.) virtually be the same regardless of the data type of the notifier - but as far as I can see that is still not possible. Even if you limited the number of data types you supported, and had different sub-classes for notifiers of those different data types (to then extract and handle the standard que or event reference that in fact would be at the core of the system) - you would still need an old style polymorph VI to let the callers use the public VIs without them having hard coded the creation of the correct sub-class...right? (Have not used LVOOP much yet...)