Jump to content

Fab

Members
  • Posts

    193
  • Joined

  • Last visited

  • Days Won

    15

Posts posted by Fab

  1. On 12/3/2019 at 9:45 AM, Fab said:

    @Jim Kring

    What should my customer include in their about page since http://openg.org doesn't work anymore?

    Thanks,

    Fab

    Hi @Jim Kring,

    My customer is back asking what he should be including in their about page since http://openg.org doesn't work anymore?

    He wants to make sure he is respecting what the license says and giving a link to people to openg.org.

    Thanks,

    Fab

  2. I agree that the XControl questions should go. XControls will not make it into NXG anyway. When I teach Advanced Architectures in LabVIEW, I mention what XControls are but I skip that section because I don't think they should be used for new development.

    I do recertify by points but I am already very active in the community. 

     

  3. 10 hours ago, hooovahh said:

    I'd argue this should probably go under contributing code, not finding code.  Either that or going under the Beyond Basics Training where more advanced topics are discussed.  I might be wrong but Reference Designs Portal isn't really a place I would see going to find a toolkit, or example on how to do some operation.  It seems more like a place to understand design patterns, and structure code.

    I will let @Christian_L add to this. I was suggesting to put it in the section looking for code because the Reference Designs already solve lots of problems that people who are starting from scratch might not know about. Instead of reinventing the wheel. The reference designs cover everything from simple libraries, design patterns all the way to complete application architectures. When I teach Advanced Architectures in LabVIEW I point people to this page and I often hear: "why didn't I know about this earlier before I went and reinvented the wheel". 

    If you prefer to include it under Beyond Basics Training, that is fine with me, as long as it is included somewhere on the landing page.

    Thanks,

    Fab

  4. Excellent work Hooovahh! I hope it is not too much trouble to keep it up to date.

     

    I would like to add to the "I'm Looking to Find Example Code and Toolkits" section the NI Reference Designs Portal at http://ni.com/referencedesigns

    It is a collection of reference designs that Christian Loew and his team keep updating. It started with only Systems Engineering reference designs, but now it includes several other. 

    Thanks for adding the links to the videos we have for source code control, you could also link to our blog SCC category, so as we add new blog posts and videos, the link will be up to date. We have videos for SVN, Hg, and Git: http://delacor.com/category/scc/

    Thanks,

    Fab 

  5. I know this is an old post, but just in case someone else tries this code...

    I just downloaded the code and the TSPopu.FG.Poup.vi was broken, I made a minor modification in the Show case to have the event registration pass through (I don't think the Generate User Event.vi does anything to the reference itself. The code seems to work fine after this change.

    modified Show case.jpg

    • Like 2
  6. This is an old thread I know.

    I stumbled upon it while trying to figure out something else.

    I just thought to add for any future readers that if all you want to do is visualize the "gibberish" data returned from the serial port. Just wire an indicator, right click on it to select "Display Style" and then click on the little box that appears on the left and select Hex Display.

    You can also just right click and select Hex Display, but I like to make the display style visible so others know that is the intent, to display the Hex as Hex.

    Fab

  7. 13 hours ago, GME said:

    To prevent this from happening again to see the error after a long build process, I have created a VI to search for broken VI(s) within my project dependent classes before the build process.

    checkBrokenClassVI.PNG

    Cheers,

    Jimmy

     

    Jimmy,

    This is a good alternative if you don't have access to the VI Analyzer Toolkit. I believe the toolkit is included in the Developer Suite version of LabVIEW. 

    Check out: https://forums.ni.com/t5/VI-Analyzer-Enthusiasts/List-of-VI-Analyzer-Toolkit-Tests/ta-p/3510239

    The test is called "Broken VI" and it is listed under VI Properties. 

    Granted, the VI Analyzer test looks for any broken VIs, regardless if they are in a library or not. 

    At Delacor we run a suite of VI Analyzer tests before building to find this and other nuisances (some times show stoppers) that could jeopardize a long build. 

    You could convert your test above into a Custom VI Analyzer test and run it in conjunction with other tests that already ship with the toolkit.

    Here is a short video describing what our Delacor VI Analyzer Tests package does. We have created customized versions of this toolkit for our customers. Perhaps you could create something similar.

     

  8. logo-delacor-unbalanced-300x129+copy.png


     


    Delacor is thrilled to announce the release of the DQMH Toolkit 2.0 to the LabVIEW Tools Network (LVTN).


     


     


    This 2.0 release brings a number of new features (they are awesome and worth the download alone) and improvements.


     


    These changes were inspired by our desire to give you the best possible experience for rapid LabVIEW application development and by the great feedback we received from you.


     


     


    We have incorporated some of this feedback into our 2.0 release and will continue to do so on future releases.  You can read the release notes for a full description of all of the changes.


     


     


    At your convenience head on over to the LabVIEW Tools Network and grab the DQMH Toolkit 2.0 directly or upgrade by refreshing the package list in VI Package Manager.


     


     


    If you are upgrading from an earlier version of the DQMH Toolkit please ensure that you upgrade the Delacor QMH package that will take care of upgrading all the toolkit required packages.


     


     


    All that remains is to launch the DQMH and get to work!


     


     


    Many thanks,


    Team Delacor


    • Like 2
  9.  

    But your right, it is a problem.  Even though I could show someone what to do in minutes, it’s easy to have no idea what the first step to do is.  Fabiola is fighting that problem by providing several instructional videos for her new Delacor framework.

    ...

     

    As Fab points out, one can also provide a junior developer simplicity via a simple API or set of tools that encapsulates complexity.  And personally, I think there is simplicity in standardization, since there is so much effort in learning code structure.

     

    We are also fighting the problem via the scripting tools. Automating the busy work and abstracting that away from junior developers. In our experience, explaining the concept of user events and how the information is transmitted from DQMH module to module has never been the problem. The problem is when the junior developer has to remember all the steps needed to create a user event. With the scripting tools we automate most of the busy work and let the junior developer do the final connection of editing the event structure case to handle the specific event, but they don't have to worry about remembering to add the new event to the typedef, to the destroy events, to the create event, etc, etc.

     

     

    Yeah that's part of the problem, the only "standard" on making an actor design at the moment is the NI Actor Framework.  This standard is not catching on in the advanced developer community.  I can speculate why but the point is, if standardization is key to adoption, then all of these different designs might be adding to the noise.  Which is hard for me to say because lots of what i see in the DQMH, and JKI Objects I like a lot.  And will likely be using one of them over the Actor Framework.

     

    The value of the DQMH videos, and scripting code should not be understated.  Conceptualizing, and designing actor based software is confusing at first.  Being able to say "Here watch this video for a few minutes, and you'll get the basics." is going to be a very valuable tool.

     

    standardization was a big part for the Delacor team deciding to use the NI QMH as our springboard. The producer/consumer and QMH templates were the ones we realized most of the junior developers we encountered were familiar with. This is one of the reasons the Main module looks a lot like the NI QMH template, with minor exceptions. 

     

    Glad to know that DQMH is one of your options for your future projects. Let us know if you decide to go with it. 

     

    Also good to know that you find both the videos and the scripting tools useful. This inspires us to continue to create such tools for the community.

    • Like 2
  10. Have you never had the use case of an arbitrary number of actors?  â€œRestart†works if you want 0 or 1, but what about N, specified at run time?  I made a “Popout window†UI actor just today to support an arbitrary number of independent windows in an application.  The actors start as needed and shut down whenever the windows are closed.

     

    We address this via the Cloneable DQMH Module. It already comes with clone management and at run time the N number of instances to launch can be selected. We have an example of this in the shipping example. The DUT is a cloneable module.

     

    The benefits of this type of design is the only thing that is asynchronous (and more difficult to debug) is the actual UI, not the actor it self handling all the messages.  Probing and opening that actor was easy because it was on the block diagram of my main running VI and I could hold CTRL and double click to open the BD.

     

    When a DQMH module is created, the tester comes with a button that shows the block diagram of the DQMH Module Main. If the DQMH module is cloneable, then it will show the block diagram for all instances if the ring is set to "All" or it shows the block diagram for the requested instance.

     

    This feature was not included in the shipping example, but you can see it in a project created via the DQMH Project template or by adding a DQMH module to your project.

     

    The benefit in my mind was simple code.  Any LabVIEW developer with CLAD experience could open the code, find where actors were started in parallel (because they were just subVI calls) and find what was going on.  No nebulous cloud business, starting and stopping not knowing what is running or doing what.  Just open the VI and see.  I'm not saying it has to be this way but it was powerful and simple.  The next actor type framework I adopt is going to have those same requirements.

     

    In our experience, junior developers get around via the DQMH API Tester to know what is running or pressing the "Show block diagram" button on the tester to see what is going on in the DQMH Main.

     

    Most of the time they do not need to go that deep and having a simple API with simple API calls: Start, Show Panel, Hide Panel, Stop, etc means they can do simple VIs that just call a chain of these calls. If they need to debug, they just need to run the tester and use it as a sniffer.

    • Like 1
  11. Fab,

     

    This looks really cool, I look forward to digging into it.  I haven't looked through all of the sessions next week, any chance you will be presenting it during one?

     

    Hi Jordan,

     

    I will be using the DQMH shipping examples for the demos in the Reusable code presentation and we use DQMH for the project described in the Curing Cancer presentation, one of our customers will be presenting about his experience using our modular approach to his projects vs his old code & fix approach. Chris Roebuck will be using DQMH in his demos to show how to leave the coding and debugging in LabVIEW and call the public API from a DQMH via TestStand sequences during his LabVIEW Developers guide to TestStand presentation.

     

    You can also watch some of the getting started videos that we have created for DQMH, there is a link to them at: http://delacor.com/products/

     

    Here are the presentation details:

     

    TS6420 - 5 Tips to Modularize, Reuse, and Organize Your Development Chaos

    Fabiola De la Cueva, Delacor

    Tuesday, August 4, 3:30 PM - 4:30 PM  Room 19A

     

    TS7238 - Curing Cancer: Using a Modular Approach to Ensure the Safe and Repeatable Production of Medicine

    Duncan MacIntosh, PerkinElmer

    Fabiola De la Cueva, Delacor

    Wednesday, August 5, 3:30 PM - 4:30 PM   Room 19A

     

    TS6421 - Don't Panic: LabVIEW Developer's Guide to TestStand  

    Chris Roebuck, Delacor

    Thursday, August 6     2:00 PM - 3:00 PM  

    Room 16B

     

    Hope to see you there,

     

    Fab

    • Like 1
×
×
  • Create New...

Important Information

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