ShaunR

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)

The DLL is 64 bit. Are you using 64 bit Matlab?

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.

Well. The CLFN can't dynamically load. By that i mean you've cannot load a DLL, get the pointers to the function calls and call the functions with the appropriate arguments. If you can do that then it gives you the capability to map similar functions (e.g initialisation) across multiple DLLs with a single call from the application. The closest you can get is to apply a path at run-time to the CLFN which is more like a just-in-time static load of a single function. So for each function you want to call, you will have to have a CLFN and supply it with a path to the particular DLL that the function resides in and have one for each "similar" function in each of the DLLs you want to call. If all the DLLs have the same binary interface, then it's not a problem (think about the same DLL but just 54 bit or 32 bit compiled). If they are all different, then you have a huge number of VIs with CLFNs (one for each DLL function variant).

Right click on the Image indicator and select "Advanced>Synchronous Display"