Kurt Friday

I'm excited to release ViPER ViPER is an Object Oriented design Framework that supports dependency injection and recursive object creation. Systems are assembled at runtime from a collection of pre-built components defined by an Object Definition Document. Please visit the project on GitHub https://github.com/kurtafriday/ViPER I've presented this framework at several GLA Conferences, for an overview and guidance please view. GLA 2021 https://labviewwiki.org/wiki/GLA_Summit_2021/Open_Source_ViPER GLA 2020 https://labviewwiki.org/wiki/GLA_Summit_2020/ViPER_-_A_LabVIEW_Dependency_Injection_Framework This branch of ViPER has been used by us to develop systems in regulated industries for several years, it's solid and reliable, however its windows only. I'm working on ViPER_WinRT which is compatible with Windows and RT and we have already used it for several systems. I'll be releasing ViPER_WinRT in the coming months. I'll work to get ViPER onto the VIPM Tools Network soon. I'm looking forward to the feedback and I hope you enjoy and get value from this framework. Ping me if you have any questions. kurt@medulla.net

Absolutely! you can plugin plugins to plugins. You can build rich object hierarchies at runtime using ViPER just feed in an Object Definition document and then it assembles itself. Would you like to have a play with it?

Hi All I just wanted to share my presentation "ViPER a Dependency Injection Framework for LabVIEW" that I gave to the 2021 GLA Summit I talk about ViPER and also the Test Executive we built using it

I'm excited to share it, should be ready after the new year. probably Github You can watch the latest presentation I gave at the GLA Summit here

Hi Lavans Medulla will be releasing its Test Executive framework as open source before the end of the year. I responded to a post here where people were after an Open Source Alternative to TestStand. I wanted to make this a new post as I don't want it to be misconstrued that our executive is a replacement or that we are anti TestStand, I think TestStand is a brilliant tool, I've used it and will use it where needed, however options are good to have and many of our clients only want a LabVIEW only solution. Our Test Executive is built on the ViPER framework which is also being made open source. You can view a presentation I did on ViPER and our Test executive here Medulla Test Executive Part 2 includes a demo. I'll be talking more about ViPER and the Test Executive at the GLA Summit. I'm looking for some power users who would be keen to play with it before I release it.

We’re looking at making our Medulla ViPER test executive open source. I presented the ViPER architecture and test executive to the Sydney LabVIEW User Group. You can view the presentation in the link below ViPER Test Executive Presentation I’m hoping to have this released before the end of the year but I’d be keen to have some early adopters.

Hi Lavans I'm working on releasing our Medulla ViPER Dependency Injection Framework to the community as an open source project. ViPER has been a labor of love that I have been working on for close to 8 years. The motivation to develop ViPER was to reduce the cost, time and frustration involved in deploying test systems in highly regulated industries such as medical device manufacturing. The big problem that ViPER solves is that change does not require you to perform a full top to bottom verification of the system, only the new or changed component needs to be verified. We used ViPER at Cochlear to test implants and sound processors and is the standard architecture used within the enterprise. ViPER was also used to develop a system to parallel test up to 100 Trophon 2 units simultaneously for Nanosonics by implementing a Test Server running on an NI Industrial Controller. HMI Clients were implemented on tablets for operators, engineers and admins. Although ViPER is useful for test its not used just for test systems, you can build any system with ViPER. ViPER is a plugin architecture, it implements a recursive factory creator that injects pre-built (and verified) components into a system at runtime defined by a Object Definition Document. ViPER can build rich and deep object hierarchies, even inject into ancestors as well. Components include soft front panels and attribute and configuration viewer and are built on GDS4 class architecture. ViPER systems are also slim and efficient because they are not carrying around redundant classes in their builds that may or may not be needed. ViPER includes an Object Editor that allows you to create or edit the Object Definition Document but is also a useful engineering tool allowing you to navigate the object hierarchy, configure and launch Soft Front Panels for any sub objects. Included is a Project template that allows you to create your own ViPER Components. I presented ViPER the GLA Summit last year and to the Sydney LabVIEW User Group, I've posted the Video of the presentation on LinkedIn, I'm keen to find a few gurus to have play with it before I release it. ViPER: A Dependency Injection Framework for LabVIEW Cheers Kurt

Thanks Eventually I'll add the ability to edit an item and read back the cluster Also right click and view an item such as an array as a waveform graph. If the item is another object then display its attributes as well. The Variant Probe looks cool I'll take a closer look

Hi All I'm playing around with visualising clusters as a tree structure. I've got some nice code working that I thought I would share. It's part of an abstract data viewer that I'm working on. Code is based on Open_G Variant and Open_G Config File tools ClusterViewer.zip

I had a similar issue thanks for the post I found I had to manually copy LabVIEW 2014\resource\lvimptsl.dll into the root of my exe

Hi All Apologies for not replying I didn't realise that there were posts here. Regarding the Pump example, its just a simple demo of the capability of the framework. Probably the best way to handle not pushing another pump volume command while it is already pumping is to have a busy state in the datamembers and don't allow any new pump volume commands to be placed in the queue until it is not busy. Spot on! In most cases all you need is the command queue to send commands into the process, however there are situations where you would want the process to message up to the public level. In the launcher there is a wait on occurrence, and that occurrence is the 1st thing that is set when the process is launched. We want a situation that when the launcher has completed execution the process is confirmed to be up and running. So the launcher waits until the process is live. The same is true for the close process, it waits until the occurrence is set when the process shuts down. I've tested inheritance and all works as expected, you can have parent active object and call its constructor within a child and the parent process is launched. Take a look at the Bike example, although the Bike is not active you could make the Bike active and the Racer would inherit the active capabilities of the Bike. A good example where you could use this is to make a general server class and the child is protocol specific.

