0_o

More or less. The DLL Server for each family handles the logic of that family and it expects you to give it another dll of vis that implements it's API functions for a specific instrument model. The sequencer declares which instruments are available and opens standard panels to configure steps of tests using those instruments among other utilities that the sequencer comes with. The question is about the DLL C Server but also about the entire design. What would you change in it? Will adding simple panels for device families help a factory floor non-programmer write his/her own tests in TestStand? I know you hate OO and probably Actors in particular so I won't narrow you down. Having a standard panel to handle DMMs and load different implementations into that panel without having to change logic or datatypes or GUI is the specific case I have to deal with. I thought OO inheritance might fit here: the standard panel will use API functions from LVLIBP and the specific instruments will inherit the actor in this LVLIBP. However, you can just as well have Python and MySQL run a test sequence on a station while running API calls that are implemented for the specific station's instruments according to an XML file. The reason I have that DLL C Server in my framework is that I didn't want the general panel in the sequencer to hold the connection to the instrument and the low-level logic mainly because I wanted to be able to kill it and free the memory. Correct me if I'm wrong but this is easily done when the engine that keeps alive the connection to the hardware is external in a different scope than the sequencer exe.

The sequencer is not TestStand, this is the main framework I was talking about. I thought that by caller you referred to a sequencer. However, this framework is getting old, thus, I had 2 options: 1. Recompile this huge framework to LV2018 2. take out the main advantage it has over TestStand (standard driver for most of the device families out there, much more than 22 with many drivers from different manufacturers already implemented) take it outside of my framework and bring it into TestStand. I'm trying to explore this second option in this post. You got me interested when you talked about being able to run a batch file of tests over this exe without a sequencer but rather more like a step recorder and allow different batches to run simultaneously. In my case, the sequencer does this kind of work. I was never able to do that in your kind of engine exe unless I used autoit. I love the concept of Xilinx Vivado. It is written in TCL/TK and you can record a test you do manually and it will create a TCL/TK script you can run on a machine that doesn't have Vivado (costs a lot). How do you do it? Do you use Actors and record the messages?

