ShaunR

Yeah mine were a little more obvious that an xcontrol was really the only elegant half-way decent solution. One was a string control with markup and the other was a tab control that works like the native one should. So it was really about encapsulation.

If that scares you then I don't give you good odds on "fixing" the LabVIEW source when it's released I've just written two XControls. (First time in about 6 years). They seem to be ok but some of the ways they work can be a bit unintuitive.

Surely it would have been easier to just add the CRC check in the openG.

Nope.

When you edit a palette set, there is an option of "Place VI Contents" when right clicking on a VI, which will drop the code contained in the VI rather than the VI itself (like a template). Maybe it has something to do with that.

Well. You could make an XControl.

That only tells you if the bytestream has been modified in transit rather than if there is a corruption in the archive itself.

Well. Rold is particularly thorough, so In the interim. If it's windows only, you could try Zlib Library for LabVIEW 1.1.0 It has a compatible VI with the native LabVIEW but I didn't notice the conpane for the OpenG ones. I'd be interseted if it passed your tests too.

Actors? (AKA Throwing lots of cats in the air then trying to herd them.)

If you've ever started up Wireshark, you'll see occasional TCP retransmits due to differnet factors - especially under load and especially with Wifi.. These don't get retransmitted with UDP. It sounds like most of your losses was were due to packet collisions.

I don't see a check in there at all. It's not much of a change in the bowels of the LabVIEW code, but does require a new CLFN to call the CRC which fortunately does exist in the DLL.

Itseems to me that that this is an extremely poor cure of the symptom rather than addressing problem. If it ever gets deployed somewhere other than your particular network, with your particular data needs; it will undoubtably run into problems. RUDP is an application overlay. So you would need to code it yourself (from the spec I linked to). I don't know of any LabVIEW implementations but there are quite a few similar ones (RTP?) since UDP is used all the time with VOIP and video streaming.

ARP is part of address discovery. It links MAC addresses to IP addresses. Yes you do need it. Ditto gleichman or implementing something like RUDP at the application level.

I don't care what version of .NET is required. All .NET is banned from my projects and some of my hair has grown back as a result I too have products in 2013 and have found it relatively stable. It was my next choice if I were to be dragged kicking and screaming from 2009 Anyone else prefer an earlier version than 2013?

What should the source code minimum version be? By that I mean the source code of the package manager itself, as it would ideally be open source. Obviously 2009 is my preference but that requires 3rd party toolkits for HTTP and HTTPS; which is not really tenable for most people. Later versions are plagued by stability and performance issues so I guess what I'm asking is what is the minimum stable version of LabVIEW that should be supported based on prevalence.

I know you are looking for the most precise method for this type of waveform, but is there a reason you can't do a peak detect to remove the lead-in?

Thanks for the plug. But I would only recommend it if TLS is required since (as far as I'm aware) it is the only one that supports it.

Wavelets are part of the Advanced Signal Processing Library.

Uhuh.

Wavelet?

You will notice that in 2015 and below, selection of the individual items isn't made until the mouse is released. In 2016 and later, the items are selected as you drag the selection. Bit lets be clear here. The issue isn't version performance, per se. It is a problem with redraw on certain platform configurations; the reason for which is unknown. My feeling is that it is something to do with the display driver as I have seen other spurious issues (such as not redrawing correctly when dragging) which were resolved with driver updates.

I was refering to : Which is exploitation of acquired data - reporting, statistical analysis and trending. But I guess you misunderstood my reference to databases for property pages. This is where I leverage a relational database to give different "views" of devices and easily present tests and configurations that are applicable to those devices. A relational database is ideal for this purpose. Somewhere on lavag.org I did a simple example a while back for converting ini file configuration system to a database which is a similar concept (can't seem to find it now)

None of that really solves your current problem - if anything it is making it worse with assumptions and complete rewrites. Your risk assessment should be screaming at you. If you consider exploitation to be separate from from acquisition, then a natural partition will form where you can add different exploitation methods as required at a later date.

I'm not really sure what this means. SCPI is a command syntax (strings) usually sent over TCPI so where you are talking about adding functions "through the SCPI standard"...it's a little bewildering. The aim is to get completely away from DLLs and drivers where possible. Where not possible, one sometimes makes an SCPI compliant intermediary translator for that device. Is this what your service DLL is doing? I have no view on lVLIBPs. I don't use them. I know some that do. If a developer wants to use them it's up to them I do have a very strong views on .NET, ActiveX and DLLs, though and the rule of thumb is avoid whenever possible. SCPI is one way that I avoid them in multi-device architectures because it only requires TCPIP and string manipulation for hundreds of devices. But here you are basically talking about device specific property pages. I can see the OOP argument for it. I've yet to see a robust implementation that doesn't require a complete rewrite of base classes as soon as a new device needs to be supported. But I understand the "theoretical" appeal.Personally I prefer a database solution to this. I was merely pointing out Rolfs preference for DLL wrappers around other DLLs which greatly simplifies the LabVIEW interface code. That is in contrast to my preference to direct implementation in LabVIEW without intermediate wrappers. They both have their pros and cons. For me, I just don't want to have to recompile another intermediary every time the upstream binary changes and let the user replace the binary directly if they really want to. That means a lot more complicated LabVIEW code but less forward maintenance. I'm sure Rolf will chime in if there is some specific information you require from his implementations.

It depends on what the DLL server is doing for you. You did say that the reason for the DLL server in the first place was due to LabVIEW limitations - many of them still exist. If the low level drivers for specific devices are so obnoxious that they have features that can only be implemented in C/C++ (like callbacks) then you will get stuck. It is for these reasons that Rolf prefers wrapper DLLs for LabVIEW to other DLLs. If, however, you go the SCPI route then you can implement it all in LabVIEW, packed libraries or not.