0_o

Sorry for the cross post with the gdevconn ticket thread but I had to ask here too: Did you by any chance happen to record the GDevConn? Thanks in advance

Same question here.

And here goes our rock(et)star. With the global warming upon us, with leaders that can't even handle the little covid, I wish you good luck in your space mission. We will LabU forever.

Thanks for a delightful event

I've been waiting for this since graduating my CS degree in 2005. Thanks!

Amazing! Thank you all so much for uploading those lectures and a special thank you to those how presented them. I wish we had a strong technical CLA here but we don't have such a large community as you do.

remember to stop your subscription or else they will continue automatically to charge you additional 12$ each month just for the subscription if I understand correctly

Amazing! Can't wait for those videos each year. Thanks! Here is my preliminary feedback: 1. Youtube is great since you don't have to go through the FTP process yet they have some limitations and might prevent access to your own material - back it up 2. NI has some videos and pdfs which are related to those videos, maybe they can add links and support the wiki 3. Send a link to the wiki to the presenters so they will add their own material to the lectures that are missing 4. The Youtube videos are tugged NIWEEK2019 under LabVIEW Wiki. the LabVIEW wiki channel is empty and doesn't refer to those videos and the search for NIWEEK 2019 doesn't show a summary or those results Keep on the great work.

Thanks for all the replies. The .net works just fine, maybe the guy in StackOverflow used an old .net version or something went wrong in his code. I attached the vi that demonstrates that the bug is not existing anymore. Issue solved URI.vi

Thanks! That's a great example for me to learn how to handle DLL's correctly. However, I still get the 2250 error after choosing, for example, C:\ROI 123.bmp in the input. I was expecting to get file:///C:/ROI%20123.BMP

Thanks for the replies! Darin, I wasn't sure if I filled in the prototype correctly according to the help. LogMAN, this is the exact example I was working on. It used to work and now it gives me error 2250. Which brings me to what Rolf said... it is not compatible with Win 64bit. I moved the application from 32bit to 64bit. Rolf, I have MPR.dll in my Win10 64bit and I need the URI, not the UNC (I thought that code used to give the URI yet the last time it was used was before my time so...) What do I need to change in the code to make it compatible with 64bit, safe to use and that it will return the URI? Thanks in advance.

Hi, I'm trying to convert a local file path c:\... to a URI path file:///wdcwdc%20wdcwc... Windows MPR.dll (C:\Windows\System32\mpr.dll) does that conversion using WNetGetUniversalNameA https://docs.microsoft.com/en-us/windows/desktop/api/winnetwk/nf-winnetwk-wnetgetuniversalnamea#see-also For some reason, I don't get the prototype to work using the call dll function. Help will be much appreciated.

Hi, This is not specifically LabVIEW related: How do you organize important posts you read and want to save for the time of need? For example, I want to save an interesting post from Lavag/NI Forums or any other LV blog. This post might contain VIs and I would like to tag it in a way that will let me find it when it becomes relevant. I would like such a post to be saved locally like an RSS so that I'll get the new comments and won't depend on the site to keep the links alive. I see the veterans here keep track of all the new posts and even offer solutions by giving links to some old posts without having to search for them sometimes. Do I miss something? How do you organize it all? I hope to hear of some cool little RSS app that will let me search through the tagged vis and posts stored on my computer and not about some bookmark manager. Thanks in advance.

Search for Stitching in OpenCV -> Write Python code -> integrate into LV

After some more investigation, I found an old post that can be summed as saying: 1. Michael Aivaliotis: VM per project with installed packages in NI for code reuse 2. Smithd: Wonders if you can leverage Windows packagers like Chocolatey/Puppet/OneGet yet he got no reply I know how to handle VMs and I know now that I can do a multi deploy without pro. Did someone find a way to make Chocolatey etc work with LV?

I played a bit with the free tool and you found how it was written. Did you find the source code of that free tool? I would like to try and build on that automation and wrap my own flavor of state machine into it without writing everything from scratch