Not trying to brag but I can do about the same Only that in my case the caller, which is a sequencer with lots of functionality, calls a dll server for each family, think of it as a different exe for each family in your case while the GUI of that server is loaded as a plugin into the sequencer. With all the benefits it slows down development sometimes since I can't just work with a new device using the manufacturer's vis, I need first to fit it into my standard (but then the full-featured framework saved me time since I don't need to rewrite the logic and gui, I just reuse it). Now that you know actors framework, would you have done it differently using HAL-MAL+LVLIBP? Do you cell your tool? Is there a video demonstrating it? Is there an easier way to add a driver while using a standard reused logic/gui for that instrument's family?

Let's see if I understood you correctly: You have an exe that lets you support all the device families while the specific instruments are listed in an ini file. In the exe, if the logic wants to set, for example, the Eload to CC 0.2A and load=on it will call "init", "set cc" and "set load" via dynamic vi server call by reference of a driver you built for the specific model and that driver must follow that families API? If the vi server call can't see the correct inputs/outputs from the API you'll get an error for a specific function for that instrument in the exe (greyed out maybe). I too wish to keep it all LabVIEW. Question 1: Is my description correct? Question 2: In this scenario how do you free the memory or prevent on driver from making all the application to hang or even work with several instruments in parallel? Question 3: If the driver you are calling uses a global, for example, and you didn't call a dll that remains in memory with the global from init to close but rather a simple vi, how do you keep the connection id alive?

Please ask for clarification if something is unclear. By family I mean dmm/dio/scope/...

Hi, I need help with the redesign of an old framework: A sequencer has a general plugin front panel for each family of instruments drivers. Each of the general plugins manages a front panel while interacting with a general family driver which is actually a dll server that accesses the instrument. That dll server accesses a dll that wraps the vis from the instrument manufacturer using family standard vis. For example: Instrument manufacturer Init vi -> Instrument family standard Initialize vi -> specific instrument standard dll -> general family driver server dll -> General family front panel plugin -> sequencer The result is the ability to build a sequence with a general family front panel + general driver and replace the general driver with a specific driver when it is done. It shortens the development time since the sequence and the driver can be written in parallel while maintaining a bug free standard that gets all the other benefits of the sequencer or the already written front end logic. At the moment the driver family server is written in c because it was written when LabVIEW missed lots of features. Since it reminded me of the actors HAL example, I'm thinking about an actor that will hold the family front panel and lvlibp general driver with inheriting lvlibps that uses the manufacturer vis implementing standard family vis. Is there a simpler solution that will let me reuse as much of the framework? Thanks in advance.

I refer to the migration tool between LabVIEW and LabVIEW NXG. If there are features that are not yet supported or if my code uses an old llb, for example, that won't be supported or if the migration tool is not working properly and can't migrate correctly some features that means I won't be able to move to NXG even if I wanted to. A new thread here with NXG issues will make sure NXG is ready for us in a year or two when we have to migrate. I'm going to try to migrate a very big project (just to check in theory what happens) and list the errors I get, should I post it to the dark side or here?

You convinced me not to try NXG at this time. My main concern is not being able to open a large project without it being broken. Should we start a new NXG thread with failed migration attempts so that NI will make sure that we'll be able to migrate smoothly in a year or two?

Hi, LV NXG got itself some new features that finally make me conceder it, more so because of the LV2018 release bugs and the fact I can't work with LV2017 along with LV8.5. It supports DAQmx, Vision, FPGA, SVN, TestStand and much more. Mainly, I hate feeling left behind stuck at LV2016, especially when it comes to Python support. However, I don't see here a thread about NXG with active users so I don't know what is not yet supported and what will be the learning curve. Will I, again, be NI's guinea pig? I understand they have a code migration tool yet I don't know how good it is for huge projects. Is it using a VI at all? Does it support scripting and OO? Could I use llb/lvlib/lvlibp/...? What are the benefits? Is the FP resizable? Migrating upstream is one thing. What about downgrading? Even Regular LabVIEW can't handle downgrade (just try writing a vi in 2016 with a conditional indexing tunnel and save it back to 8.5 that didn't have this feature - LV8.5 will crash). Yours truly, Guinea pig SN: 23145211.

That requires me to upgrade a LabVIEW+.net+c+assembler Software that took 15 programmers 10 years to develop and many of those programmers are no longer working here. I hope to get to it during the 2nd quarter of 2019

Interesting! I didn't know about the counterfeit. I user the most recent driver and even contacted the company for no avail. As to NI, it is completely cool to stop support, I even think that many of NI's problems start from this baggage. However, to use the Win compatibility as an excuse instead of saying they stopped the backward compatibility effort is not ok mainly since it prevented them of simply checking what will happen to a LV8.5 user that will install LV17 next to it. I do think they should have tested it and let the user know they don't match during the installation instead of finding out LV8.5 is gone once LV17 is installed.

Hoovahh, for home use I like Win10, I just stumbled upon various issues with it when it comes to using it for work. The issues were: 1. No drivers - Just this month: a usb2RS232 converter didn't connect to a flash chip even though it is stated that the chipset is supported and before that, I had an issue installing LV 8.5 runtime on a Win10 NUK and had to replace it with a MiniDesk 2. and this is the main issue: NI says LV 8.5 is not supported and won't work on anything above Vista while it actually works fine on Win10 till you try to install LV 2017 next to it. This is actually an NI issue and not a Win10 issue per se As for the VirtualBench, if the driver is a dll and the wrapper happen to be vis I don't understand why it can't be supported on LV8.5 (ver15 is not the first one and it first supported LV13) unless it depends on MAX drivers which it doesn't if I understand correctly.

NI's support came back to me and said that actually, all the new vis I get from installing the driver/app are actually wrappers to a dll. This dll can be wrapped from Python for all they care (https://github.com/armstrap/armstrap-pyvirtualbench updated to virtualbench15) but then they won't give support. I thought that the meaning of this is that I can access this dll from LabVIEW 8.5 yet the support person said I can try but again I will get no support since the virtualbench requires a new Win version and LabVIEW 8.5 is not supported over a new Win version. How comfortable lol, this claim solves lots of support issues for NI and is actually a declaration of them stopping to maintain backward compatibility since LV8.5 does work over Win10. Soon Win7 will be at its end of life and NXT will be the only version supported. I bet you all hate Win10 for all the hardware access issues it brought with no compatible drivers. Prepare to hear: we don't support LabVIEW, only LabVIEW NXG in your configuration. When LV17 was introduced I tried installing it next to LV 8.5 with catastrophic results (due to the change in the unified runtime) so now that I'm using LV16 next to LV8.5 I asked if installing virtualbench 17 for LV16 will harm my LV8.5. The support guy said he doesn't think virtualbench 17 will install LV's runtime of LV17 but he said he recommends me to be on the safe side and install virtualbench 16 on LV16 (normally virtualbench 17 can install on LV16). Anyhow, to play safe and get the support, I'm going to write an engine in LV16 for the virtualbench and access it from LV8.5 (maybe close it as a dll). Wish me luck

Hi, VirtualBench comes with a driver for LabVIEW 2013 and above. I need to work with LabVIEW 8.5 in this project. Did someone try to save this driver to an older LabVIEW version? Creating such a version is a mess since you can't "save to previous' vis that refer to files in vi.lib. Should I try and do it? Thanks in advance

Admin: 0. Choose Functionality Admins + API + Requirements + Setup GIT Functionality Admins: 1. Scenarios (according to API + Requirements) + Documentation 2. Black Box testing around a function (empty VI with connector pane filled according to API) + benchmark 3. Update GIT with the empty function and its tests Users: 4. Users solve each functionality Functionality Admins: 5. Each function admin approves the tests under his/her control back to the main trunk if the requirements are holding Admin: 6. Approves a new stable version

Since you asked... I personally don't use ini files. I use MVC and thus all my controls are also in a class. I use traverse and save the class as a binary file. For config I use JSON or SQL. However, some projects demand ini file config so here we are

Hi, I tried using the openg ini vis and here is my two cents feedback: 1. Read operation locks the file and doesn't open it as read-only, thus, blocking a write operation. There is no permission or access handling in the package 2. Even though a numeric variable should be represented as 4 and not as "4", for example, inside a cluster every variable is represented with " around it 3. Read/Write panel from/to ini is a great concept yet it needs to be debugged. I saw strange results from variant controls for example that got 2 lines but I wonder if it can deal with two controls with the same label, for example. 4. It would be nice if the open could have got a file reference from the general file open vi that will handle permission settings or any other file operation before the openg gets involved. 5. Some VIs require a type input yet even after they know the output type they still give out a variant. Maliablle VI?

Update: I installed: 1. .net 1.1 (via slipstreaming) 2. visual studio .net 2003 full application (took me forever to find it) However. LV 8.5.1 runtime keeps giving a C++ runtime error. I went into the unpacked installer of LV 8.5.1 and found the MSI installer of the LV8.5.1 and it did run! Not all the MSIs of the packages run. Some report a missing Microsoft component. My app opens and hangs now which is a different behavior than before. Visual Studio SP1 patch still can't run saying that Visual Studio itself is not installed. How do I install the runtime now that I have the IDE? I can't find the runtime. Frustrating... update2: After nstalling VS2003 IDE the VS2003 SP1 was able to run, thus, I have VS2003 runtime and .net 1.1 yet LV 8.5.1 still fails on C++ error. The runtime MSI was able to run successfully yet I don't see National Instruments in add remove apps or the LV 8.5.1 runtime itself which is strange. My app still doesn't run on the NUC with Win10 64bit

Thanks rolfk! So to sum it up, since LV 8.5.1 is using GNU C Library version 2.2.4 I should install Visual Studio 2003 (or Visual c++ distribution 64bit) and it should work? I'll update in a few hours. Wish me luck.

Same here. It works from LV 8.6 to 2018. But from 8.5.1 and prior to that version (8.2 tested) it is not working. Tell me if you are able to install 8.5.1 on your NUC, just getting into the first panel of the installer

My NUC is running Win10 64 bit and I installed all the updates. The KB offers patches for win8.1, 8, vista, RT, server8 and server 2012 assuming that the issue is solved for win10 through the updates. Should I try installing the win 8.1 64 bit patch on my win10 64bit?

LV Runtime 8.6.1 and above works fine. Running the exe gets me to the installer panel. LV Runtime 8.5.1 and below won't work on my NUC. Running the installer gives an error before the installer's panel is up. There is a change in the windows environment (c++ .net ...) between the versions. Going to work some http://www.dependencywalker.com/ magic

I have 8.5.1 runtime running on win10. The fact you can run it on a U processor tailored for mobile says I guess that the issue is not the processor but rather some other NUC issue or C++ issue. Did someone here install LV on a NUC?

Hi, When I try to install LabVIEW 8.5.1 runtime or visa 4.1 on an Intel NUC with CPU i5 7260U I get: Microsoft Visual C++ Runtime Library Runtime Error! Program ........\LV RunTime 8.5.1\setup.exe This application has requested the Runtime to terminate it in an unusual way. Please contact the application's support team for more information. Just in case I installed Visual C++ 2005 redistribution and checked under add remove programs that the Windows feature of allowing version under .net 3.5 to run was enabled. This is not an ARM based processor so why does LabVIEW has a problem installing on the NUC?

The problem is not only with those services. When I need to send someone an exe that says hello world I need to send along LV Runtime with a lot of functionality that my exe doesn't actually require. It is the same with .net but this is not the case in python for example. The fundamental issue can be compared to VM vs dockers: In the VM you have a complete OS with all the security and tools while in the case of a docker you only take the functionality you actually need with you. Maybe a VM can get you better in depth security but a docker has much less attack surface.