Rolf Kalbermatter

Yes you need to install the shared library too. If you run VIPM to install the package you should have gotten a prompt somewhere along the install that asked you to allow installation of an additional setup program. This will install the NI Realtime extensions for the LVZIP library. After that you need to go into NI MAX and go to your target and select to install additional software. Deselect the option to only show recommended modules and then there should be a module for the OpenG ZIP library. Install it and the shared library should be on your controller.

Well, the base was pretty solid and worked for most of the things. I personally find it impressive that it wasn't really necessary. That said the control editor certainly could have benefited from some love in the mean time. It works but always was a bit of a difficult thing to use for actual working on controls, and you can easily end up with a control so messed up and impossible to grab the individual parts in the way you want, that it's often easier to start from scratch again. And I have it from the original developer who worked on the control editor, that the control editor wasn't actually a piece of software they still felt proud off and that in order to redesign it, it would need to be completely rewritten as modifications of the existing code base would be basically unmaintainable. You can be judging on that but you have to consider the times back then. Experiments to compile some of the LabVIEW code base with C++ were a disaster as the C++ compilers at that time produced massively exploded code with sometimes pretty bad performance, so the entire code of LabVIEW was written in standard C. C compilers were struggling to compile the huge LabVIEW code base (NI had to beg Apple repeatedly to extend the internal tables of the Apple C Compiler to be able to handle the number of symbols the LabVIEW code required). NI could have waited a few years with LabVIEW hoping that C compilers got better but that wasn't really a good option so they had to work with what was available. And then as C compiler tools got better there were many other areas that required attention to implement new features rather than redesign existing features that basically worked.

Disable the live drag feature as is mentioned in the thread from Neil. This will get rid of the potentially long and jerky refresh and according bad drag drop behaviour that you can get in larger projects and VIs with this feature. Also another question: What happens if you don't pass back the DVR reference into the class wire? I generally don't do that at all but simply use an unbundle to get the DVR from class private data and then an IPE structure to dereference the DVR, without putting the DVR reference back into the class after. I agree that this should still work, but I have a hunch that this particular use case might have been overlooked during testing of the read only flag for DVRs.

The control editor? No, that is in LabVIEW since at least version 2.x and at that time they didn't even have the option to call VIs as integral dialog of the IDE. These dialogs itself are in fact using the same resource format as a LabVIEW front panel, but the code handling them is all written in C and part of the LabVIEW executable.

I figured as much as I did try on a myRIO and also on a normal Linux x86 system and couldn't reproduce the problem. I do have currently a 9035 available for another project (which has higher priority) and will try it on that one as well very soon.

I'm not sure it is the same as in LabVIEW 2016 but they changed quite a bit about how the moving (and ctrl-dragging) of objects works. When at first confronted with this it felt smooth and actually quite impressive. That is until I had to work on a larger project in LabVIEW 2016. Suddenly everything started to get quite jerky and I ended up frequently to involuntarily dropping things somewhere on the diagram where I never had intended to do it, simply because somewhere along the jerkyness LabVIEW decided that I had released the mouse button or something. To me it feels like a nice idea that got executed based on a limited test but not quite tested on real world professional sized projects. Or every developer at NI uses only the highest end super powered machines with CPUs that normal money can't buy you .

Your sentiments you posted in your first unedited post are fully valid. NI has gone from a small technically driven company to a middle sized bean counter controlled company. It can feel rubbish at times. But I'm not sure you or I will change that in any way. Their customer support is still above average in many cases but if the problem gets difficult you can run into a brick wall sometimes and the people in support are not allowed to leave the predefined channels even if they don't work. But without a proper reproducing case that also shows the symptom on a system that NI can test on, there is nothing anyone could do about this. The PSE in question will shoot down any CAR without at least a clear description how to reliably reproduce the problem. Unless you can show NI in a convincing way that you will buy for a few millions of extra hardware if it works .

