ShaunR

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.

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"

The technical term is "All Rights Reserved" and grants no rights to anyone apart from the original author. The important part here is "Rights" which has nothing to do with software, per se. The definition of "Open Source" is a bit nebulous depending on who you ask (OSI is different from FSF, the latter of which is more of an ethos). I err on the side of caution and choose to interpret it to mean "source distribution" and completely separate that term from licencing-I know where I stand then. So you can call your software, Open Source, Free Open Source, Freeware, Nice-bloke-give-a-lot. I don't care. I only need to know Does it come with viewable source code? (not a deal-breaker if it doesn't) What licence is it? (won't touch it without one)

MIT is a good permissive licence. Unless you categorically state otherwise, LavaG.org cannot technically even distribute it to us which, I expect, would not be the intent. It's a minefield and just choosing one, regardless of what it is, saves so many headaches for your intended users and for LavaG.org.

So..... What licence is it?

The reason for my clarification wasn't really to do with architecture - more to find out what can be replaced piecemeal. Full re-factors always run into problems but if you have defined partitions, then you can replace over time with far less risk. Two things spring to mind. Firstly. If the C Server is dynamically loading the instrument specific DLL dependencies based on instrument selection. Then that can't really be done from LabVIEW. If you are planning on using an actor architecture to try and replicate this kind of behaviour then you will be jumping through many sub-optimal hoops just to achieve a similar outcome. Second If these are DMMs, SAs, VNAs etc then they probably support SCPI. That was invented to take out all the instrument specific driver requirements so you should only need one driver (TCPIP?) and that means you can just create simple text files with the raw SCPI commands for different configurations, regardless of manufacturer/model and squirt them directly to the device. The device will tell you what is allowed and not allowed (a DVM won't have current range, for example). Once you have a command squirter, then the "sequencer" just becomes a file manager and you can use your own custom sequencer or Test Stand-it doesn't matter, although Test Stand UIs are horrendous for production. Most modern devices also have recipe storage which is an initial configuration squirt (say at shift start, device replacement) and then just a recipe select command. It would be a judgement call as to how much is in the device and how much is in your files. If not all devices support SCPI, then I would look at reusing the current code for only those particular devices with a view to replacing them with SCPI devices at the first opportunity. You can do all that in any architecture you like (OOP or other) and it will be simple, easy to maintain and easily configurable (maybe too easily configurable?). You can make it more complicated than I have outlined based on specific needs, but it will work regardless. Addressing is the thing you have to solve in your own code, and that's it.

OK. So let me see if I've got this straight. You have a DLL "server", written in C, that represents a family of devices - say a DMM "Server" DLL that encompasses Keithly, Agilent et.al (and maybe even different model numbers within manufacturers). This DLL server is a "translator" that unifies the interfaces between different models and calls the appropriate, device specific initialisation functions so that your "Sequencer" just calls InitDVM (say), sets a range and reads the values without having knowledge of the underlying, instrument specific formatting. You are asking whether the DLL "Server" can be re-written in LabVIEW rather than the C implementation? And that because "Actors" are dynamic instantiations of the objects, whether this could be used?

True. I'm just spit-balling. You may also get version control out of it.

Well. You could also generate a menu so it appears in the palette.

Getting back to this again. What should we do with plain zip files? What I'm thinking of are the zip packages which are basically "install to a place of your choice-have fun" type packages. Many of these are given away as "driver" packages for interfacing to hardware. OGPM, VIPM and NIPM all have meta data of how and where to install but a simple zip file has no meta data. How would we handle this? Should we handle this?

I use TSVN and it didn't crash on my machine.

That's your problem then. You've whipped the carpet out from under LabVIEW. Namepace the VIs in the sequencer.

Maybe you are not creating articles but general admin akin to what you are doing is the corner stone of a great Wiki and usually goes unrecognised and un-loved. Keep up the good work.

I was unable to get a crash. I gave up when it indicated about 5000 deletions. Did I need to do more? LabVIEW 2017 both 32 & 64 bit on Windows 10. (Note: not SP1)

Heathen

Yes. It is in the build process, not at install-by then it's too late (at install) and the recompile passes but the VIs are broken. By the way. this happens also with the TPLAT so it isn't a particular VIPM problem. The work around is to delete the DLLs just before building (so that VIPM or TPLAT fail to find the files during the build) and press "ignore" when it searches. Luckily, that doesn't fail the build but I can see that at some point they might "fix" it so the build fails.

I was going to be flippant and say "The NI forum has loads" but they don't work either.