Jump to content


  • Content Count

  • Joined

  • Last visited

  • Days Won


G-CODE last won the day on May 29

G-CODE had the most liked content!

Community Reputation


About G-CODE

  • Rank
    More Active

Profile Information

  • Gender
  • Location
    San Francisco Bay Area

Contact Methods

LabVIEW Information

  • Version
    LabVIEW 2015
  • Since

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. The two people who gave this presentation might be able to point you in the right direction.
  2. Oh, you can turn it off.... Well previously I was using the right-click plugin, so I was happy to see it appear as a feature in 2019. When it comes to software, over the years I have adjusted my attitude by telling myself to "expect everything to change all the time". That way I'm not frustrated every time I have to reteach myself something. On the upside, it's probably a good mental exercise to not allow our muscle memory to become burned in. Think of it as cross-training for the brain. 🙂
  3. Now you've got me thinking. I'm so habituated to creating typedefs, events, and registrations for every message. Maybe there's a better way...
  4. I have to be careful what I say here because I haven't explored Messenger Library, but my inclination is to think that I'm going to have to know the type at some point in time whether it be at edit time or at run time. So at what point in time would I rather know it? I just downloaded the package and flagged your YouTube videos to watch.
  5. Tell me about it! I think I've written seven of them so far and every time I create a new one I have to reference my previous modules to help me get the new one working. It's not trivial. For that reason I moved complex logic outside of DCAF to a higher level. DCAF manages I/O like scan engine, serial/modbus instruments, calculated tags. I wrapped DCAF in a subsystem that all other subsystems must use to access I/O. Since DCAF exposes I/O data through NI's CVT, I make sure not to use the CVT elsewhere throughout my application as that would bypass the protections I put in place for writing to tags.
  6. That doesn't necessarily have to be true if you're willing to dig in to specifics of existing frameworks even if you haven't spent a lot of time developing with them. For example, Antoine points out that DQMH has good scripting tools. I agree with him, even though I haven't developed a large project with it. DQMH seems like it makes it very easy to create new messages with custom data types. Those are good suggestions to add to the comparison chart! This raises the question of what a framework should be: process startup and management, dependency management, data management, interprocess communication, etc... The answer is probably different for everyone. It depends on what's important to the project and the developers working on the project. Now you've got me interested in digging into Messenger Library which I've never taken the time to do. SMO and DQMH assume you are going to be using events to broadcast and receive messages.
  7. SMO. I'm guessing Francois will say the same thing since he wrote a large part of it. Several months ago I was comparing three common community frameworks and I had Francois chime in. I attached a screenshot of what we put together with our rankings obscured. If he's ok with me showing it, I'd love to reveal our rough rankings for the categories shown. My superficial summary of each? Actor Framework - you better love having LOTS of classes in your project and opening DO methods to figure out how the code works. JKI SMO - Use this framework and Steven Mercer will castigate you because no human alive can write code with reference class data that isn't riddled with race conditions and bugs. Honestly though, if you're that worried you can impose some rules when developing with this framework to make it more actor-like. DQMH - The fact that it was developed for customers who don't understand object oriented programming suggests that if an experienced developer wants to combine it with classes that it might be unnecessarily complicated. Sure enough, I watched the presentation on how to do hardware abstraction with classes and DQMH and it confirmed my suspicions. It makes one think about what a framework would look like if your initial design goals were NOT to hide classes from less experienced developers. Turns out that framework might look something more like SMO. In the same project that is using SMO, I'm currently using DCAF at the lower level to manage I/O because there are hundreds of I/O tags. Now that I've spent a fair amount of time developing a variety of DCAF dynamic modules for this project I think I have a good idea of DCAF's strengths and shortcomings. It is open source so if I want some of the bugs and nuisances fixed, I'm going to have to fix it myself. Whoever wrote it got us 80-90% of the way there, but that final polish is going to take a fair amount of work. A lot of the code under the hood just ain't that pretty and some people don't really care about that. I do so I find myself getting annoyed every time I dig into it.
  8. Can you show me how to make LabVIEW crash by doing this? I created and destroyed 1 million DVRs that were cast to integer and cast back to DVR and couldn't get LabVIEW to crash. Attached VI made with LabVIEW 2013. DVR to integer_2013.vi
  9. There's this reference design framework, but as far as I know it doesn't have scripting to create accessor methods. https://github.com/JKISoftware/JKI-State-Machine-Objects
  10. I'm happy to report that the bug seems to have been fixed. I opened the example code I originally posted using 17.0.1f1 (32-bit) and the buggy behavior has gone away.
  11. It might exist in 2015 as well? I realize if we can't make these issues reproducible then it's difficult to report. I'm going back and forth between two projects right now - one uses LV2015 and the other uses LV2017 - so I'm forming opinions about the apparent stability of each. The LV2015 project is YUGE!!! and it's mostly stable as long as I don't right-click on anything in the project Dependencies folder and select 'Why is this item in Dependencies?' which will instantly crash LV. The safer bet is to right-click an item and select 'Find>Callers'. So one of my few gripes with 2015 is I've seen some really strange dependency issues that have been difficult to track down because there are no typedefs, globals, etc. in these classes that would cause dependencies to exist. The LV2017 project only has about 50 classes so far, but the latest issue I'm experiencing isn't hard crashes, but the project getting stuck with a spinning wheel indicating it is working, but it just never comes around and I have to force quit the application. It seems to happen as soon as I right-click a class to save it after I've added some methods. I'll give it 3-5 minutes in hopes that it will finish whatever it is doing, but every time I eventually have to force quit and restart LV.
  12. I've been encountering so much strange behavior in the 2017 dev environment that I started taking screenshots of all the weird stuff I was seeing and I finally just gave up. I already mentioned the weird stuff with parallel access DVRs, but I keep getting some non-parallel DVRs where the wire in the DVR in place element structure is just broken for no reason. Reattaching seems to fix it for a while. One screenshot I did keep was an error state that occurred from a class appearing as a duplicate within a Typedefs folder (attached). Don't ask me how that happened. How can a class exist in two places? It certainly didn't exist in two places on disk and definitely didn't exist in the typdefs folder. Oh, and if 2017 seems to be eating up processor usage, but you have NO processes running and everything is just sitting there idle, try closing the breakpoint manager window if you have it open. That worked for me. Like I said, this is just a partial list...
  13. Glad someone else is seeing the same behavior in the example I posted. The fact that you were able to create a new VI and couldn't reproduce the behavior is indicative of what I've been experiencing. These bugs are intermittent, but the example I posted on the NI forums wasn't the first time that happened to me. LabVIEW didn't crash while I was working on the example I posted. I've got another example that exhibits the same behavior and uses code from the actual project I was working on. I haven't yet determined what will cause the code to compile that way, but imagine how difficult and strange it is to track down these bugs when all of a sudden your code just stops working. Another strange artifact I've seen by creating accessor methods this way is that sometimes LabVIEW has changed these VIs to reentrant execution and turned on inlining. I can't tell you how many times I've examined the execution properties and found these settings changed, yet I had never changed them. I definitely wouldn't turn on inlining unless there was a good reason to do it. What I've concluded from this is that DVR parallel read-only access is really buggy and shouldn't be used. It seemed innocuous enough that to turn it on for a read method shouldn't have caused any problems. After spending quite a bit of time developing a project in 2017, I agree with Neil Pate's sentiments expressed last week. The LV 2017 editor has some issues. I'm going to keep moving forward with this project in LV 2017, but if I had to start again from scratch, I'd pick LV 2015. The editor in 2015 seemed to remain responsive and snappy on big projects, unlike 2017 which will (at times) slow down to a crawl when all you're trying to do is move something across a block diagram. Additionally, I haven't mastered exactly when to press the 'W' key to turn of maintaining wire connections so that feature seems like more of a hindrance than it is helpful.
  14. I just posted this over on the NI forums. Can anyone else confirm. This seems really strange, but I still think I might be missing something. I've got a probe on a block diagram that doesn't agree with the data coming out of the VI that is the source. https://forums.ni.com/t5/LabVIEW/Parallel-Access-DVR-Bug-LV2017/m-p/3696695#M1039519
  15. You can easily instantiate a child class at runtime. You can launch your application with only the parent class in memory until you specify which child class should be instantiated. Each of your child classes can be placed in their own libraries (LLB or packed project library 'should' work). The path to the class in the library can be passed to the 'Get LV Class Default Value' function as shown in attached. However, without looking into it more, I'm not sure this really solves your problem since you are trying to load code that is specific to a LabVIEW version. It sounds like you want to create a parent class that can be opened with either LV2013 or LV2015 and then dynamically load a child class that could have been created with either LV2013 or LV2015. Is that correct? -Eric
  • Create New...

Important Information

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