Was that on an NI RIO hardware or a standard PC used as a RT system? If latter then there is still a very realistic chance that it is due to some specific hardware version of chips in your system. They tend to have all sorts of bugs that can negatively affect software. Systems like Windows contain a lot of pretty involved software hoops in the hardware drivers to work around such bugs. Even Pharlap has that but to a much lesser degree since they are not used as much and not on as many more or less mainstream hardware systems build with all kinds of components from sometimes rather obscure sources. PCI bridge implementations are very well known to not always follow the official standard to the letter and even those standards are regularly revised and improved to better support certain advanced modi. Even if it is NI hardware this is still true, but then NI should be with some effort able to reproduce it. From the sound of your error description it looks like a race condition somewhere in the kernel that can under very specific circumstances cause a mutual exclusion lock somehow.

But it's logical. Without a reproducing case there is nothing you can fix realistically. Sure you could send someone to check all umptien million lines of source code in LabVIEW, DAQmx, NI-488.2 and low level drivers like NI-KAL etc, but that is a task no person could fill in in an entire life time and still missing hundreds of potential gotchas. Unless it's reproducible it is not a bug, at most it could be your imagination or a cosmic ray causing it. And from my own experience as AE more than 20 years ago, and from application development for customers, if I can't reproduce it, there is a serious chance that the problem is indeed at the other end of the line, and not in the software I am supposed to support, no matter how angry a customer is about the piece of sh*t software he presumably bought. And if you have spent hours supporting such a customer and finally after many hours realize what error on his side caused it, it can be still a challenge to break those news to him in a sensible way. The people who tend to get most angry are often not very good in admitting their own faults.

Just as infinitenothing has mentioned, unless you use the Run VI or the Start Asynchronous Call VI server method, it is highly unlikely that you run an independent VI hierarchy in your application that could cause the refnums to be autocleaned.

What a FUD! SubVersion has never been licensed under the GPL license. It was developed by CollabNet and distributed under a fairly liberal license. Later it got transferred to the Apache Software Foundation which distributes software under the Apache License which is also NOT comparable to GPL. Even then the GPL does not cover the license of code maintained with a GPL licensed tool, but only code you would link in any way with that tool. And in the case of the Linux kernel there is even an explicit exception that applications running on Linux and therefore technically linking to the kernel in some way (they need to do kernel system calls for just about everything that interacts with the system) do not fall under the GPL unless the application developer elects to use the GPL for his software. As to VIPM it is under a commercial license from JKI. The OpenG libraries that are also used inside VIPM as well as being installed through VIPM are all under a BSD license, except the shared library parts that I wrote, which I left under LGPL. Technically this has no influence on any application developed with such OpenG libraries. The VI parts are BSD licensed and allow you to do almost anything with it except claiming you wrote them yourself and they require you to somewhere put a copyright notice that your application uses libraries from OpenG. The LGPL licensed shared libraries in those tools don't taint your application either since they are dynamically linked as a library and since LGPL explicitly exempts any software that uses such a library in such a way from any obligation to be open sourced itself, you are fully safe there. The main limitation the LGPL license has on those libraries is that you can't grab the C source code for them and create your own shared library from it and not open source it under the LGPL (or GPL) yourself. I feel this is a fair limitation. If someone takes that code and improves it in any way I want a chance that this improvement is returned to the community. If you use Tortoise SVN then yes that is distributed under the GPL but even then claiming that since your source files pass through Tortoise SVN somehow they are suddenly also GPL licensed is a total bullshit. It's analogous to claiming that any car driving through your private road automatically is owned by you from that point on. You may forbid other cars to drive on that road and get a ruling from a judge that anyone still driving there without your consent can get a fine but you don't automatically own them. Actually I think it is even more analogous to anyone driving on the public road in front of your house being suddenly liable to you for the mere fact of driving there!

You should check the link to the NI site. It only shows a Page Not Found error.

