Jump to content

0_o

Members
  • Content Count

    181
  • Joined

  • Last visited

  • Days Won

    4

0_o last won the day on January 31

0_o had the most liked content!

Community Reputation

9

About 0_o

  • Rank
    Very Active

Profile Information

  • Gender
    Not Telling

LabVIEW Information

  • Version
    LabVIEW 2016
  • Since
    2004

Recent Profile Visitors

1,197 profile views
  1. Search for Stitching in OpenCV -> Write Python code -> integrate into LV
  2. 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?
  3. 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
  4. 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
  5. 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
  6. 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
  7. 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)
  8. 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.
  9. 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
  10. 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.
  11. 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.
  12. Can you elaborate which hoops for example?
  13. 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.
  14. 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?
  15. 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?
×
×
  • Create New...

Important Information

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