Maybe Symbio could send the GDS and AddQ vi's that are in question to an independant 3rd party. Once the 3rd party has recieved the vi's Symbio could provide the passwords to their Vi's and AddQ can provide the passwords to theirs. The independant party can then provide a report on the level of similarity.

So some developers jumped ship from Endevo/Simbio to start AddQ, took the GDS sourcecode, repackaged it as their own and added a few bells and whistles to it, without your permission. The crazy thing is that if anyone wants to add OOP farmeworks into GDS all you have to do is contribute, and if you have ideas or sugestions on new features to GDS then Mikael would love to hear it. I'll keep using GDS, it Rocks, and I'm looking foward to contributing more.

Yeah, definitely but it seemed to have issue with this file as well. LV2009_ENG_32.exe->(ZIP)->Products/MDFSupport/MDF/MDFSupport1.cab->misetup.bin.F5D87C60_CF9D_4AC4_8480_40189BD11225

OK, I think this is a false alarm but I I think this needs to be investigated. I downloaded LV2009_ENG_32.exe from the standard download and evaluate LabVIEW link https://lumen.ni.com/nicif/us/lveval/content.xhtml However when I run the downloaded file "LV2009_ENG_32.exe" through F-PROT virus scanner I get the following virus detected W32/Virut.AI!Generic See the following report generated by F-Prot -----------------------------SCAN REPORT----------------------------- F-PROT Antivirus for Windows Antivirus Scanning Engine version number: 4.5.1 Virus signature file from: 11/4/2009, 3:23 AM Scan name: [Custom Scan] Path to scan: C:\Temp\LV2009_ENG_32.exe| Normal scan Also scan: Inside subfolders, Compressed files, Streams Scan started: 11/4/2009, 5:25:21 PM --------------------------------------------------------------------- [Found virus] <W32/Virut.AI!Generic (not disinfectable)> C:\Temp\LV2009_ENG_32.exe->(ZIP)->Products/MDFSupport/MDF/MDFSupport1.cab->misetup.bin.F5D87C60_CF9D_4AC4_8480_40189BD11225 [Contains infected objects] C:\Temp\LV2009_ENG_32.exe [Quarantined] C:\Temp\LV2009_ENG_32.exe->(ZIP)->setup.ini --------------------------------------------------------------------- Scan ended: 11/4/2009, 5:47:35 PM Duration: 0:22:13 Scan result: Scanned files: 1 Infected objects: 1 Disinfected objects: 0 Quarantined files: 1 --------------------------------------------------------------------- I've scanned the file through AVG but that particular variant of the virus doesn't appear in AVG's database. I've tested this on a clean uninfected machine, can someone else verify this if possible? If NI could also just confirm this is a false alarm as well

Hi Hacti Do the crashes now occur even tough you don't work on the original conflicting VI? Can you tell more about the particular vi that caused the issue?

Jim she is awesome, congratulations mate

I've just released GOOP Developer 2.3 This latest version is built under LabVIEW 9.0 and appears to resolve the Vista issue and also provides LabVIEW 9.0 compatibility. The source code for GOOP Developer 2.3 is also available. You can download the GOOP Developer 2.3 Installer and source code here

OK so you have a RS 485 to 232 converter. Probably the first thing to do is check that your serial interface is OK and your cabling is fine, this is always a gotcha. In my experience the first time you plug some serial device into your PC it doesn't work first time, its either that I need a null modem or my com port isn't setup correctly, so check all that. Add into the mix that you have a 232 to 485 converter you have compounded the issue. Probably try sending packets via hyperterminal and check them on the 485 side with a scope, its a good reality check.

Hi Hacti Does this happen when working on a specific project or VI, or will it occur if you start with a fresh VI and start playing with it? Does it happen in development or run environment? Take a look at this link from NI, it may shed some light.

The NI-OPC Server supports the UDC 3000 and UDC 2500 see the following Link http://zone.ni.com/d...p/id/6417#toc17 So with the NI-OPC Servers you can communicate to your UDC controller, in LabVIEW you just use DataSocket to read and write to items. Alternatively Honewell probably have their own OPC Server which you should be able to connect to. You mentioned the Burr Brown Converter, what type of converter is it? do you have more info?

OK I can replicate the issue, but I don't need to build it to see it. Steps to recreate 1) Place a Tab Contol on the FP 2) Make Page 2 the default value 3) Save and close the VI 4) Open the VI, Page 1 is shown instead of Page 2 Lecroy, having a go at the LabVIEW Development team is a little unfair. They work bloody hard do deliver a product that in my oppinion is Frikin Awsome. This bug is not a show stopper, just initialise it at startup with your desired value. Be proactive in the evolution and improvement of LabVIEW and report the bug to NI

Can you check your browser history for Saturday?

The problem is due to exe's now requiring an internal directory structure so they can handle building projects that contain classes or library's. So you want a solution that can check if the directory is internal to the exe. I had a play and found that the Get File Type.vi is able to return the type as Directory if the directory is outside the exe and Invalid if it is inside. I've modified your code to show this. mvcfgConfigPath_KF.vi