Your assumption is not fully safe. File IO is protected and if your application can happen to access the same file from multiple locations asynchronously you do have to employ some protection. Most of the times I have actually LV 2 style globals that manage a certain subset of ini settings for an application. Each of them has a initialize method, a get and set method and a save method and if there is a change that some information needs to be modified asynchronously a specific modify method for such information. The initialize method does read the configuration into the uninitialized shift register and is typically executed during program initialization, the save method saves the content of the shift register to the INI file section that it handles and is sometimes called at the end of the application and whenever the user changed a setting in the configuration. For program runtime variables that you want to save somehow to some persistent file storage you should do something similar but you might need to do also some kind of resource locking if you intend to read the value do something with it and then save it back. The reading of the LV 2 style global does not require to actually read in the value from disk as it is already stored but you may have to distinguish between just reading for reference whatever is the current value in which case you simply read the LV 2 style variable and reading it in order to modify it and write it back in which case you may need to acquire also a semaphore that is then released after you have written the value back.

You're doing several errors here. The main error is that you access a global resource concurrently without any protection of it. The File IO VIs have a built in protection with the deny and access rights but since you do no error handling you simply miss it completely that something went wrong. Basically without error cluster fed through the VIs you are totally bound to fail without good indication. There is nothing fundamentally wrong with the File IO functions but the way you try to use them simply can't work. A file is just as a global variable a global resource and needs to be treated like one. If you don't watch out you create race conditions and in this case since the File IO functions do some resource locking to prevent the worst to happen also errors that you don't handle at all. Both the Open Configuration File and the Close Configuration File can fail if the file is open at that moment by another function. If the Open Configuration File function fails you have to retry opening it until it succeeds before you can read any data. If the Close Configuration File function fails with the write if modified set to True you have to equally retry it, otherwise the data you modified in the INI file data is not written back to the file on disk. Again, only the Open Configuration File and Close Configuration File actually access the file on disk at all. Everything else is done in memory. Open Configuration File opens the file for reading and will fail if the file is currently open for writing by a Close Configuration File function that needs to save some data back to the file. And Close Configuration File will open the file for read/write which will fail if anyone has that file already opened no matter if it is just for reading or also read/write access.

In terms of CPU there is definitely less resource consumption by an invisible control, quite independent on how it was made invisible (made invisible, on an invisible tab, window minimized or hidden). In terms of memory resources there is not really any difference, the control still is there and needs to manage its state and data. This also means that it is not 100% idle. If you change properties, or the value in any way, it will take some processing power to update the internal state of the control even if it is invisible. However this is typically significantly less of an effort than even just updating a single numeric control on a front panel. YMMV of course, updating a graph with a multi mega samples array will take some time as the data may have to be copied into a new data buffer, but the drawing of invisible controls is postponed until they get visible again (if LabVIEW knows that the control is invisible, that might be different for a control that is on a technically visible panel but outside of the bounds of your screen).

In addition to all the above remarks, your found issue may be anyhow a red herring. The NI INI File VIs read the INI file in the Open Config Data.vi and store its contents internally in a memory list. It is only written back in Close Config Data.vi if the write file if changed (T) boolean is set/left on true AND the ini settings changed in any way by calling actually one of the Write Key.vi methods or the Remove Key.vi or Remove Section.vi. So collision of read and write to that file only can happen if an open and close can compete simultaneously for control of that file. The error you see in your simple example is expected behaviour by the way. LabVIEW allows to control the access right and the deny right when opening a file through an explicit File Open node. Your implicit use of the File Open by wiring directly a path to the File Read and File Write opens the file for each operation and for the Write with the deny read and write access. The implicit File Open in the File Read will then bail out with an error as it can't open the file again if the Write managed to grab the file first. In the other case the implicit File Open in the File Write will bail out with an error since it tries to open the file with write access but the File Open in the File Read has opened the file with the deny write specification to prevent inconsistent data during read operations. Accessing any global resources concurrently requires careful planning and considerations. You either have to allow concurrent access and risk inconsistent data when reading and writing at the same time or you have to handle the sequential access to the file in some way so the read and write won't happen simultanously (and then you could play with the deny and access modes for each to allow the read to open the file anyhow eventhough the write has it open too).

We used to have a Toolkit that would allow a LabVIEW application to properly interact with the Service manager so it could itself behave like a real service. It consisted of a DLL part that does the real work of interfacing to the Service Control interface in ADVAPI32.DLL. This also involves callbacks so a DLL is really unavoidable here. I'll have to check about the status of this toolkit and if we can make it available to external parties. From what I remember it was a substantial development effort.

