LogMAN

I'm putting this out here in case anyone missed it. NI has made all of their online training courses available for free to the global engineering community. The period was just extended to at least May 31, 2020 (previously April 30, 2020). Those who are new to LabVIEW and want to start with LabVIEW Community Edition should take a look at Getting Started with LabVIEW Community Edition. For further reading, check out NI’s Response to the Evolving COVID-19 Situation.

You are unable to activate the community edition with a pro license. It is always activated with a 365-day community license.

NXG 5.0 🎉

During installation you must accept the license agreement. Only for non-commercial use. It installs to "<National Instruments>\LabVIEW NXG 5.0" (same as pro) VM seems to work for me this time (probably because installation is actually offline).

This works for me: https://www.ni.com/en-us/support/software-technology-preview.html And I always thought the only way was via the beta program: https://www.ni.com/support/beta-program/

That is even better, haven't thought about it. Is there any chance of this changing? It would also be really great to have an idea exchange for NXG to discuss things like this. I want to support the effort, but sending out one-way tickets is very frustrating Thanks for reminding me, this is something I'm very excited for (and almost forgot about 😅)! You are right, those icons make it super easy to distinguish. Kudos for spending time on this

(Un)fortunately only someone who actually worked with CG is able to tell the difference, which makes NXG easier to sell to new customers than existing ones. Just a few clicks and you get your shiny graphs, overviews or packages. @Aristos Queue mentioned before, that NI lost business opportunities because of the old fashioned UI of CG. I'm pretty sure we are not the target audience of NXG at this point. Maybe in the future. Until then we can still spend our money on CG. Really, there is no incentive for NI to listen to our complains right now and I don't expect them to. Nevertheless, I'll keep an eye on NXG and on how it evolves in the future. Until then we can share our experience and ideas here and prevent each other from regretting horrible decisions 😉

Yes, the execution system hasn't changed but the appearance did, at least from a users perspective. LabVIEW CG has a clear distinction between the two, which doesn't exist in NXG. Classes and typedefs are both represented by the same kind of object (G Type). Although their abilities and representation is different, they are represented as the same kind of thing. If you take a control in LabVIEW CG and turn it into a class, you choose "Convert Contents of Control into class" and it becomes an entirely new type. In NXG, however, you can simply add class functionality. Now, unless a typedef is a class in secret, there is no way to simply add class functionality without converting it into a class first. Maybe I'm reading too much into it, but this is how it appears to me. Yes, the amount of types and what they represent didn't change and I understand the technical reasons for how they are implemented, but why use the same file extension? I work with engineers who don't know the difference between a class and a struct (and they don't care). What I'm afraid will happen is this: Here is the same thing in CG For all I care, the file contents of a typedef can be equivalent to a class. I don't even mind if a typedef was a class in secret, as long as they are easily distinguishable by the end user (i.e. me). That is currently not the case. That is good news. Maybe it was addressed in 5.0, can't wait to try it out. Need to wait for the VM to finish though.

You mean the same committee that works with Visual Studio all the time? I wonder where they get their ideas... Yes, that is a bummer. Actually, the thing they call "G Type" serves as a strict typedef, but it is really just a class that doesn't inherit from gObject (it inherits from Void). Since classes cannot be nested in LabVIEW CG/NXG, the only way is to put both of them inside a common library. Now, where have I seen this concept before...

@Neil Pate Thank you so much for sharing your thoughts. I have also been playing with NXG (working through the NI online courses) for the past few days and my impression is very similar to yours. NXG has a lot of interesting and useful features that I really want to use as soon as possible but at the same time there are so many little things that either don't work, are missing or very annoying to use. At this point I'm still interested in learning about all the features of NXG, without any intention to use it for any serious application in the foreseeable future (3-5 years). Nevertheless, this is a chance for me to give feedback to NI on all those little things. With NXG 5.0 around the corner I hope they address many of the "obvious" problems in 4.0. In any case, I intend to treat it as an early-access platform rather than a released product. In my mind NXG 4.0 is really NXG 0.4. One thing that really frustrates me is that there is no platform to suggest ideas and vote on them. The feedback system in NXG is a one-way ticket. You can do it from an open ended wire branch, which is one of those annoying things not intended by NI. Create an open ended wire branch, right click on the end of that wire and create the primitive you desire. You can see in the screenshot that the menu allows you to access the array palette. Not very user friendly imo, but still better than surfing the palettes on the left.

