ak_nz

The best practices we follow is to limit activities in DVRs to setting or retrieving data. We don't use DVRs as a "lock" mechanism to limit access to a resource. If we need such behavior we implement any other locking functionality that has time-out capability such as semaphores, SEQs or the ESF. This has allowed us to avoid a host of issues, such as deadlocks in dynamic dispatch methods between DVR'd classes in a hierarchy.

To be honest, that statement in the LVOOP white paper is fairly controversial. Your simplified process doesn't necessarily require by-reference behaviour, although it certainly makes it easier. If you want to pursue inheritance hierarchies using DVR's then I suggest looking at using GOOP / OpenGDS. It has a proven track record of sorting out the nitty-gritty and letting you focus on the more generic problems associated with reference-based designs.

My guess is it is to do with the scheduling infrastructure built into LabVIEW. VI Server Property nodes in other OSs force running in a specific UI thread, and some actually require full root loop access (root of the LabVIEW execution). To enable such support in a real-time system and provide guarantees on real-time performance was probably impractical.

We have a lot of third-party IP in dlls here so the Execution System wrappers would help us out a lot (and avoid continuously customizing ini files to extend the number of threads per system). But agreed this wouldn't be beneficial to everyone.

Looks interesting; I have been working on something similar. I notice your naming follows the TPL convention in the 4.0+ .NET Framework, were you inspired by this strategy?

Avoid abusing inheritance hierarchies as much as you can - keep them clear and shallow. Sooner or later it bites you in the a$$.

Wow that was a difficult read... To More Generic doesn't change the run-time class on the wire, simply provide some compiler guarantees that the class can then be viewed as the parent. Without sitting down with a strong cup of coffee - your solution sounds like it might work but it also sounds awfully complicated for what is basically an LSP violation in the hierarchy.

I too use the build number for source control. When we don't use a build server directly we have a plugin (Tools menu) that reads in the project source SVN revision and allows the developer to build the appropriate build spec and then reverts the project file to prevent confusion.

Do you see you logic error in the SubVI1 False case?

In order to create an HTTPWebRequest: there is a factory method in the base class WebRequest: https://msdn.microsoft.com/en-us/library/system.net.httpwebrequest(v=vs.110).aspx. You could then call GetWebResponse to process a response object. "The HttpWebRequest class provides support for the properties and methods defined in WebRequest and for additional properties and methods that enable the user to interact directly with servers using HTTP. Do not use the HttpWebRequest constructor. Use the WebRequest.Create method to initialize new HttpWebRequest objects. If the scheme for the Uniform Resource Identifier (URI) is http:// or https://, Create returns an HttpWebRequest object." EDIT: Looks like you can only call GetWebResponse on derived classes as you specified. It looks like the WebClient class design exposes this as a virtual seam to override. LabVIEW can't create .NET classes, so in this case you could wrap it up in a basic assembly and use that from LabVIEW. Or use the LabVIEW native APIs to communicate to the web service.

Quick thought - you could probably down-cast the reference and then set the TimeOut and ReadWriteTimeOut properties on the HttpWebRequest reference.

You implied that your C# assembly contain a Form - so presumably you want to show this form from within LabVIEW. Once you have instantiated your form with a Constructor node you need to show the form with the Show() method via an Invoke node.

My understanding is that they both execute in the single UI thread and they have basically the same performance - although the performance similarity is unofficial from an NI support person.

By application and your description I presume you mean instantiating an instance of the particular Form that you are showing? Or are you calling the static Main method in the (commonly named) Program class in order to start-up the message pump in order to monitor WND messages?

Here's a simple example that replaces all property nodes that exist for a given control ref with a different type. In my case I have specified a Numeric type; feel free to change this to suit. Note that the VI with the property nodes must be in edit mode for this to work; as a result it might not suit your use case.

My mistake, I assumed you meant replacing the control applied to rather than the destination of the node. Are you sure that Property is the write type? I assumed this was for any Property Node call, rather than the specific PropertyItem GObject.

Yes, it is entirely possible if you have a reference to the object. Make sure you have VI Scripting enabled in your LabVIEW options (under the VI Server section) in order to see more useful methods and properties of VI Server objects.

Hi gang, I am in the process of re-structuring a large application to minimise dependencies. The approach taken is to break the application up into buildable components. One of the consequences of this is that many VIs, when moved to another component, are missing SubVIs, including some polymorphic instances. They need to be replaced with versions that are now located in these built components (lvlibps) I have been able to fairly easily write a scripting tool to locate missing SubVIs and replace them from a search folder but have struggled with polymorphic instances. While I can replace the polymorphic VI itself easily (eg. "Poly Convert.vi") , it appears as if I cannot retrieve the "missing" instance that was used (eg. "To int32" is the missing selected instance); thus I am unable to correctly set the right instance after replacing the VI. Any ideas? I have many hundreds of polymorphic instances to replace in this project and am not looking forward to the menial work otherwise... EDIT: An example of what I am trying to replace attached

I like cell. Perhaps Slot?

We make extensive use of this feature - but unlike MarkCG our deployment scope is much more limited (Windows targets only). Besides deleting the cache when the occasional "odd" thing happens we very rarely ever get corrupted VIs now (unlike 2012 - looking at you buddy).

The second link demonstrates an example of the Report Generation Toolkit. The example shows saving the report to an html file.

Yes, for simple projects we would have a single "Common" library which would contain the abstractions needed by the other hierarchies. Only this Common library would be automatically loaded into memory by it's callers. We have found that sometimes 'stairway' requires a bit too much lvlib maintenance to be truly useful on all but the larger projects. I'm interested in your experiences and patterns for this. This is probably my main take-away point as well

Do you favor LLBs as the alternative? I'd be interested in hearing more of how you manage the same use cases.

A comment on smithd's description of "package management" with lvlibs - this type of management is common in our other Java and .NET applications for packaging dependencies. Discussions around how to manage packages in order to reduce dependencies / coupling between dependencies has been a common topic of discussion in the development world (outside of LabVIEW) for many years now. LabVIEW has it's own take on the same concepts. We typically try and use the "stairway" pattern for dealing with dependencies but that relies heavily on LabVIEW "interfaces/abstract" classes. It works most of the time; on occasion we have the same sort of bloat but that typically occurs when we have multiple copies of basically the same dependency loaded from different packages.

At work we favor packed project libraries for production deployment (VIPM packages for development deployment) so lvlibs are unavoidable for us. But we do run into the "load the earth" scenario too. The best compromise we have found is to break down the component into smaller pieces.