As far as I know, the ActiveX server interface in LabVIEW dates back to LabVIEW 6.0 or something and that is in fact before such features were available through VI server. It seems there was very little changed on the ActiceX server interface since, while the entire VI server itself received a huge workout with many new features including the whole scripting API. The most simple solution might be to create a VI library that provides the necessary functionality through use of VI server and build a DLL from it.

PNGs definitely can contain zero bytes in their datastream. It's a fully binary format.

That's a very old recommendation back in the days when NI added source code control integration to LabVIEW (version 6 or 7 or something like that). They used the Microsoft source control API for that which was only really supported for the now defunct Microsoft Source Safe offering. Some companies developed additional plugins for that API that interfaced to other source control solutions but the Source Safe API used the old checkin/checkout methodology like what CVS had been using and didn't support any of the other methods like what SVN, Hg and Git nowadays support. As such the Source Safe API was severally limited and never really could catch on, probably also helped by the fact that Source Safe was a notoriously bad source control system, that could actually corrupt your source code randomly if you were unlucky. NI later improved the source control interface in such a way that you could install LabVIEW based source control provider plugins, so if you want to use SVN and have it integrated in LabVIEW directly you should probably install the Viewpoint SVN plugin instead. The only problem with LabVIEW based project plugins is however that they can affect the performance of LabVIEW IDE operations. There have been reports that installing any of the LabVIEW SVN plugins start to severely impact edit time performance if a LabVIEW project file reaches a certain number of VIs. But PushOK SVN is certainly the worse solution for use with LabVIEW. That all said we use SVN for our development, but we usually don't install any source code control plugin in LabVIEW. Most simply use the Tortoise SVN Windows shell integration. You have to be careful when moving, renaming, or deleting files as you have to make sure to first do those changes in Tortoise SVN and then change the project to reflect the new situation but it works pretty well if you keep yourself disciplined.

I second what drjdpowell says. This never happened AFAIK. What you describe about reinitialize to default can happen when you use VI server to load a VI into memory and then call it, both with Run VI, or Call By Reference (asynchronous). When loading the VI with Open VI reference it will be loaded into memory and then all the controls will indeed be initialized to their stored default value. Another thing you may be confusing is that controls wired to the connector pane will always use either the value wired to that connector pane or the configured default value. But that has been like that since the beginnings of LabVIEW and still is. Controls that are not connected to the connector pane however will simply retain their last value for as long as the VI stays in memory and that has been like that since the beginnings of LabVIEW too. And the use of local variables instead of shift registers/feedback nodes is discouraged because of performance reasons!

I personally created a Veracrypt partion as a file in my personal folder and install it on boot up as drive P:\ for projects. All my development work is on there, which has the extra benefit that it is password encrypted and can't be accessed by unauthorized people if the computer ever gets stolen. (This is a company requirement that all project work needs to be in some encrypted form that can only be accessed with the correct credentials).

A yes! I remember that. The Picture control does maintain a background pixmap that is redrawn on front panel refreshes and pixmap extractions. And it is in fact independent of the size of the actual Picture Control although I think that for refreshes of the image it will clip the drawing operations to the visible area. But did you notice the rect input to the Picture to Pixmap.vi function? With that you can define a clipping rectangle to which the returned image will be restrained! From the help to that function: rect is a cluster that contains coordinates that describe the bounding rectangle of the image you want to convert. The default is to return the entire image. Horizontal coordinates increase to the right, and vertical coordinates increase to the bottom.

The post install action is run in the context of the installer so it should have the same elevated rights. That SHOULD be enough, but I'm sure there is a possible scenario with custom policies and such from a heavily guarded IT departement that could allow users to install applications but not change firewall rules. Most likely not intentionally but still!

I"m not quite sure if you mean to advocate a class hierarchy for an "has" relation. Part of the sentence sounds like it, then again the other part seems to indicate you mean not. One of the first principles in OOP anyone needs to understand is that two objects can either have an "is" relationship or a "has" relationship. For an "is" relationship inheritance is usually the right implementation, for "has" you should make the "owned" object a value/property of the owner, which could be by composition.