You should include a link to make it easier for others to find: https://forums.ni.com/t5/LabVIEW/This-class-control-or-constant-is-permanently-broken/m-p/4040676 No, this is the first time. However, I used the LabVIEW Resource Editor to look at the default data of those controls and they expect the class library inside a project library ("BBP Database Processor.lvlib"). <DefaultData>"%00%00%00%011%1CBBP Database Processor.lvlib%12Operations.lvclass%00%00%00%00%00%00%00%00%00%00%00"</DefaultData> You probably moved the class out of the library without saving its members (not sure about the exact steps, actually). You should revert your code to the last known good state. Hopefully you have version control in place. Alternatively you could try moving the class library back inside the project library. That might fix the VIs.

I don't know of a way to do this OS independent. Here is a VI that gets the monitor and workspace area for any monitor, given a screen coordinate. Of course, this only works on Windows. Workspace.vi

Cross post: https://forums.ni.com/t5/LabVIEW/Data-Variable-Toolkit/td-p/4032397

I don't think that is possible. That said, the sources are located at <vi.lib>\AppBuilder

Not that I have ever done it, but the sources are located at <labview>\resource\dialog\PreferencesDialog. There is even a page template, so it might be possible somehow: <labview>\resource\dialog\PreferencesDialog\PreferencePages\pageTemplate.vit

Indeed, there is (to my knowledge) no way to achieve what you want with pure dataflow. You could put your string in a DVR and make it part of the parent state. As long as you keep the DVR contained inside the class, its behavior is well defined and can be documented. Of course, anyone who uses the class needs to be aware of the caveats.

Yes you can. Have a dynamic dispatch EventHandler.vi that handles the events from Parent in Parent:EventHandler.vi and a Child:EventHandler.vi for every child. Use Call Parent Method in Child:EventHandler.vi parallel to the event loop of the child. Only the Stop event needs to be handled by each child. Here is an example I put together (saved for LabVIEW 2013): Reusable Events 13.0.zip

Actually, if you turn your cluster back into JSON you can compare it to the original JSON string to see if there are any differences. The string is empty if every element is defined in the source string. Try this: Extract Parameters.vi Notice the "Differences" string, which lists all differences (missing elements) in your source JSON string.

@ThomasGutzler here is a version that does most of what you describe. The order of elements inside Parameters doesn't matter. You can use enums. It doesn't matter if the JSON string has additional elements (no error) However, you don't get an error if an element is missing ("two" in your example). That would require something like a "strict" mode, which I don't think is supported by JSONtext. Unfortunately code is removed from VI snippets on LAVA, so here is the VI. Extract Parameters.vi

You can change your terminals to dynamic dispatch at any time by choosing This Connection Is > Dynamic Dispatch Input/Output (Required) at the terminal block. You'll find that this option is only available for class inputs and outputs. To change your VI from static dispatch to dynamic dispatch, simply change both - input and output terminals - to dynamic dispatch.

Not necessarily. Controls, Indicators and local variables have "built in logic to prevent front panel updates when continuously updating the same value. This prevents front panel re-draws". You can achieve similar results by deferring FP updates. Of course, writing to the control or indicator directly is the most efficient solution, because they "do not need to de-reference pointers, nor make copies of the data in memory". For your specific case, perhaps you can update the UI less frequently to reduce CPU load. Displaying a new value every 100 ms is more than sufficient for most applications. If you have a lot of graphs, pictures, etc., consider reducing the amount of data and update them only when necessary.

Here is a KB article regarding the differences between controls and indicators, local variables and property nodes: Control/Indicator, Local Variable, and Value Property Node Differences There is also an article that explains the different threads in LabVIEW and what they are used for: How Many Threads Does LabVIEW Allocate?

The front panel should be visible during the test to ensure that it is actually redrawn. It should also contain the necessary number of indicators to make both cases are comparable. If you reuse the same reference multiple times and defer panel updates, it only measures the iteration time of the For-loop + a single redraw, which is not the same as updating the UI on every loop iteration. Here is a version of your VI that has 100 boolean indicators on the front panel and is visible during test (it is also important to have all indicators visible on screen during test): MethodPerformance.vi On my PC the differences are much smaller with this version (if you set the number of elements to 1, the number of updates is roughly the same).

You need at least four characters. Try "DLLs".