Jump to content


  • Content Count

  • Joined

  • Last visited

  • Days Won


Everything posted by 0_o

  1. 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
  2. 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.
  3. 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
  4. 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
  5. 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.
  6. 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.
  7. 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.
  8. Search for Stitching in OpenCV -> Write Python code -> integrate into LV
  9. 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?
  10. 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
  11. 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
  12. 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
  13. 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
  14. 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)
  15. 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.
  16. 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
  17. 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.
  18. 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.
  19. Can you elaborate which hoops for example?
  20. 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.
  21. 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?
  22. 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?
  23. 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?
  24. Please ask for clarification if something is unclear. By family I mean dmm/dio/scope/...
  25. 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.
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.