Jump to content

Leaderboard


Popular Content

Showing content with the highest reputation since 06/05/2019 in all areas

  1. 9 points
    So I wasn't there but there was a public announcement at GDevCon about a new edition of LabVIEW called Community Edition which is the LabVIEW Professional version (I read that as application builder included), and completely free with no watermarks for non-commercial use. NI hasn't made any post about timelines, or other details yet but I hear those are in the works. This is obviously a huge thing for LabVIEW as any monetary barrier to entry will discourage new developers from experimenting with LabVIEW. And then there is the fact that those that are familiar with LabVIEW, can keep up with the newest version outside of their company, or when they are between jobs.
  2. 7 points
    I've exported the OpenG sources from Sourceforge SVN to Github. It's located here: https://github.com/Open-G I'm hoping this will encourage collaboration and modernization of the OpenG project. Pull requests are a thing with Git, so contributions can be encouraged and actually used instead of dying on the vine.
  3. 6 points
    Why are so many things just that little bit harder in or weirder in NXG? I am trying to use it to make my first "real" application, in this case a relatively simple WebVI. I put this list down in the hope someone can tell me I am being dumb and there is a sensible way to do these thing Why can I not easily branch off a wire by clicking on it somewhere? Now I have to right click and select the option to create a wire branch Why can I not right click on a primitive to open the sub-palette for that thing to give me similar items. I can right click and replace or right-click and insert... Example, I have an existing 2D array wire I want to get the size of, there is no way for me to right click the wire to quickly open the array palette and then drop down a Size primitive I have to relearn the whole palette structure as all the icons have changed. OK that is fine so let me explore a bit and poke around but I cannot keep a palette open by pinning it? (OK so it turns out I can do this if I start the browse from the left-hand palette and then weirdly click the << arrow, but I am so used to opening the palette by right clicking on the diagram). Arg, then the pop-up help covers over the next item in the list 😞 The Align menu is so much less usable in that drab gray and single line. There was nothing wrong with the way it is implemented in Current Gen, why change this? The GUI is so dull in general. The colours are washed out and grey everywhere is just depressing. It sounds silly but it makes me not want to use it. Sorry, but MDI is not a suitable technique for anything other than the most trivial of applications. I like the really like the zoom but please let us pan with the middle-mouse or something similar Please pop open menu items as soon as I browse into them, rather than forcing me to click (looking at you Case Structure Cases and Align menus) Why are the icons so confusing. Please can someone explain how the picture below conveys any information that this array concatenation. Why can I not run a Sub VI in a WebVI? In order to test the correctness of a piece of code I have to move it out of the .gcomp to run in isolation, and this actually moves the code on disk What was fundamentally wrong with the Project Window in Current Gen? I have a vertical monitor that I use exclusively for displaying the Project window and it is amazing. I don't particularly like the new implementation but at least let me undock it! I am also not really filled with confidence that as my project grows in size it will not become overwhelming (yet another reason to keep Virtual Folders) This is just a small subset of the items I am currently struggling with. In general I am quite forgiving of new software, but I think NXG has been baking in the oven for something like 8 years! I appreciate that NXG has not been designed for me, rather I suspect it is targeted at a whole new audience of LabVIEW developer. As such I know my muscle memory is going to be really detrimental in getting me up to speed with this new way of doing things so I am trying really hard to not let that get in the way of my journey. Something deep down just makes me worry that the essence of what makes LabVIEW (current gen) so special has been lost in translation. It just feels like too many decisions have been made by people who are not actually very familiar with LabVIEW. This makes me a bit sad as I have no doubt that a ridiculous amount of engineering effort and love has gone into NXG (and am under no illusions at the scale of the task of rewriting current gen). All in all my experience trying to develop a non trivial (not by much though) application in NXG has further cemented my thoughts that I am going to have to stick with current gen for the foreseeable future. That said, strength and courage to NI. I will check back again in a few years. ps: I am really excited for the WebVI technology. Please port it to Current Gen so I can actually use it πŸ™‚
  4. 6 points
    Thanks for putting down all your thoughts and providing examples, Neil. I agree with every point you've made. Have you used the Shared Library Interface editor yet? That's some next level UI inconsistency. I wrote a couple of blog posts on my experience converting a small (< 100 VIs, < 10 classes) LabVIEW project to NXG (see Let's Convert A LabVIEW Project to LabVIEW NXG! Part 1 and Part 2). During the process I made a lengthy list of issues and came to the same conclusions many people have voiced in this thread. Of the issues uncovered during the conversion, some were due to missing features or bugs, some a lack of understanding on my part, but a surprising number were due to interesting design choices. The TL;DR of the blog is there is nothing in NXG for me to want to continue using it, let alone switch to it from LabVIEW. Which is sad because I was really hoping to find something to look forward to. Here's hoping for a LabVIEW NXG: Despecialized Edition!
  5. 6 points
    The New Data Value Ref and Delete Data Value Ref nodes will be able to be in inline VIs (and thus malleable VIs) in LV 2020.
  6. 6 points
    View File Hooovahh's Tremendous TDMS Toolkit This toolkit combines a variety of TDMS functions and tools into a single package. The initial release has a variety of features: - Classes for Circular, Periodic, Size, and Time of Day TDMS generation with examples of using each - Reading and Writing Clusters into TDMS Channels - XLSX Conversion example - File operations for combining files, renaming, moving, and saving in memory to zip - Basic function for splitting TDMS file into segments (useful for corrupt files) - Reorder TDMS Channel with Demo There is plenty of room for improvements but I wanted to get this out there and gauge interests. The variety of classes for doing things, along with VIMs, and class adaptation makes for using them easier. If I get time I plan on making some blog posts explaining some of the benefits of TDMS, along with best practices. Submitter hooovahh Submitted 12/12/2019 Category *Uncertified* LabVIEW Version 2018 License Type BSD (Most common)  
  7. 6 points
    All of the presentations are now on the LabVIEW Wiki. You can find them at: https://labviewwiki.org/wiki/Americas_CLA_Summit_2019 Thanks Kevin Shirey and Mark Balla for producing the videos and all those that volunteered to run the cameras. This is an awesome resource to be able to go re-watch and review these great presentations again or for those that couldn't join us in person to be able to view them as well.
  8. 6 points
    @Jim Kring, it seems to me that the export of the code has gotten a positive response from the community. However I may be wrong. If anyone has any opinion either way, please come forward. As you can see in this thread, it appears the community has rallied around this effort. This is why I emailed you to come here and share your thoughts. In the past, OpenG was a great venue to showcase how a bunch of passionate LabVIEW users can come together and collaborate on something useful. The passion is clearly still there, as shown by the numerous discussions here. The general coding community has moved to Git with GiHub being the hub. This seems like the logical next step. Who knows what this initiative will lead to. However, I’m expecting that placing OpenG in a neutral GitHub repo will provide the spark and the tools to facilitate open collaboration, then the community can drive the future. The community is full of smart people who have a desire for clean tested code. And if issues come up, LAVA discussions (or GitHub issues) are there to hash things out. When LAVA offered to host all OpenG discussions back in 2011. it was clear that the community wanted to help. When @jgcode put his standards together for how code should be discussed at that time, It was an exciting time. Since then, many people have come forward with offers to add new code into OpenG and fix bugs. For example @drjdpowell first offered to include his awesome SQLite toolkit for inclusion into OpenG. He got no response either way. It’s a shame to have a platform and forums to allow people to post and discuss OpenG code and then ignore it. If you have ideas on what the future of OpenG is. I’m hoping it’s to be more transparent and inclusive. Providing the tools, resources and some safety checks along the way, is the best way to facilitate passionate individuals to dive in. Do you think keeping the status quo of the past 10 years makes sense? It seems to me that the community disagrees. What do you think?
  9. 6 points
    You people are so laid back and forgiving. I’m an editor on multiple wikis across cyberspace, and none of the others are anything less than draconian. Capitalization whatever?! Wow. I’m going to need to wear my oversized Hawaiian shirt and cargo shorts when I’m editing, just to get in the right state of mind! πŸ™‚
  10. 5 points
    My experiment with NXG is now over. A simple web page has taken about 5x longer than I had planned for. Some of this is due to me underestimating the nuances of the web module but most of it has been me fighting the new IDE. The other night instead of happily diving into some after dinner software development fun I was actually filled with dread at the thought of having to open NXG and finish what I started, it really is that unpleasant to use. For me, NXG is nowhere near usable in a real project that I expect to have to develop, maintain and make money off. Some stuff seems to work, but everything has this toy feel about it. It is ugly, sluggish, unintuitive and absolutely repulsive to develop with. Sorry that sounds harsh, but it has been in development for over 8 years and has an incredibly strong pedigree to compare against. NI have taken almost everything that made current gen so special and thrown it in the bin. NXG is clearly being managed and developed by people who have never actually become intimately familiar with LabVIEW. I will check back in a few years time but at this point I am extremely disappointed and now need to think very strongly about where my professional systems development career is going. Current Gen is going to be sunsetted at some point and will fade into irrelevance due to its closed source nature (not that open sourcing something of its complexity would help now, it is too late for that). I could wait a few years if I had confidence that the ship was sailing in the right direction, but apart from AQ who consistently has the courage to actually even reply to these threads there is virtually nothing coming back from NI and I feel that the HMS NXG-itanic is sailing full steam ahead towards its doom. NI is run by extremely clever people who have no doubt done their sums and analyses and are charting the course for NXG that they think will bring them the most success in the long-run. I have a strong appreciation for just how big an undertaking something like NXG is, but given where it is after 8 years of development it just seems that I am not the target market and there is not too much I can do about it. Happily, given how robust NI hardware and current gen LabVIEW actually are I suspect there will be quite a bit of work supporting old systems for at least another decade (perhaps more).
  11. 5 points
    For a final Case. Sadly there isn't any non-depreciated Items to replace that vi. Which makes this work for Clusterzilla. ArrayToCluster.vim
  12. 5 points
    Hey LAVA friends. I'm going to be doing a live-stream on Youtube next Tuesday April 28, (10AM Pacific) to go over LabVIEW Community Edition. I'd love to see you guys there. It'll be interactive with chat for your questions, and I will be making an attempt to talk to a Raspberry Pi and Arduino. If you're curious about low-cost hardware or just want to find out what's new in the latest LabVIEW. Join me here: https://youtu.be/4HLVqYXpxIo. Edit: If any of you have done any projects with the supported hardware. Let me know and I can mention you or pull you into the discussion. - Thanks.
  13. 5 points
    The main difference between LabVIEW and a C compiled file is that the compiled code of each VI is contained in that VI and then the LabVIEW Runtime links together these code junks when it loads the VIs. In C the code junks are per C source file, put into object files, and all those object files are then linked together when building the final LIB, DLL or EXE. Such an executable image still has relocation tables that the loader will have to adjust when the code is loaded into a different memory address than what its prefered memory address was defined to be at link time. But that is a pretty simple step. The LabVIEW runtime linker has to do a bit more of work, that the linker part of the C compiler has mostly already done. For the rest the LabVIEW execution of code is much more like a C compiled executable than any Virtual Machine language like Java or .Net's IL bytecode, as the compiled code in the VIs is fully native machine code. Also the bytecode is by nature address independent defined while machine code while possible to use location independent addresses, usually has some absolute addresses in there. It's very easy to jump to conclusions from looking at a bit of assembly code in the LabVIEW runtime engine but that does not usually mean that those conclusions are correct. In this case the code junks in each VI are real compiled machine code directly targetted for the CPU. In the past this was done through a proprietary compiler engine that created in several stages the final machine code. It already included the seperation where the diagram was first translated into a directed graph that then was optimized in several steps and the final result was then put through a target specific compiler stage that created the actual machine code. This was however done in such a way that it wasn't to easy to switch the target specific compiler stage on the fly initially so that cross compiling wasn't very easy to add when they developed the Real-Time addition to LabVIEW. They eventually improved that with an unified API to the compiler stages so that they could be switched on the fly to allow cross compilation for the real-time targets which eventually appeared in LabVIEW 7. LabVIEW 2009 finally introduced the DFIR (Dataflow Intermediate Representation) by formalizing the directed graph representation further so that more optimizations could be performed on it and it could eventually be used for LabVIEW 2010 as an input to the LLVM (Low-Level Virtual Machine) compiler infrastructure. While this would theoreticaly allow to leave the code in an intermediate language form that only is evaluated on the actual target at runtime, this is not what NI choose to do in LabVIEW for several reason. The LLVM creates fully compiled machine code for the target which is then stored (in the VI for a build executable or if code seperation is not enabled, otherwise in the compile cache). When you load a VI hierarchy into memory all the code junks for each VI are loaded into memory and based on linker information created at compile time and also stored in the VI, the linker in the LabVIEW runtime makes several modifications to the code junk to make it executable at the location it is loaded and calling into the correct other code junks that each VI consists of. This is indeed a bit more than what the PE loader in Windows needs to do when loading an EXE or DLL, but it isn't really very much different. The only real difference is that the linking of the COFF object modules into one bigger image has already been done by the C compiler when compiling the executable image and that LabVIEW isn't really using COFF or OMF to store its executables as it does all the loading and linking of the compiled code itself and doesn't need to rely on an OS specific binary image loader.
  14. 5 points
    Found a fix for this. It should be fixed in LV 2020. The bug ONLY affects copying from a 1-element cluster of variant to a variant. Or a cluster of cluster of variant to a variant. Or... you get the idea... "any number of cluster-shells all containing 1 element, culminating in a variant" being copied to a variant. This was a fun bug... consider this: The memory layout for an byte-size integer is { 8 bits } The memory layout for a cluster of 1 byte-size integer is { 8 bits } They are identical. "Cluster" doesn't add any bits to the data. That's just the type descriptor for the data in that location. This is true for any 1-element cluster: the memory layout of the cluster is the same as the memory layout for the element by itself. This is true even if the 1 element is a complex type such as a nested cluster of many elements or an array. When a VI is compiling, if data needs to copy (say, when a wire forks), LabVIEW generates a copy procedure in assembly code. For trivial types such as integers, the copy is just a MOV instruction in assembly code. But for compound types, we may need to generate a whole block of code. At some point, the complexity is such that we would rather generate the copy procedure once and have the wire fork call that procedure. We want to generate as few of those as we have to -- keeps the code segment small, which minimizes page faults, among other advantages. We also generate copy procedures for compound coercions (like copying a cluster of 5 doubles into a cluster of 5 integers). Given all that, LabVIEW has some code that says, "I assume that type propagation has done its job and is only asking me to generate valid copy procs. So if I am asked to copy X to Y, I will remove all the 1-element shells from X and all the 1-element shells from Y, and then I will check to see if I have an existing copy proc." Nowhere in LabVIEW will we ever allow you to wire a 1-element cluster of an int32 directly to an int32. So the generator code never gets that case. In fact, the only time that we allow a 1-element cluster of X to coerce directly to X is... variant. The bug was that we were asking for a copy proc for this coercion, and the code was saying, "Oh, I have one of those already... just re-use copy-variant-to-variant." That will never crash, but it is also definitely not the right result! We had to add a check to handle variant special because variant can eat all the other types. So if the destination is variant, we have to be more precise about the copy proc re-use. I thought this was a neat corner case.
  15. 5 points
    At the 2019 Americas Certified LabVIEW Architect Summit, GCentral was introduced to the LabVIEW Community. GCentral is a non profit organization (incorporated September 2019) composed of G community leaders creating a platform for programmers to find/use, contribute, and co-develop G code packages and collaboration resources. While GCentral is leading the charge to solve these problems, we will closely align with the community's needs. This forum is designed to connect GCentral's efforts with the community's needs. Some links to be aware of: GCentral.org LabVIEW Wiki Twitter (@GCentralOrg) LinkedIn Instagram (gcentralorg) Facebook Website GitHub Repo
  16. 4 points
    LabVIEW Community Edition rocks! In order to help kick off this momentous occasion, I've put together an example alarm clock. It is broken down into 6 lessons (so far) taking you from blinking an led through creating an alarm clock with a state machine. To download or learn about LabVIEW Community Edition check out GCentral.org Check out the alarm clock here! <-(http://bit.ly/ChrisCilino_LabVIEWCommunityAndRP)
  17. 4 points
    So first I want to acknowledge some areas we could have done better. I have been involved in a number of discussions around what our migration strategy looks like, and the biggest gap we immediately identified is a lack of clear external messaging, so that is something we are looking to address. I have talked to all different kinds of users, and in a relatively short discussion we are able to align on whether or not NXG is ready for their use case. That is great, but you should be able to make that determination yourself by looking at public documentation, it should not require a call with me or a frustrating session of attempting to migrate an application. NI has tried to provide this in the past with the LabVIEW roadmap, but it doesn't have enough detail for you to make a high confidence decision. For example, it is not possible to differentiate between functionality that is not complete yet versus functionality which was intentionally omitted or intentionally changed. We have also not done a very good job of explaining the background of specific decisions - which leads to some of the feedback in this thread where it seems like we have changed everything for no reason. Certainly I can point to some changes which were mistakes, and generally speaking we have the flexibility to undo those changes, but many of the bigger changes were intentional, designed, tested changes which we believe are an improvement. We intend to do a better job of publicly documenting those decisions. It is hard to overstate the reorganization efforts that have happened within NI over the last couple of years. Last NIWeek Eric Starkloff talked about how we were organizing the company around business units instead of around products, and that has had broad reaching impact, but we were making major shifts in the way we built products in the last couple of years anyway. Like many of the large software companies we have been shifting to a user-centric development model where we actively try to bring the user into the development process instead of thinking we know what they need and developing in secret. A good example of this shift is the introduction of the product owner role in NI R&D, a role focused on ensuring we are delivering the right value to our users. Both the product owners and product planners have long histories of working with LabVIEW, so you should not feel like the decision makers working on LabVIEW NXG are completely detached from LabVIEW - in many cases the decision makers for the two products are the same. There have definitely been teething pains with this shift, but we are getting better at it. I saw several comments about feeling left out of the decision process, and there are certainly some valid concerns, but I would also point to the level of engagement over the last few years where the product owners and product planners have attended and solicited input at the CLA summits, GDevCon and NIWeek. We also have quite a few targeted user engagements when we are working on defining features and workflows. We can absolutely do more, and we plan to, but many significant product decisions have been made as a result of those engagements. Remember that there are a lot of LabVIEW users out there, and we can't talk to all of them. A light-hearted analogy would be to seeing the results of a national poll and saying - 'well nobody asked me!' That being said, I do want to increase my engagement with this community, and there is clearly a lot of passion about making LabVIEW NXG the best it can be. I would love to set up some 1x1 interviews with those of you who are interested so I can better understand how you are using LabVIEW today. I will start a different thread about that. Back to the main point - it is important to understand what LabVIEW NXG is today versus what it will become. LabVIEW NXG today is not ready for most of the applications of this community. You are some of the most advanced LabVIEW users around, and are collectively using nearly every feature in the product. As Stephen said early in this thread - NXG has many nice things, it just isn't ready for him (or most of you) yet. We are trying hard to get there and have made substantial progress, but there are still functionality gaps. We expect that you will continue to use LabVIEW for at least a few more years until NXG is more complete for your workflows. I saw a comment about not wanting to develop an application of thousands of files in NXG, and I agree that I don't consider NXG ready for that either. Similarly - converting a large project from LabVIEW to LabVIEW NXG is not something I would recommend yet either. The Conversion Utility and associated tooling is more effective for converting instrument drivers and libraries. To be honest I was surprised that no one in this thread pointed out that there is currently no way to probe classes, and no way to make custom probes. Yes we are already at version 5.0 and we still haven't built a full replacement for LabVIEW. That is a reflection of the incredible array of features in LabVIEW and the diversity of users and user cases that this community contains. However version 1.0 was not intended as a full replacement for LabVIEW and neither is version 5.0. For a subset of our user base who are building less complex applications NXG is ready for them and they are using it. For example a lot of work went into the workflow of helping a simple user take and process their first measurement, and we are building out from that foundation. When I talked about our reorganization and change in philosophy - that also translates into how we prioritize features and workflows. We are not just racing to recreate every last piece of LabVIEW in LabVIEW NXG. We are trying to understand the problems you were using those features to solve so we can determine if that same solution is the best choice for NXG. I plan on also addressing some of the specific points of feedback in this thread, but this post turned out much longer than I had intended! Hopefully that provides a bit of framing around the current state of LabVIEW NXG. Thanks, Jeff
  18. 4 points
  19. 4 points
    So I just discovered this, this morning and I think it will help out in making VIMs when dealing with supporting a scalar, or 1D array data type. I have an example which is my Filter 1D Array VIM, posted here, which is heavily inspired by OpenG's implementation. In it the developer can filter out a scalar, or a 1D array of something from a 1D array. I did this by adding a Type Specialized structure at the start which checks to see if after building the array, if the data type matched in the incoming array. If so it is a scalar and should be used. I then have another case where the data just goes straight through thinking it must already be a 1D array. But what I realized today is that is unnecessary. If in the VIM my input is set to a 1D array, and we add a build array with only 1 terminal, and that build array is set to Concatenate, then that whole structure isn't needed. A Scalar will become a 1D array with one element, and a 1D array will have no items added to it after the build array. In this example the code simplification isn't much, but someone may have had two cases in a type specialized structure which handle scalar and 1D array separately and using this they could be combined them into one. And one other minor thing, I don't think I will actually be updating the Filter 1D Array VIM to use this, just because knowing if the input is a scalar means other sorting work not shown can be ignored helping performance.
  20. 4 points
    I found this tonight while working on a project: https://remixicon.com/ Really good icon library with modern-looking icons where you can customize the color and size of the icons, then download them as PNG files. I then import them into a LabVIEW pict ring and it's off to the races.
  21. 4 points
    It is not a bug. It should break for any unsigned integers because that's how the "negate" method works.
  22. 4 points
    I'm working on a personal project (more information will be shared about this later) that needs Message Queue Telemetry Transport (MQTT). While searching for LabVIEW libraries for MQTT I found 1 on VIPM, 2 in the NI Forums, and 1 through Goggle on GitHub, as follows: WireQueue-MQTT Driver for LabVIEW by WireFlow AB (this one costs $550) MQTT Client API in native LabVIEW by Peter - daq.io (also on GitHub as LVMQTT) MQTT-LabVIEW by Michal Radziwon Quaxo MQTT LabVIEW by Stefan May This is not unusual for just about anything you might be looking for. In fact searching on GitHub there are 13 results for LabVIEW+MQTT. What was weird is that two of them were almost completely the same, yet neither attribute the other. I don't know which came first. I ended up forking from one of them but I guess I'll attribute both to be safe if I end up using it. However, talking about code confidence, I just found this one: LV-MQTT-Broker by @Francois Normandin. I know Francois, he is a LabVIEW Champion. He has included unit tests. It has full documentation as well as an NIWeek presentation by him and Sarah Zalusky, both of whom are Certified LabVIEW Architects (CLAs). From GitHub I can see he has been actively contributing to it and its open source (which most of them were). Honestly, I wish I had found this one first. Just some words for thought...
  23. 4 points
    Here you go. Set Icon.vi Use it like this: To get back to the original icon just call it with an empty path.
  24. 4 points
  25. 4 points
    I assume you meant this video? There is this older video of Dr. T and Jeff K. introducing a LabVIEW Basics Interactive CD-ROM (~LabVIEW 4), but it's not as exciting as the LabVIEW 5 promo.
  26. 4 points
    Add SuperSecretListboxStuff=True to your labview.ini , reload LabVIEW new menu items will show up when you right click on MLC control. Read this thread
  27. 4 points
    As someone contributing code on LAVA, I would like to see the certified LAVA repository packages made available through the GCentral package search tool.
  28. 4 points
    As a company that uses LabVIEW and has it's own existing internal repository for reuse code, I would like a way for my developers to discover packages in G Central and in our private reuse repository, all from a single portal.
  29. 4 points
    Version 1.2.0.6 released. https://github.com/LabVIEW-Open-Source/DataManipulation/releases/tag/1.2.0.6 Added support to return a list of Event reference types (class of event) for Event Registration Refnums Controls, Panes, Splitters, VI References and Application References. Array is empty for all other datatypes. ** Please note that this does not drill into clusters of Event Registration Refnums. This is only one-level deep. I have not tried, but I assume that getting the cluster elements and then looping on those should work...
  30. 3 points
    Hi everyone, Apologies for the slow response - this thread kicked off a number of internal discussions within NI and I was waiting for some of those discussions to shake out before setting up these engagements. First of all - I have set up a calendly link for scheduling time slots for 1x1 discussions. This is my first time trying calendly, so I have set up 30 minute time slots for three days later this week. Let me know if you have any suggestions or tweaks to make this more effective. Thank you in advance to those of you willing to take the time to talk to me, I appreciate it! In the link I specified two different types of discussions, please specify which kind of discussion you would like to have and I will send you a Microsoft Teams link. The first type is a user interview where we discuss how you use LabVIEW today. This is not focused on NXG, it is a way for me to better understand your workflows and pain points that you encounter today. This helps me better inform design decisions we make in NXG. The second type is a feedback discussion focused on NXG - this is more open format where I will do my best to answer your questions and discuss any feedback you have on NXG. Second - I want to address some of the points in this thread about prior engagements with NI. For the last few years we have been very focused on closing the functionality gaps between LabVIEW and LabVIEW NXG - this means we have not done as much iteration on usability and existing functionality as we would have liked. Big gaps like dynamically loading a VI, sub panels, and hardware support were prioritized higher. As we are getting closer and the gaps are getting smaller, we are re-evaluating some of these longstanding complaints and looking to address them. For example Neil mentioned he had a lengthy discussion a few years ago and didn't see any product changes as a result. I discussed this with the product owner that conducted that discussion, and it (along with several other user interviews that expressed similar concerns) led to several significant design changes - including a major redesign of how we handle tearing tabs out of the editor. In that specific case the redesign represented a significant development effort and was deemed lower priority than closing some of the gaps we mentioned earlier, but as we get through some of those higher priority items I would expect us to look at it again. There were several other areas of feedback which did lead to product changes - such as more color on diagram constants and changes to how the palettes work. We know we need to do better at closing the loop so you can see the impact that these discussions have, and we are working on finding the right venue for having those discussions with the broadest possible audience. Regarding dr powells question about areas which I consider significant improvemented in NXG - there are a few which immediately come to mind 1. The workflow of detecting hardware and getting a first measurement has been significantly improved. We have heard consistent feedback from new users that the getting started experience in LabVIEW is difficult - so called 'blank VI syndrome'. We tried a few different ways of addressing this in LabVIEW, but in NXG automatic detection of hardware is improved and reflected directly in the project and measurement panels let users configure their measurement and basic signal processing before being translated to G code. That is not a workflow that impacts many of the more advanced users on this forum, but it makes LabVIEW more approachable to new users which is important to grow the user base. 2. In my opinion the changes we have made to the project are a huge improvement. Requiring a project, using the project and components to manage the dependencies between files, and mirroring the project file structure on disk (which I realize not everyone is in favor of) has eliminated cross linking. Personally I find it speeds up my development for the editor to be picking the disk location of the files I am creating - especially when I am working with classes and creating a lot of files. 3. Components in general are a big improvement over the options in LabVIEW. They simplify dependency management and encourage modular code architecture. They solve many of the limitations of PPLs. Each component translates to an exe or gll when built, which simplifies build specifications. We have also enforced a strict rule of editor run behavior being the same as built application behavior, which should improve difficult to track down bugs where it works fine in the editor but breaks in a built application. 4. Moving to an xml file format will enable us to eventually have a significantly improved integration with git and other third party tools. We are not there today, but that is where we intend to get to. 5. This is less user-visible, but the underlying architecture of NXG is more flexible than LabVIEW and has been designed for extensions and plugins from the beginning. This is easiest with C#, but it means that community members who know C# are able to extend NXG in a myriad of ways that are not possible with LabVIEW. As I said in my previous post - LabVIEW NXG is still a work in-progress. It is not ready for complex projects yet, but we are getting closer and moving quickly. Similar to what Stephen said - I believe the vector is good, and community engagement helps us refine our direction. Please grab a slot for a 1x1 discussion if you want to discuss this further or are willing to talk with me about your current workflows. Thanks!
  31. 3 points
    A perfect moment to dig out a thread , just a few days before its 10th birthday. I made dis: https://labviewwiki.org/wiki/Heap_Peek And happy birthday, thread!
  32. 3 points
    I threw this together, and maybe someone will find it useful. I needed to be able to interact with cmd.exe a bit more than the native system exec.vi primitive offers. I used .NET to get the job done. Some notable capabilities: - User can see standard output and standard error in real-time - User can write a command to standard input - User can query if the process has completed - User can abort the process by sending a ctrl-C command Aborting the process was the trickiest part. I found a solution at the following article: http://stanislavs.org/stopping-command-line-applications-programatically-with-ctrl-c-events-from-net/#comment-2880 The ping demo illustrates this capability. In order to abort ping.exe from the command-line, the user needs to send a ctrl-c command. We achieve this by invoking KERNEL32 to attach a console to the process ID and then sending a ctrl-C command to the process. This is a clean solution that safely aborts ping.exe. The best part about this solution is that it doesn't require for any console prompts to be visible. An alternate solution was to start the cmd.exe process with a visible window, and then to issue a MainWindowClose command, but this required for a window to be visible. I put this code together to allow for me to better interact with HandbrakeCLI and FFMPEG. Enjoi NET_Proc.zip
  33. 3 points
    First of all, hi everyone and thank you all for the feedback. I really do appreciate it, and I want you to know that I generally read these threads even if I don't always participate. Stephen also periodically sends threads to me and the other relevant product owners. I am the product owner responsible for G language in LabVIEW NXG. There are other product owners responsible for other aspects of LabVIEW NXG and the related technologies. Our role in LabVIEW R&D is to advocate for the user within the development team. We am ultimately responsible for making sure the functionality we add to the product is valuable to our users. That being said - I don't want to oversell my role. As the product owner (which we have started calling productization lead because I don't actually own the product) I don't set the priority of which functionality we invest in first - that is decided by our planning organization, but I work closely with them and have a lot of input into that process. It is the responsibility of planning to identify high level workflows and investment areas, and it is the shared responsibility of the product owner and development team to design and build solutions that satisfy those requirements. There is a lot of good feedback here, much of which I was already aware of, and much of which predates my role existing. I want to take the time to properly address the different points in this thread - so expect some follow up posts from me next week, but first I just wanted to introduce myself. Jeff Peacock
  34. 3 points
    For comment, here is a beta version of the next SQLite Library release (1.11). It has a significant new feature of a "Parameter(s)" input to the "Execute SQL" functions. This can be a single parameter or a cluster of multiple parameters. Uses Variant functions and will be not as performance as a more explicit preparing and binding of a Statement object, but should be easier to code. drjdpowell_lib_sqlite_labview-1.11.0.86.vip
  35. 3 points
    NXG actually seems quite good at figuring out what I am looking for with quick drop; I just type the name of the primitive and it appears. This is good as I cannot identify anything because the new icons all look totally weird to me...
  36. 3 points
    Thanks. It was mostly to satisfy myself I wasn't missing some game changing feature or workflow in NXG that was hidden behind its slow and drab exterior. Like you, I haven't seen any examples of large projects running under NXG so wanted to document at least a small project. There was one NXG product owner who saw it and took the time to respond, and noted the event structure feedback was useful. I think it had some support for clusters of clusters (see Neil's example), but definitely not for classes and references. Here's a few more issues that I ran into: There's no auto-save VI recovery feature. Save often. Seriously. Accidentally mousing over the wrong thing can crash NXG. If I've gone to the trouble of finding and downloading offline help files, NXG should be able to locally search them (really, they should be included). The wire direction when wiring is wrong after the first anchor point. LabVIEW 20xx selects either vertical or horizontal based on the initial mouse move direction after starting a wire, and for each click when anchoring a wire. NXG respects the initial direction, but anchor clicks do not. I'm constantly tapping the spacebar to change wire direction. This really slows wiring down. Holding the spacebar and click+dragging allows scrolling around the block diagram (panning). If I've just clicked a structure (selected an event), pressing spacebar does nothing. I have to give 'focus' back to the diagram by clicking it first. The different library, tag, SLI (and probably other) views have no consistency in their look and function. Granted they each do different things, but it doesn't feel coherent. No case structure auto complete for enums. Can't type first few letters of enum in case and have it auto complete. Frustrating for very long enum values. There's no way to set the Z-order of front panel controls (I think there used to be in previous NXG versions?) I have to move controls to unplaced items and place them again to get the correct order. No icon view for cluster constants. More often than not, converted VIs don't have the structures, nodes, wires, etc placed on the block diagram's 5px (?) grid. This means any wiring changes can never be aligned properly without moving entire structures, tunnels, nodes, etc. Single wire segment can't be moved in large steps with shift + arrow keys. This is incredibly annoying. Let me disable animations. Palette flyouts/drop downs, pane show/hide, anything. Visual accessibility doesn't seem to be high on the list of NXG design goals, but at least let animations be disabled for performance reasons.
  37. 3 points
    You mean like this? That is possible. Obviously for the sake of change a colon is now used to separate the elements, because hey they were changing everything else, right?.
  38. 3 points
    I thought I'd reply to this thread for posterity. LabVIEW Community Edition is now fully released starting today. Just to summarize: LabVIEW 2020 and NXG 5.0 are part of the release. Includes everything that comes with LabVIEW and NXG Professional Edition, Including App Builder (exe builds). No watermarks or feature restrictions LabVIEW NXG Community Edition includes the LabVIEW NXG Web Module Extending SystemLink Cloud evaluation to 6 months during 2020 LINX toolkit included with install. Supports: Arduino via serial port. Digilent uChip board RasPi and Beaglebone Black as LabVIEW targets via Ethernet Port. You can build/deploy a LVRT application on the above targets (RasPi and Beaglebone Black) and run headless. Exact same process as traditional NI embedded targets etc like cRIO. You can use the LINX toolkit separately if you need it for commercial usage. Just install it on a non-community system. The license for LINX allows this now. License allows usage for anything and everything except: NO Commercial use. If you want to do commercial work, buy a full license for your business or use your company's license. NO College University courses/labs (post-secondary). Academic Site Licenses apply in these cases. Note: Students and teachers in K-12 classrooms can also use LabVIEW Community and LabVIEW NXG Community. License is activated through your ni.com account and lasts for 1-year (renewable each year). Clear definitions are detailed in this link. *Arduino is only serial support (not a target)
  39. 3 points
    @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.
  40. 3 points
    [Update: NI Bug 974336] There seems to be a bug in the coercion of data to variant when a cluster contains a single element that is a variant. (original post here). Note: This bug appears to be very old, going as far back as LV2012. This has been reported to NI in the LV2020 Beta forum. I don't have a Bug ID / CAR yet. Coerce to Variant Fail (LV2019).vi Note that adding another element to the outer cluster causes the problem to go away.
  41. 3 points
    @The Q My library is not complete by any means, but what works really works... I've followed a TDD approach. So far I've covered only 79 requirements out of 141, and I haven't started any branches to support MQTT 5.0 yet... So it covers the basic needs such as shown in the presentation you're referring to, but nothing fancy like QoS 1 and 2 and the likes. (or TLS for that matter). If you want something more complete, I'd check Wireflow's implementation first. Now, I'd really like to get other folks to contribute to my Open Source Project. It would give me a moral boost to continue pushing it further. In the meantime, thanks for the advertisement!!!
  42. 3 points
  43. 3 points
    Due to bitbucket discontinuing support for Mercurial in 2020, I have migrated the source code to Github. From now on, if there is any development on this project, it will be in the LabVIEW Open Source project: https://github.com/LabVIEW-Open-Source/ui-tools You can use both LAVAG or Github's issue tracking to report any issue you might encounter with this package. (previous repo: https://bitbucket.org/normandinf/ui-tools/)
  44. 3 points
    I already have that superpower I once used lots of letters so that if you read the for loops top to bottom the letters spelt out my name and a message. I also once heard that wether you use "a" or "i" depends on if you came from a mathematical or engineering background. What's really stange (for me) is in C and PHP; I use "i". But in Pascal, and Python ; I use "a". I know that to a certain extent it is muscle memory since if I use "i" in Pascal, I nearly always leave out the colon before the equal sign. Maybe it's a coping mechanism because I switch between languages so much.
  45. 3 points
    As a developer working on multiple machines, I'd like to be able to save a (personal) configuration file of "IDE-improvement" style packages to install on every machine.
  46. 3 points
    It is good to finally see some movement in OpenG. Git and GitHub are also the right choices (Bitbucket would probably also work). Even novice programmers will be able to participate this way. πŸ‘ That said, the current repository has a few problems: No tags No branches All projects in one repository Changed commit messages (the links in the commit messages are non-functional) It is possible to transform an SVN repository into a Git repository while maintaining all tags and branches and updating the committers (because Git uses email addresses and SVN doesn't). Here are some instructions I used in the past for such jobs (instructions are for Linux of course): https://epicserve-docs.readthedocs.io/en/latest/git/svn_to_git.html For OpenG this process is a bit more complex because of the way the repository is structured (i.e. tags inside folders for each project), so the scripts must be adjusted to take this into account. I also suggest splitting the project into multiple repositories during this process to improve maintainability (unless there is a reason why it needs to be one repository). I could prepare the scripts to automate this process if you are interested.
  47. 3 points
    As a package consumer I would like to be able to subscribe to packages so that I get notified when a new version is available.
  48. 3 points
    We use a variety of frameworks/templates/patterns for our architecture: The Actor Framework is used for asynchronous UI operations and long-running data processing tasks. Queued Message Handlers (not using DQMH or QMH template) handle simple asynchronous tasks. Action Engines encapsulate privately shared data for our translation and general I/O libraries. (Queued) State Machines ensure that everything runs in order. The proxy pattern is used to interface most customer libraries. We have our own frameworks for the test execution engine and test libraries (message based). I find the publicly available frameworks and templates (DQMH, Messanger Library, NI templates, etc...) very valuable for learning and to get things started quickly. More advanced projects, however, require a deeper understanding of the underlying patterns in order to develop your own architecture (which may or may not utilize these frameworks/templates). In your case these are synonymous πŸ˜‹ "Any sufficiently advanced technology is indistinguishable from magic." (Arthur C. Clarke) For some reason that just popped into my mind... If your entire architecture and thought process is fundamentally based on actors, any small project will of course have to depend on it as well. That is, unless you are willing to rethink (and probably reimplement) the fundamental architecture. Then again, why reinvent the wheel?
  49. 3 points
    Hey folks. this year we're trying something new. All Videos for NIWeek 2019 can be found here: https://labviewwiki.org/wiki/NIWeek_2019 Feedback welcome. Thanks to @Mark Balla and other volunteers for recording the videos. Edit: We're starting to add the back catalog to YouTube. NIWeek 2018 videos are also up.
  50. 3 points
    You can extract the labels from the type descriptor, once you know where to find them in the array. I added support for it in this open source DataManipulation library. Check out the OpenDescriptor palette. You can install the latest release (1.1.0.5) from here: https://github.com/LabVIEW-Open-Source/DataManipulation/releases/tag/1.1.0.5 (download VIP file and install with VIPM). Once installed, you'll find the "List Element Names" method under Addons>DataManipulation>OpenDescriptor palette. (It can list enums and cluster elements as well, although those are natively supported under the Variant Utilities palette.)


×
×
  • Create New...

Important Information

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