Jump to content


Popular Content

Showing content with the highest reputation since 05/07/2020 in Posts

  1. 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
  2. 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!
  3. 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!
  4. 3 points
    There are multiple considerations: Public IP address: Your mobile carrier (or Internet service provider) assigns you a public IP address. STATIC public IP address: Be aware that this is an increasingly rare commodity. I don't know which country you live in, but I'd be very surprised if your consumer mobile carrier provides static public IP addresses anymore. You might find a commercial/enterprise provider that still sells static IP addresses, or you can use a Dynamic DNS (DDNS) service like https://www.noip.com/ -- DDNS allows you to connect to an address like neilpate.ddns.net which stays static even if your IP address is dynamic. Unique public IP address PER DEVICE: Unfortunately, if you have 1 SIM card, you will get 1 public IP address to be shared between your Windows PC and all of your cRIOs. This is the same as your home Internet: All the PCs, laptops, tablets, phones, and other smart devices that connect to your home Wi-Fi all share a single public IP address. This is Network Address Translation (NAT) in action. If you really want multiple unique public addresses, you'll need multiple SIM cards. Unique public IP address per SIM card???: Nowadays, you also need to double-check if your carrier even provides you with a unique public IP address at all! Carriers around the world have started implementing Carrier-Grade NAT (CG-NAT) for both mobile and home Internet users. This means your SIM card might share a public IP address with many other SIM cards. If this is the case, then DDNS won't work! Suppose you have 1 public IP address, and each of your devices host a web service at port 443. You can assign a unique port per device on your modem and do port forwarding as you mentioned: Dev PC --> neilpate.ddns.net:54430 (modem) --> (Windows PC) Dev PC --> neilpate.ddns.net:54431 (modem) --> (cRIO 1) Dev PC --> neilpate.ddns.net:54432 (modem) --> (cRIO 2) This means the client program on the Dev PC needs to know to use a non-standard port. You can do this easily in a web browser or a terminal emulator, but I'm not sure that LabVIEW can use a custom port to connect/deploy a cRIO. Alternative solutions You don't necessarily need a public IP address for remote access. Some modems can be configured to automatically connect to a Virtual Private Network (VPN). If you enable VPN access to your office and you ask your modem to connect to that VPN, your devices will be on the same (local) subnet as the Dev PC in your office -- we have done this for a cRIO that's deployed into the middle of a desert. If your modem doesn't support this, you could configure each device to individually connect to the VPN instead. Or, your provider might offer enterprise-level solutions that connect multiple sites to the same VPN. For example, they could offer SIM cards that provide a direct connection to your corporate VPN without the need to configure your modem or devices. Yes, these are commonly solved. The issue is that there are so many possible solutions, so you need to figure out which one works best for your use-case.
  5. 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
  6. 3 points
    The IDE was in fact pretty much here when NI launched LabVIEW Web UI: https://www.youtube.com/watch?v=RiY35znIdUg which used Microsoft Silverlight. Since that must have been in the making for several years before it was released, this is more like 10+ years old. Does the IDE look 10 years old or older? The fact that pretty much every traditional LV developer feels horrible pain at the mere look of the IDE is saying either we are all hopelessly outdated or indeed the IDE is a step backwards in terms of nimbleness (agility?). The IDE should be modular, since the underlying code itself is not. In fact, it should be open, offering the ability to third party developers to hook their tools and customization. I am not particularly depressed anymore at the unfolding of this slow motion catastrophe, and in fact I am even willing to believe NI that indeed there is a new crop of developers who are going to prove us all wrong. But right now, this is not the direction we (academia) are going. We want openness (for reproducibility purposes), we want flexibility, customizability, and we are certainly not going to have our users pay runtime licenses for toolkits simply implementing public domain algorithms. I am still much more efficient at programming in LV, but there is zero incentive for me to choose NXG over Python at this point, based on my 25 years of dealing with NI.
  7. 3 points
    As a user collaborating on an idea for un-created code, I want to be able to see what other users are thinking about as well. For example, let's say, in the back of my mind, I have this idea for an open source barbecue thermometer that runs on a Raspberry Pi using LabVIEW. That said, I have several open source project ideas, all of which I find equally interesting, so I randomly pick one of them to start working on. But, maybe there's another community member that wants such a BBQ thermometer as well. If I knew that, I might choose to prioritize the project that someone else is interested in vs. another project that nobody (but me) cares about. Similarly, let's say I have the idea, but don't have the bandwidth to really pull it off in any reasonable timeframe. Someone else sees the idea, however, and wants to help. Knowing that I'm not alone, I might choose to begin work on the idea. Finally, let's say that I have this really cool idea, but I'm a software guy and it would probably require a custom Pi HAT. That's way outside my comfort zone, but maybe someone else is willing to help with that, and make the project a reality. This could even allow for voting, similar to the kudos system on the NI Idea Exchange. Of course, there's no obligation to do anything if your idea gets a bunch of kudos, but it could be incentive and/or drive innovation by others.
  8. 2 points
    Hi! Great article, indeed. I'd like to add some little notes, that I've known of. - I saw Heap Peek in LabVIEW 2.5 already. I could propose, that it was always in LabVIEW, in any version maybe, but I can't check it right now, because I don't have LabVIEW 1.0 or 2.0 distros. - There exists another way to get Heap Peek window visible. You could use some utility to deal with applications windows, like WinSpy++ or Window Detective or any similar tool. Heap Peek is hidden window by default, but it may be displayed easily. - Those hex numbers in the upper right section of Heap Peek are the objects' addresses in LabVIEW memory, so they could be used to explore (or even modify) a single object's properties or any related data in your favourite debugger (of course, if you know, what you're looking for). - I believe, DCO stands for Data Controller Object and there's DDO also, that should be Data Display Object. I didn't study DDOs much (it's either a control or an indicator), but a DCO controls how and which data is passed through a single terminal (on BD) or control/indicator (on FP). You may find any SubVI's/node's terminal w/ Heap Peek and in its properties you should find an address of DCO assigned to it. The same is doable with controls and indicators on Front Panel. On BD DCOs are called Parameters or EFN Parameters (for CLFNs) or somehow else. On FP they're called FrontPanelDataControllers. It's easy to find them using "F" button of Heap Peek. Going to the original topic, there's "Window monitor" debugging tool also, which could be viewed with CTRL+SHIFT+D+W. It's able to display LV windows handles (HWNDs), positions, names and some other info's. Oddly nobody ever mentioned it on the forums, maybe because its use cases are very limited. It's not so convenient to use also, because its interface is very ascetic. WinSpy++ or the analogs do the similar work a way better.
  9. 2 points
    Lack of NIWeek content has prompted @Steve Watts, to start VIWeek. See his post here: https://forums.ni.com/t5/Random-Ramblings-on-LabVIEW/VIWeek-Making-Trouble-Again/ba-p/4044162 LabVIEWWiki Page.
  10. 2 points
    You may possible rather use this version 4.2.0-b1 here.
  11. 2 points
    There will be Ph D thesis written on the Boeing MAX debacle. I am starting to wonder whether there will be, regarding the NXG one, if no insider information ever leaks out. In the meantime, some food for thoughts: https://medium.com/@herbcaudill/lessons-from-6-software-rewrite-stories-635e4c8f7c22
  12. 2 points
    A pack of hungry wolves could not hold me back. I am just waiting for the thread Jeff said he was going to make.
  13. 2 points
    Dug up from the info-labview mailing list... on April 1, 2011 (can't make this up): Keep in mind that at the time of its disappearance (at least from public eyes), LabVIEW Web UI was in par with ~ LabVIEW 3.1 (no undo, no event structure, etc. for instance). It would be very instructive, from an historical perspective, to have an insider's view of NI's development plans at the time (2011 and before) and how this unfolded up to now, with this bizarre "perpetual alpha" release strategy of a development product supposed to replace a flagship product, which itself is not officially discontinued, but in practice will have little bug fixes or added features. In fact, from a sociological perspective, it would be interesting to have an idea of who is leading this effort, as I have a hard time admitting that NI can find enthusiastic young developers working on somethings that is so painfully uncool. Somewhat premonitorily, the same newsletter contained these two links (found on the Wayback machine): https://web.archive.org/web/20100406005233/http://www.ni.com/news/releases/april0701.htm https://web.archive.org/web/20110402173747/http://www.ni.com/news/releases/april1101.htm You can 't help but wonder what will pop up when the next time capsule will be opened in 2036...
  14. 1 point
    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 ๐Ÿ™‚
  15. 1 point
    They were added in 2019, actually. Can't live without them now ๐Ÿ˜Š Indeed, these features are very useful for corner cases. For the general case, however, I would argue that the cost (slower performance, higher complexity) probably outweighs the benefits (haven't tested it). Still, the Hidden Gems version allows you to specify a pattern, which makes it extremely flexible (not sure about the OpenG version).
  16. 1 point
    I would do it in two steps 1. Discard protocol data (~00D and 037) - This is typically done when reading the data string anyway. 2. Split the payload using Delimited String to 1D String Array.vi.
  17. 1 point
  18. 1 point
    There are 2 separate sets of limits: Scale.Maximum/Scale.Minimum and Data Entry Limits.Maximum/Data Entry Limits.Minimum. The digital display simply shows the value stored in the Slide -- in other words, it shows what you'd see from the Slide's terminal, local variable, or Value property node. The underlying issue is that the Slide's value remains unchanged when you update the Scale limits. The Scale limits set the visible range on the GUI but they don't set the range of allowable values. To get the behaviour you want, you don't need to use a property node on the digital display but you must: Set "Respond to value outside limits" to "Coerce" instead of "Ignore" Programmatically update the Data Entry Limits
  19. 1 point
    Thanks Jeff, I have sent the calendly link (but I could not find the bit where we pick the Option 1 or Option 2, sorry! I would like to chat about how I use LabVIEW today).
  20. 1 point
    I do remember discovering the Window Monitor and Ned windows semi-independently. Someone posted a way to show the Heap Peak window, with CTRL+Shift+D+H and I thought that was likely for Debug, and Heap. So why not try D+<every letter combination>. At the time I think only H, N, and W did anything. Most of the time I care to find a window's HWND I use a private function which lets me do what I want. I have never had a need for knowing the HWND of any of the other windows so that Window Monitor wasn't all that useful for me. The Ned windows unlocked more useful information, but just for curiosity sake really. Also I find it really interesting that Heap Peak has been in LabVIEW for such a long time and with seemly no or little updates to it.
  21. 1 point
    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)
  22. 1 point
    Broadcast Actor.zip Hello All! I'm looking for a little bit of feedback on an Actor I've put together. The zip file attached contains an Actor called "Broadcast Actor". I know the idea of a "broadcast" partially goes against the AF rules but bare with me. The reason I put this together is because the idea of an abstract message was driving me a little crazy. I probably haven't had it properly explained to me but in any case I decided to try and build something that accomplished a similar task as an Abstract Message while also maintaining the low/zero coupling abstract messages provide. I do know Interfaces are out and about in LabVIEW 2020 but this approach is for older code bases that we can't quite upgrade yet. I loosely based this approach on DQMH which has an interesting architecture for messages going "up the tree" using broadcasts (user events), that parent modules register for when they start up. I figured something like this could also be implemented in an Actor. The attached broadcast actor has a message that returns its own populated "Event Cluster". Calling actors can call this message and are returned this "Event Cluster". The parent actor can then register for all of the events of the child actor in their Actor Core. I know reply messages are kind of discouraged in AF but this also felt like an okay way to use them. Once the child actor is up and running it can call it's own broadcasts which the parent can hear and do something intelligent with. My understanding of "low coupling" is limited, but I *think* this approach would prevent the parent actor from being loaded into memory if we are just trying to load the child actor. Maybe I'm way off or maybe this has been done before but it felt like a way to not have to use abstract messages (a barrier for some people to adopt AF), but also allow for low coupling between the actors themselves. Any and all feedback is welcome. What am I missing? -John Hoehner
  23. 1 point
    The two people who gave this presentation might be able to point you in the right direction.
  24. 1 point
    It's a start. Humor and the recognition that the world is moving on outside the ivory tower...
  25. 1 point
    All the videos for VIWeek are live: https://labviewwiki.org/wiki/VIWeek
  26. 1 point
    I successfully used oglib_lvzip-4.1.0-b3 from this post, enhanced for 64-bit LV by Rolf. It always worked good for me.
  27. 1 point
    So just adding info here for future googlers. There is an NI KB article on how to cleanup the cache here: https://knowledge.ni.com/KnowledgeArticleDetails?id=kA00Z0000019KdtSAE&l=en-US In there it also mentions an ini token that eliminates cache creation completely:
  28. 1 point
    JeffP, in the interest of not letting this conversation die, can you present some positive features of NXG that improve over LabVIEW?
  29. 1 point
    Here are some "secret" INI keys related to CLFNs: extFuncGenNoWrapperEnabled=True - the most interesting one here; adds "Generate Wrapper" option to CLFN context menu (on by default). When this option is unchecked (off), LabVIEW doesn't generate the wrapper for DLL call, i.e. ExtFuncWrapper function is not called and the user's function is inlined into the VI code and called. This feature could slightly improve performance of external code communications, saving approx. 5 to 10 ms on each call. But you must be absolutely sure, that your CLFN is set correctly as no error checking is done in this case and any small mistake in the parameters leads to LV crash. There might be an indirect use of this feature, e.g. manual fine-tuning/debugging of some problematic function or a function with unclear parameters etc. When the option is enabled and extFuncShowMagic is set, CLFN is painted red. extFuncBreakOnGenNoWrapper=True - if enabled, disallows to run VI with CLFN's "Generate Wrapper" option unchecked. The Run arrow is broken and the error is stated as "Call Library Nodes with 'gen no wrapper' are not supported.". The error is detailed as "This Call Library Node is set to 'gen no wrapper'. This setting skips certain steps when calling DLLs in order to be faster, and can be dangerous.". extFuncShowMagic=True - adds some coloring to CLFNs, when "Generate Wrapper" and "Type Only Argument" options are used. extFuncExtendedOptionsEnabled=True - adds "Allow Sub-Arrays" option to CLFN context menu (off by default). I assume, it should have worked this way, but I have not found any signs that this feature is working at all. If I set "Constant" option, then a sub-array is passed into a function, else the whole array is copied and passed, no matter if "Allow Sub-Arrays" is set or not. Maybe I missed smth or it's a relic option from pre-LV2009 era... extFuncArgTypeOnlyEnabled=True - adds "Type Only Argument" option to CLFN context menu, when clicking on a node's terminal (off by default). When this option is checked, LabVIEW passes 0 (aka NULL) instead of a real value of the parameter, no matter if passed by value or by reference. When the option is enabled and extFuncShowMagic is set, the terminal is painted bluegreen (cyan). Any thoughts, what was it used for? Here's its scripting counterpart. allowPreallocsInDll=True - adds "Allow Preallocated Data" option to CLFN context menu, when clicking on a node's terminal (off by default). Did not study this one well, but it seems to not do anything or I'm wrong? Here's its scripting counterpart. callLibNodeMayHaveLVClassParams=True - if enabled, allows to run VI with LV class wires passed into CLFNs. By default the Run arrow is broken, when class wire is connected to CLFN. Interesting, but what can we do with it in the external code? AllowCLFNTakeSlice=True - unexplored too atm. This is the pic with some options activated: DbgPrintf.vi I also noticed that there are some private flag bits for CLFNs, e.g. extFuncVarArgs, extFuncParamsFromTL, extFuncNIValidated, extFuncTopLevelOnlyInUI. I believe, some bits should be available with scripting also. Var args feature looks interesting, but it's likely an abandoned thing, isn't it? AFAIK CLFNs never supported that in any manner. Finally some sort of off-topic, but somewhat related. Did you know that it's possible to create an input constant for CLFN's return terminal? Just set Return output as non-void and do a RMB click on the left terminal. The Run arrow is not broken and the VI runs fine. Ancient bug or intended for something? I've never seen that value being passed into external code in any ways.
  30. 1 point
    Here's the relevant NI Forums thread on this topic: https://forums.ni.com/t5/LabVIEW/New-LabVIEW-2019-Feature-Create-Constant-Create-Control-and/td-p/3933878 Come at me, bro.
  31. 1 point
    There is a different API for Installer Builder. It is also not officially supported by NI, but there are a couple of examples that ship with the API to help you learn how to use it: [LabVIEW 20xx]\vi.lib\InstallerBuilder\examples
  32. 1 point
  33. 1 point
    I have a XY graph to display the trend of temperature over time. I am making the plot legend scrollbar visible based on number of plots I have. If I enabled it using the property node, I am not able to click on the scroll bar and move it. But I am able to use the mouse wheel to scroll. Please help me why this is happening. As a workaround, I made the legend scroll bar visible from the right click option on the graph and saved it. And I am not changing the visibility through property node and this works fine. Temp plot testing.vi
  34. 1 point
    If you can't get a dedicated IP address, one thing you can do is have your software query the outside world and find out what its public IP address is, and then update some location that you can get access to. This is essentially dynamic DNS. I have a domain I registered and have a website that I host. I have the computer that serves the web page update its own DNS every couple of hours because my IP address may change. Another option might be to do something like write a text file to Dropbox. Then when you want to connect to it read the dropbox file and that will tell you the public IP. Then the ports as JKSH mentioned will reference each device.
  35. 1 point
    Yes, I was very committed to HP48, wrote many programs and games back in the day, which can still be found. I still use it daily, but as emulator on my Android. here is how: green shift -> units (#6) hit next couple times to get to Angles menu (top row of buttons) choose your deg Angle enter number hit degree menu at top you can hit enter to make a duplicate to convert a unit to another purple shift -> desired unit. this takes the top stack and converts (replaces the stack) hence I like to make duplicate.
  36. 1 point
    There's an Idea Exchange entry about this for LabVIEW CG, but it really should extend to NXG too: https://forums.ni.com/t5/NI-Package-Management-Idea/Install-the-same-package-to-multiple-versions-of-LabVIEW/idi-p/3965419
  37. 1 point
    In the article it says: "The ability to create modes and overloads isnโ€™t publicly available in the newest version of LabVIEW NXG; however, weโ€™re looking to extend these features to our user base soon."
  38. 1 point
    It is up to the user to take "reasonable steps" to find the license. Keeping license notice in each file helps, especially when someone uses part of your code to create something else, and files with multiple licenses are mixed. Such situations are good to avoid, but if someone takes the code, he/she should check licensing and provide proper information in the derivative work. This is what you will actually find in GNU FAQ, though they make a big issue out of the derivative works: https://www.gnu.org/licenses/gpl-faq.en.html#NoticeInSourceFile To modify a lot of VIs, you may use pylabview - if you know how to use use python or bash, you can make a batch to extract, modify and re-create any amount of RSRC files with it. You only need to make the script which does the modification, ie. add the documentation to one file, and compare extracted XML before and after the modification to get a patch to be applied to all other files. For the selection - if you don't mind others using it for anything, MIT is a good choice. Though sometimes people say that, and then still feel cheated when someone makes modification to the work and starts making money out of it... if you feel unsure here, you may choose GPL instead. And if you completely don't care about license and want to mock it a bit, there's always DBAD - it's quite popular for underground tools.
  39. 1 point
    Saved in LabVIEW 7.1. Run Application.vi
  40. 1 point
    Here are some of mine. SystemDesigner - Although it is essentially MAX and only works with NI hardware, I like the fact that it provides an overview of the hardware, access to various documents (pinout, specs) and the ability to create and test measurement tasks from within LabVIEW. Not to mention the auto-generated code when placing tasks into VIs. Captured Data - Finally I can easily capture, export and import data without having to write custom code. Capture data once and use it often. This is very useful for testing code in development and prevents misuse of "Make Current Values Default", which tends to bloat VIs. It is also possible to just drop data into any compatible control (i.e. graph) without any manual labor. Build Queue - It is somewhat broken, but I like the fact that it can build packages in parallel. There is great potential for much faster builds when compared to CG, especially for large an complex projects. Learning - I like the way NXG guides users through learning projects (of which there are quite a few). Highlighting elements in the UI is very helpful for self-paced learning. Online Help - Not specifically a feature of NXG, but I like the way the new manual is structured. The context help could use some improvement though. Controls and indicators - I like the design of NXG controls and indicators. They look much better than modern controls in CG, especially when used in combination with a Windows 10 theme. That said, I hope they add support for system controls soon. Automatic File Organization - This is probably number one or two of features in NXG I really like. Moving files inside a project now automatically moves files on disk. No more housekeeping. Still, I miss virtual folders a lot.
  41. 1 point
    As seen in the other thread, I am pretty negative about NXG. However I would like to temper this with some things I have seen in NXG which I do like Vector based GUI. I don't like the choice of colours, fonts, widgets or pretty much any of the iconography but I do think the switch to vectors is an absolute necessity for a modern application running in high DPI settings. Zoom! I was pleasantly surprised when I accidentally zoomed on the Front Panel. In current gen to get pixel perfect GUIs sometime I find myself resorting to the windows magnifier or dropping down to 1024x768, so being able to zoom is a welcome addition. The helper alignment hints when placing Front Panel controls. Anyone who has used any kind of vector drawing application in the last 5 years will be immediately familiar here. (I am not sure why this is not done when designing a typedef though). The placeholder location for controls and terminals when dropped from the "other" view. No more weird and random location for new controls and terminals! WebVIs. The WebModule is not ready for any heavy lifting, but for basic web pages it currently does the trick. As a LabVIEW developer I really do not want to ever have to learn JS or HTML5 and WebVIs are certainly many steps in this direction (now please port this to current gen!). Now that I know what I am doing I guess I could start from nothing and put together a simple web VI that communicates with something else via a REST API in a couple of hours. The build process turns the VI into a bunch of HTML and JS which you can serve up with any web server. This technology has potential! The panel on the right hand side which can stay open and give you quick access to the properties of controls. It currently pretty ugly and unfriendly to usability with all its greyness, but the concept is quite sound. It can be hidden away when not needed. I am so used to the current gen properties window that it takes me a while to find anything but I expect that to diminish with more use. The icon editor. The default size of the glyphs is much too large but in general this pane gets the job done. At a glance I can see the association of all the terminals. I am not so keen at having Inputs and Outputs as submenu items as this just slows things down a bit, but the concept of showing the user the "direction" of the control is welcome. I have not really used it to create banners and stuff like that yet so I cannot comment too much on that UX. The Build Queue lists about 10 of the last builds which although I did not need in my experimental project I can see how this might be useful. If the build version number could be included in the table this would be most welcome. These bottom pane things can all be collapsed away when not needed which is good. That is about it. My experiment only involved creating a WebVI, so it is possible I have missed some neat things that can be done when developing a traditional desktop application. Does anybody have any others to add to this list?
  42. 1 point
    Inconsistent to a post i made 10 years ago? Besides, that was related to CG. I'm not advocating for removing an engrained CG feature. I thought we were discussing NXG. My assumption is this feature hasn't even beed implemented in NXG. There is a lot more work required in NXG to make it even barely usable. Lack of continuous run is not a problem in NXG. Lack of everything, is a problem.
  43. 1 point
    In order to resize an array you have to click on the tiny dot in the middle of the drag handle that only appears if your mouse is leaving the control and is some weird distance way from the border. In other words, in this picture in order to get the resize drag handle to appear I have to move my mouse over the control, then out a little bit into the middle of space with no visual indication how far out to move it until the horizontal bar appears and then find the tiny dot in the middle and then drag that. ๐Ÿคฎ How could this UX make it through 8 years of development? 2020-05-07 22-49-46.mkv
  44. 1 point
    A better way of looking at it might be that a variant is a specific data type. so if we assume c++ has some map<keyType, valueType> under the hood, the new labview map type exposes this directly and lets keyType and valueType be any labview type. the variant attribute system was specifically map<string, variant>. The api added some sugar on top so that if you specified a type, it performed variantToData(map.read(myStringKey), myDataType)...but it was still a map<string, variant>. If the content of your variant is a big array, this could potentially cause performance issues because of that variantToData. Vs 2019 where your map type might be map<string, lvArrayHandle> which doesnt need any of the weird memory allocation that happens if you call variantToData(myArrayInsideOfAVariant, dblArrayType). I dont know if this is precisely accurate, but thats what my general understanding was.
  45. 1 point
    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).
  46. 1 point
    Your argument is inconsistent. If it's not a priority then making a change to remove it is allocating resource to "the least important". Leaving it in would be the least impactful. However. If you are going to change it then you might as well make it a "Preference" since that is clearly what it is. You don't seem to have a preference or, at least, are indifferent. So why advocate taking away a feature that other people obviously feel strongly about?
  47. 1 point
    A short list of possible techniques: 1) Let the hardware do the timing. Things like DAQmx or IMAQdx can provide Events, such as "FrameDone", and some hardware can provide buffered data in precise short periods (every 50ms, say) where you can just make your timeout 0ms, because waiting 50ms means nothing to your UI actions. 2) have a loop/actor send a message periodically. In "Messenger Library" this actor is called "Metronome", and there is an AF component called I-forget-what that does similar. 3) send a time-delayed message to oneself; resending when it is handled. Also on Messenger Library and the AF. 4) Calculate the time till the action is next due, and use that as timeout (or just do the action if the remaining time is zero or negative). Recalculate after an other message/event. Generally, I would advise one never use a fixed timeout value to schedule a periodic action. With the above methods one can easily have multiple periodic actions occurring on different time scales without any interference (assuming all the actions are reasonably quick).
  48. 1 point
    Here is a new version 4.2.0b1 for the ZIP library. I didn't test it in every LabVIEW version on every platform. What I did test was MacOSx 32-bit and 64-bit LabVIEW 2014, Windows 32-bit and 64-bit LabVIEW 7.0, 7.1, 8.6, 2009, 2016, 2018, Linux 32-bit 7.1 and 8.6, and NI Linux x86 LabVIEW 2016. Other realtime targets I hadn't handy at the moment. Support for Linux 64-bit and NI Linux RT ARM as well as VxWorks and Pharlap is contained. The realtime support will only get extracted when installing into LabVIEW for Windows 32-bit and through a seperate exe file that is invoked and will prompt for an administrative elevation of this installer. You then have to go into NI Max and into the Software part of your target and select to install additional components. In the list should be an OpenG ZIP Tools version 4.2.0 package visible. Select that to be installed on your target. There are still following problems that I haven't implemented/fixed yet: 1) archives that contain file names with other encodings than your platform code page will go certainly wrong. This is probably not solvable without doing absolutely every file IO operation in the shared library too, since the LabVIEW file IO functions don't support any other encodings in the path. 2) If you try to zip up directories containing soft/hard inks then the current implementation will compress the actual target file/directory into the archive instead of a link and expanding zip archives that contain such links will expand just a small text file continaing the link destination. This is something I'm looking into to solve in the next release by allowing optionally adding a special link entry into the archive and create such a link on the filesystem when extracting. This is mostly of concern on Linux and MacOSX. While Windows also allows for such links nowadays it is still quite an esoteric feature and user accessible support for it is minimal (you have to use the command line or install additional third party tools to create/modify such links). Hope to hear from other platforms and versions and how it goes there. Without some feedback I'm not going to create a release. oglib_lvzip-4.2.0b1-1.ogp
  49. 1 point
    Version released. https://github.com/LabVIEW-Open-Source/DataManipulation/releases/tag/ 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...
  50. 1 point
    I created a package that allows you to create Markdown syntax files using LabVIEW. Code, Download, Bugs/Features, announcement. Ton

  • Create New...

Important Information

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