ShaunR

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.

Don't you use a modified OpenGPackage Manager for zlib rather than VIPM? I'm not sure if it is the same issue but when VIPM compiles the *.* it "fixes" the file path to whatever bitness you compiled it in if it successfully finds the library. That means if you created the package with 64 bit LabVIEW and the file name is "something_*.*", then the path gets "fixed" to "something_64.dll". The result is that something_32.dll isn't searched for when installed and recompiled on a 32 bit platform and the Vis are broken.

Code Library Function Node. The prototype you have put on the diagram. It is the "Return Value", the first and fixed item in the parameter list. Set that to Numeric and then choose Signed 32 bit Integer. You can't with that function. It requires a lot of setup allocations before you can call it. You need to start with the initialisation and de-initialisation functions then build it up from there. I would suggest using the DLL import wizard as a first pass (in the LV menu under Import>Shared Library(dll) ). It will create the VIs with the nodes (where it can) and then you need to figure out what it got wrong and what order to call them in. I would guess nxDrvInit and nxDrvExit are the first calls you should be looking to try.

Your basic goal is to get the function prototype (shown at the bottom of the CLFN dialogue) the same as that in the documentation. You have void xChannelIORead(uint32_t ulAreaNumber, uint32_t ulOffset, uint32_t ulDataLen, InstanceDataPtr *pvData, uint32_t ulTimeout); The return value is int32_t not void. You are missing the Handle parameter (CIFXHANDLE) and pvData is a pointer to something (probably an array) - not an InstanceDataPtr (which is a special LabVIEW parameter). Even if you fix that. You are still not finished. You will need to call other functions to get CIFXHANDLE through some sort of initialisation procedure and then deinitialise once finished. You will probably also have to call the enumerate functions to get the boards and their channel numbers so you can populate those parameters. If they have provided C/C++ examples then that will tell you what functions you have to call and in what order. Any mistakes will usually result in a LabVIEW crash. For the calling convention, you will have to look at the header files.

You mean it's "dark"? 😋 You can already do similar stuff like that with LabVIEW (although it could be a lot easier). What you can't really do is skinning.

Hmm. I'm not sure what your expecting me to say here. For debugging I want to see the results (on the FP) whilst I go probing the diagram (or even sub diagrams) especially for intermittent bugs. Quite often I throw indicators up instead of using the probe window, which I've always detested as it gets in the way of everything and you can't resize controls. So the FP becomes my probe window (usually after I found the place with the probe window). I tend to make changes to the diagram then hit CTRL+R in a kind of micro test when I'm just tidying up so I make sure I get the same result on the FP after rewiring - I don't want to keep moving windows around between editing and viewing the result. So I have all FPs are on the left screen and all diagrams are on the right screen.

When I'm working with dual monitors, I usually have the diagram on one and the FP on another - lots of room to work and uncluttered. Even when I'm working on a single monitor, I usually have multiple virtual desktops, again with FP in one and diagram in another. You can kiss that workflow goodbye with MDI.

I've said it before and I'll say it again. Speed of laying down primitives/controls is a non sequitur. It even pales in comparison to the time spent making sure wires were straight and non-overlapping (which I find oddly relaxing). I estimate that as little as 10% of my programming time is actually placing VIs, controls, primitives et. al. Another 10% aligning controls and wires and the other 80% is iterating, refining, debugging and documenting. Making a whole new ide because it is "more efficient" is an excuse you use to management and sales to fund your project when you have no concrete arguments. The real reason, IMO is more to do with that people are so afraid of touching the existing LabVIEW code and they have a glut of .NET coders who suffer from "not invented here" syndrome. I'm banking on that by the time they get anywhere near parity with the proper LabVIEW, I will have retired and won't have to use it.

They didn't need to do that. All they had to do was enable the rendering of UTF8 strings and we could support unicode easily.