ShaunR: same condition as I hooovahh: Pro VIMP allows quick installation. Non-Pro allows it too (didn't know about that solution - thanks) and you are used to that manual process since you created your own set of tools that answer most of your customization needs. ak_nz: Works with VMs per project and paid for extra win licenses. You make me jealous yet even after I'll adopt the VM per project solution I would still like to have the set of tools hooovahh uses, for example, when I want to upgrade the projects to a newer version of LV. Moreover, I'm not sure how LV works with hardware from within a VM and if the client installation will work the same since they don't run a VM. This is important since it is not only I who will do the env update/pc replacement in a few years but rather a new programmer while I'll be in some other company doing some other amazing stuff. VM doesn't automate the Dev End requirements. If something breaks since one of the add-ons require an update you won't know what to do. It is either the VM works or it doesn't. Once you have automation for the configuration you can update parts of it and run regression tests to check if everything still works (or test it on different hardware with different OS). Ideally, Jenkins will take the source code once in a while and automatically install the testbench station from zero with the IDE Env -> build -> install -> run tests -> report

Hi, Most of us here build applications and add to it user manuals and readme files that instruct how to install the app and what its requirements are. However, we don't give the same level of documentation to the development env so that we could manage the source code from another computer in a few years. You might lose track of the LV version, modules, addons, vipms, folder structure, win version, 3rd party tools/activex/dll/db, LV ini, system settings, methodology/architecture, passwords and so on. I would love to hear how you approach that issue (docker VMs? Jenkins with a build from repository dedicated station?). For now, to make it simple, I'll ask if there is a way to install LV automatically without having to install and modify manually: 1. LV ini and configurations 2. All the VIPMs that I currently use 3. NI Modules 4. 3rd party tools like activex and dlls It takes hours if not days to install everything. Is there a way to have such a bundle automatically installed when for example I upgrade LV or reinstall it on a different computer without me writing my own installation automation as I do for customer applications? It will be crazy if I would have to update my installation automation each time I add a new VIPM or addon or save something new to the user.lib for each application I write for each version For the first stage, I would be satisfied with a one-click unattended silent install of 20 VIPMs with LV env customization

Next to your custom.vi there was statediagram.vi Is it the source code to NI's Automation and syncing of state machines? I would love to customize their tool and create automation for my own flavor of a state machine that will keep in sync with a UML diagram. It was tried in other languages and failed but for basic usage, it could be nice

I understand it will require more rewrite and I prefer not to go down that path. I'm not sure I understood what you meant by exploitation and acquisition (I guess I understand that one)

Python is like a candy store and it is so easy to deploy a package and start using it. I'll try to explain yet keep in mind that I prefer working with LabVIEW end to end mainly because of maintenance 5 years from now. I don't want to employ a C, python or whatever language programmer forever and ever. Building a well documented and automated tool in one language makes the development somewhat limited but the result should be much more stable in the long run without issues rising from bad communication between departments. Let's say you have several generic test-benches with different devices in them that can test different uuts. There are versioned generic drivers for those test-benches that can be operated via an API. I'll open the browser and communicate to the server back and forth through xml rpc. The server will decide which generic driver to deploy and through celery it will decide which uut is going to be tested where and when and by whom. The server will send the relevant flow of uut test. The db with matchmaking of station+uut+sequence of a test is mongo db since the structures are not as strong as in sql, it fits the development in a much more harmonic way. Take notice that this way a control in a function doesn't have to keep all the inheritance limitations in an OO HAL. You simply deploy the relevant test sequence. Finally, Kibana will create reports from the results collected with recipes which are fast again since the mongodb is tailored to the development and doesn't enforce an sql design which might be slow for a future query that the sql design was not optimized for and it is nearly impossible to optimize it in this stage of the development. Factory floor results accumulate fast and in a matter of 5 years, it will be hard for the sql query to want to run given the timeout and optimization you set when you designed the system. A kibana recipe tailored for a mongodb that is in harmony with the software design will be fast even over huge datasets.

This is actually the real alternative I'm considering: I thought about leveraging mongodb with kibana and celery with xml rpc Python will load an API sequence from the db that suits the specific station and specific test while the API driver is preloaded also into the station according to the SQL (it can be a Python driver or whatever). It bypasses all the OO HAL architecture. As an OO devotee, it is hard for me to go the SQL path but I must admit it is much less breakable. However, that will make me give up most of my sequencer and write much of it from scratch

The current version of the sequencer uses visa and scpi. It even allows me to add functions to the API through SCPI standard. The drivers can use DLLs and .net DLLs but those calls can't be extended beyond the API. I wanted the redesign partially because new drivers come with .net dlls and extending the API through scpi won't always work. Inheritance, on the other hand, will allow me to extend the API but it is a bit more complex if the GUI panel is also inherited and what will happen to the extra controls if I replace the driver through in the sequencer. I know LVLIBPs are fragile but I'm used to them and so far I can't see why I must use a C DLL as a layer between the sequencer and the driver. Can you refer me to Rolf's original wrapper DLLs for LabVIEW post? There are lots and lots of them out there.

Thus, I thought about leaving the DLL behind and move to LVLIBP Actors. The specific instruments will inherit from the top-level LVLIBP that acts as an API. In the Sequencer's panel, I call the API functions but load through inheritance the specific driver instance. This way I'll even remove a layer: the sequencer's panel is still there but it calls the specific inheritance LVLIBP that overrides the low-level functions but still gets the high-level functions from the parent API LVLIBP Actor.

Can you elaborate which hoops for example?