G-CODE

What about this... https://www.jki.net/profusa?hsLang=en or this... https://www.jki.net/radx?hsLang=en or this... https://resources.jki.net/smarter_sorting or this... https://resources.jki.net/femtometrix-case-study or this... https://www.jki.net/apollo-fusion?hsLang=en or this... https://www.jki.net/kairos-power

Same thing just happened to me in LabVIEW 2020. It's the malleable VI with the broken wire.

But this isn't the issue is it? The front panel is updated long before the VI finishes executing.

... to further elaborate on merging. Note that we have used that word with respect to branches in source control and also with respect to files. As I previously mentioned, if you're careful not to edit the same files in multiple branches, when it comes time to merge a branch, it doesn't require that you merge a file. Merging branches is easy as long as it doesn't also require you to merge files.

Bob, I can't help but wonder if you might be mixing up terms here. If you're talking about using code from one project in another you might be thinking about Submodules (Git) or Subrepos (Mercurial). Branching is typically done within the same project with the assumption that whatever work is done on the branch will get merged back into something considered the main or master. In LabVIEW, I suspect most of us try really hard not to modify the same file in multiple branches since merging VI's isn't as straightforward as merging text files. You might branch something to work on a feature that you're not ready to deploy, but you want to be careful not to also modify the same file in another branch because when it comes time to combine everything back into one (merge), the source code can't automatically reconcile a file that has changes in multiple branches. It leaves you in the position to decide which of the changes is the one to keep and which do you want to throw away or the worst case scenario - you think there might be unique changes in both of those edits that you need to figure out how to combine into one. Eric

1. Mercurial (with TortoiseHg), Subversion, Git (with Sourcetree) 2. I have no option but to love any or all of them because the alternative (no source control) would make my life a lot more difficult. 3. Yes and yes. It just depends on the project. I would prefer Git just so I was always using the one that everyone else in the world is using. 4. Subversion might be the simplest for you considering it sounds like you don't want to be using SCC in the first place. You mentioned wanting to use source control "within" LabVIEW and I think you can setup LabVIEW to work with SVN although I'm not doing it that way. However, your computer will require constant connection with the central repository. Also, last time I tried to create a branch on Subversion, I vowed I would never try it again. It's difficult to give up the ability to easily create branches once you have it. Mercurial is a distributed version control system and seems easier to understand than Git, but that might be because I have used it more. Git has plenty of horror stories written about it when people are confused in the beginning. Eventually they learn it and the frustration subsides. 5. Once you learn what you're doing, almost never. The major pain is just in the beginning while you're learning. There is likely to be more initial pain with Git. If you're a solo developer who is used to clicking the "Save All" button on the project every few minutes, transitioning to a more thoughtful workflow where you are mentally keeping track of what you have actually changed and only committing those files is going to suck - to put it bluntly. Yet another thing to think about! After all, who wants to think more? Imagine having to constantly interact with source control by constantly typing little notes about the work you just did. This might feel disruptive to your workflow. However, it's worth asking yourself why almost every experienced developer does this. One customer I work with uses SVN and the way they use it is single commits of all their work they did that day with no commit notes. Is this helpful? Well I guess it's better than nothing. You could return to some prior state of the code although it would be difficult to figure out what state you were returning to. Consider this option if someone told you that source control is mandatory and you're just trying to check a box so you can say you're using some "stinking" source control. If you're inclined to implement some best practices and you understand the software world interacts largely through GitHub and you would like to engage with that world, consider using Git. Keep in mind this will probably require more patience initially. Whatever you choose, I don't think there is any way to completely avoid the cognitive discomfort that can arise from learning something new. Eric Graham

I think it's really helpful to point that out. Thinking about this.... I can't figure out if now we are trying to explain why it's expected behavior or if we are trying to justify unexpected behavior (or something in between). 🙂

If it were an optimization then we should be prevented from placing breakpoints where they won't function as expected. I know breakpoints have been buggy for a long time. The fact that in 2015 I could remove the wait functions and get the execution to pause as soon as I ran the VI tells me that at least some of the quirks have been fixed over time. The fix is to place a sequence structure between the breakpoint and indicator.

Every time I encounter something like this, my first thought is, "What am I doing wrong?" Is this one of those known behaviors that everyone but me knows about? See screenshot. How is it possible to update an indicator if the upstream wire has a breakpoint that hasn't paused execution?

@drjdpowell, thanks for all the work you put into this really useful library. I noticed you have some timestamp conversion utilities that the SQLite library uses. I am confused by some behavior I am seeing when converting a string timestamp with a local time offset. Can you look at the attached screenshot of that function? Maybe this is expected behavior and I'm not understanding something. Thanks, Eric

This happened on a virtual machine that only had LabVIEW 2020 installed. VIPM was always configured to mass compile VIs after package installation. If this happened even when packages were being mass compiled, what else is lurking under the hood waiting to be found? I want to assume that had I built an EXE in this state, this problem would have gone away.

I was experiencing a whole host of problems running an application in LabVIEW 2020 (32-bit) dev environment. This function was giving me the wrong output. After an edit and save, the output of the function now appears correct. This is the first time I have ever seen this... 2020-09-11_17-18-49.mp4

The two people who gave this presentation might be able to point you in the right direction.

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. 🙂

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...

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.

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.

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.

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.

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

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

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.

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.

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...

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.