Jump to content

Leaderboard

Popular Content

Showing content with the highest reputation since 06/21/2020 in all areas

  1. Dear Santa NI I am now in my 40s with youngish kids, so despite the fact that all I got for Christmas this year was a Pickle Rick cushion I am not actually complaining. However, I would like to get my order in to the Elves as early as possible. This is my wishlist, in no particular order. I expect this list will not be to everyone's taste, this is ok, this is just my opinion. Make LabVIEW free forever. The war is over, Python has won. If you want to be relevant in 5 to 10 years you need to embrace this. The community edition is a great start but is is probably not enough. Note: I
    14 points
  2. “There was this fence where we pressed our faces and felt the wind turn warm and held to the fence and forgot who we were or where we came from but dreamed of who we might be and where we might go...” -- Opening lines of “R is for Rocket” by Ray Bradbury I spent 20 years building this G language of ours. It’s time for me to go enjoy the fruits of that labor as a user! I will still be employed by NI, but I will be working full time for Blue Origin. As part of the NI “Engineer in Residence” program, I will be on loan to Blue Origin to revise their engine and support test systems. They
    12 points
  3. I did not know. That possibility was not even on my radar. Even though the drumbeat of bad news had been going for a while, most corporations refuse to change direction on a bad decision. NI showed more sentience than I usually expect from massed humans: the sunk cost fallacy is a trap that is very hard to get out of. I figured the very good engineers on NXG would either surge through it and make it fly or we would bankrupt the company trying. That's the pattern established by plenty of other companies. Mixed. I spent 4.5 years directly working on NXG (2011 to 2016) and countless hours
    12 points
  4. Does it help to re-ask the question as "where should LabVIEW have a future?" It is not difficult to name a number of capabilities (some already stated here) that are extremely useful to anyone collecting or analyzing data that are either unique, or much simpler, using LabVIEW. They're often taken for granted and we forget how significant they are and how much power they unlock. For example (and others can add more): FPGA - much easier than any text-based FPGA programming, and so powerful to have deterministic computational access to the raw data stream Machine vision - especially
    5 points
  5. I've just implemented this and posted a beta: https://forums.ni.com/t5/JDP-Science-Tools/BETA-version-of-JSONtext-1-5-0/m-p/4136116 Handles comments like this: // Supports Comments { "a":1 // like this "b":2 /*or this style of multiline comment*/ "c": 3 /*oh, and notice I'm forgetting some commas A new line will serve as a comma, similar to HJSON*/ "d":4, // except I've foolishly left a trailing one at the end }
    5 points
  6. @Aristos Queue, I was part of the private preview event and afterwards there were several comments basically saying "I watched all of this and have no idea what NI is announcing". And multiple requests that NI make it clear what they are trying to announce. I thought maybe the public event would be more clear. Nope, dozens of comments were flying in asking what, if anything was changing as the event went on. After the event ended my favorite comment was "That was a great introduction, but when does the actual event start?". Threads on Reddit, LAVA, and NI all have had various amounts of "
    5 points
  7. Are Italian LV developers more prone to producing spaghetti code? 🤨
    4 points
  8. I have been coming round to supporting comments in JSONtext, at least for ignoring comments on reading (which is quite simple to implement, I think). And possibly features to be more forgiving of common User error, such as missing commas.
    4 points
  9. Coming from my personal experience, I still lean towards no. I had a discussion with Nancy Hanson about this and we came the the conclusion that the CLA was not a destination, but the opening of doors to learn (yes, this was alluding to the CLA Summits). Personally, I had 0 experience using OOP when I got my CLA. But after my second CLA Summit, I found an application that deserved a very basic OOP architecture. The CLA Summit opened that door for me. Now I would say ~50% of what I do is OOP. There is still A LOT you can do effectively without OOP. And keep in mind that part of a CLA is
    4 points
  10. I have made public a document detailing an old internal feature of LabVIEW that will be of great interest to those of you deploying Packed Project Libraries. Until recent conversations with a customer, I never considered that this would have much utility. The problem this solves: First, you build a packed project library (PPL) from source. Then, you write a VI that calls that PPL. It works fine. But now you load the caller VI under a different target in your project. The caller VI breaks because it tries to load the PPL, and the PPL refuses because it isn't built for the new target. Packe
    4 points
  11. Version 1.5.4

    941 downloads

    Package for working with JSON. Uses high-speed text parsing, rather than building an intermediate representation as with prior LabVIEW JSON libraries (this is much faster). Allows easy working with "subitems" in JSON format, or one can convert to/from LabVIEW types. Uses the new "malleable VIs" of LabVIEW 2017 to convert to any LabVIEW type directly. JSON text makes use of a form a JSON Path notation, allowing easy and rapid access to the subitems of interest. Requires LabVIEW 2017 and install by VIPM 2017 or later. Original conversation about JSONtext. On the LabVIEW To
    4 points
  12. Hi Everyone, I was just alerted to this discussion (thanks @drjdpowell), so I wanted to be sure I heard all the feedback, to make sure we're staying on top it. Before I dive in, I'll mention there is a version 2020.1 in beta right now (if you can't access this, please be sure you sign up for the beta and/or send me a PM). This addresses many of the points raised here, so please check it out. Also, it's important to mention that VIPM 2020 had a LOT of work (and love) put into it, and the beta+launch was in the middle of COVID-19, so things didn't get as many eyes (i.e. beta
    4 points
  13. In an attempt to standardize my handling of formatting timestamps as text, I have added functions to "JDP Science Common Utilities" (a VI support package, on the Tools Network). This is used by SQLite Library (version just released) and JSONtext (next release), but they can also be used by themselves (LabVIEW 2013+). Follows RFC3339, and supports local-time offsets.
    4 points
  14. Yes, I don't assume you use many new features of LabVIEW from the last 10 years if you still develop in LabVIEW 2009.
    3 points
  15. NI didn't say they would be porting NXG features to 2021, but to future versions of LabVIEW. Technically such a promise would have been unfulfillable, since at the time the NXG demise was announced, LabVIEW 2021 was basically in a state where anything that was to be included in 2021 had to be more or less fully finished and tested. A release of a product like LabVIEW is not like your typical LabVIEW project where you might make last minute changes to the program while testing your application at the customer side. For a software package like LabVIEW, there is a complete code freeze except
    3 points
  16. Working on the next JSONtext functionality, which is features to improve support of JSON Config Files. See https://forums.ni.com/t5/JDP-Science-Tools/BETA-version-of-JSONtext-1-6/td-p/4146235
    3 points
  17. VISA is ok but not everyone uses it so...
    3 points
  18. I've encountered a black imaq image display in exes, solved by unchecking the box to allow running in a later runtime version. Don't know if that is related to your problem.
    3 points
  19. I've been toying with the idea of implementing a new TOML library for LabVIEW. I've been using OpenG variant config for years, but I would prefer to use a more standardized format for my ini config files. TOML is the best candidate for this. Erdosmiller's library is pretty good, but as the author points out, it is no longer maintained, and it didn't gracefully handle all of the datatypes that I wanted to use. It would be great to have the flexibility of jsontext but for TOML format. I'll post back here if I manage to get the project off the ground.
    3 points
  20. So this was posted on the NI forums: https://forums.ni.com/t5/LabVIEW/Our-Commitment-to-LabVIEW-as-we-Expand-our-Software-Portfolio/td-p/4101878?profile.language=en
    3 points
  21. Update: I used the dll call from the link @dadreamer provided, and made a Messenger-Library "actor" that I can use for debugging. Already found a couple of bugs with it.
    3 points
  22. Shaddap-a you face!
    3 points
  23. I agree with all your points. Definitely on making LabVIEW free for all purposes, if not even open source. NI may hang on to the mega-costumers for a while with its current business model. But eventually it'll get marked as a legacy software and slowly replaced by younger people with newer ideas and experience in different, more accessible languages. The idea that a company can sell a programming language these days is ridiculous when there are so many free alternatives. I am not counting the community edition. It needs to be free for any purpose.
    3 points
  24. I don't really expect many new language features or UX improvements in LabVIEW just because they stop working on NXG. From what we know there are only a few knowledgeable people at NI who are intimately familiar with the codebase and some of its intricate details which fundamentally drive LabVIEW. There are also many customers who rely on that technology for their own business. Because of that, NI can't just throw more developers at it and change LabVIEW fundamentally unless they find a way to stay compatible or take a bold step and do breaking changes (which are inevitable in my opinion)
    3 points
  25. The first time you mentioned this I thought it was a nice gesture, now I think you are just desperate for friends...or an alcoholic. I'm down.
    3 points
  26. I want to remind once again that all this information is just to have fun playing with LabVIEW and not intended for real projects use. I believe you all understand that. 🙂 Not that a big opening here and even not an opening for some ones, but I found this interesting enough to make a thread. As you may already know, when some library is being called using CLF Node, LabVIEW enters ExtFuncWrapper first to do some guard checks to prevent itself from a silent crash and output some error message to the user instead. I've always considered that wrapper boring enough to study, thus never looked
    3 points
  27. After starting NXG 5.0.0 and traditional hang of the whole OS for 3 minutes, LabVIEW forgot how to write text on the screen Ok, not only LabVIEW, other apps too... They used to have a name software that caused weird system behaviour: a virus...
    3 points
  28. Here are my points: By default it should list about 15 to 20 of the most recently updated packages. That way even new packages get promoted and it doesn't feel "static". I want to select between a few high level categories (i.e. Frameworks, Utilities, Drivers). I want to specify the version of LV that the package should support (it should take older package versions into account). Each package should provide some key facts: Name, version, author, summary, picture, rating, price, download count, download button. I want to open the details page if I find a package
    3 points
  29. on that note, stumbled upon this last night...
    3 points
  30. https://www.tiobe.com/tiobe-index/ LabVIEW dropped below 50... Might it be that its rank follows its average user age?
    3 points
  31. The Application class has a couple of private methods which can do this (called Global Data.Set and Get) which operate on a name and a variant value (I believe this goes back at least to 2009). I think this should persist across QD calls. Note that you should pick a name which will be different from other things which might exist in the system.
    3 points
  32. TL;DR: This is NOT a bug. It is all explainable by the normal behavior of the memory management mechanisms used by LabVIEW, including a memory allocator layer provided by SmartHeap (from MicroQuill). Details: Actually the original bug report in Dec 2013 by Mr Mike (bonjour, Mike!) was pretty accurately analyzed and documented by Ryan P in 2014 and the bug was closed then. Mike's post from today did manage to gain the attention of someone else at NI, who asked me to take a look. I reviewed the VIs from this page and decided I could explain all the behavior with actual numbers. See the en
    3 points
  33. That's a mighty fine VM you got yourself there. Almost like having a VM of this Linux RT target is a super useful tool, that helps troubleshoot and debug features of the embedded UI that are at times "inconsistent" as you put it. For anyone else that finds this useful you should go vote on the idea, and/or contribute to the conversation.
    3 points
  34. This actually sums it up quite nicely 😋
    3 points
  35. I've seen that with clients I have been working for on LabVIEW related projects. A new software development manager came in with a clear dislike for LabVIEW as it is only a play toy. The project was canceled and completely rebuild based on a "real" PLC instead of a NI realtime controller. The result was a system that had a lot less possibilities and a rather big delay in shipping the product. Obviously I didn't work on that "new" project and don't quite know if it was ever installed at the customer site. That said, we as company are reevaluating our use of LabVIEW currently. We have no pl
    3 points
  36. https://youtu.be/4pDHBrBRILQ I've managed to get the runtime happy enough to run on the RockPi S, a 64bit quad core SBC that's a third the size of a Pi. The LabVIEW stuff is still 32bit of course but this opens the door for supporting even more devices. One of the tricks I pulled to get it to work is to first enable armhf (32bit packages) on the RockPi, manually edit the lvrt20-schroot package metadata to remove its dependencies on schroot and python since it was trying to install the 32 bit versions, and just manually install those packages before manually installing the edited lvrt
    3 points
  37. I think the longer my relationship with NI carries on, the more the message seems to be that I'm not considered part of the direction NI is concentrating on at all. In a way, the new announcement is a bit like "this isn't designed for you, do you hear us loud and clear?"
    3 points
  38. The core of our business has changed. Fewer users are developing their own test applications; instead, they're buying something off the shelf like TestStand. Fewer users are developing their own data acquisition software; instead, they're buying something off the shelf like FlexLogger. This trend alters significantly the role of LabVIEW (CG and NXG) in the NI ecosystem -- it becomes far less important to support whole application development (though, of course, we still do and will) and far more important to support "just a bit of customization" when the pre-built tools fail. A lot of softwar
    3 points
  39. You can edit that wiki if you have more info. or write your comments in "Discussion" page if you're unsure about editing it directly. I created a whole category of articles there: https://labviewwiki.org/wiki/Category:LabVIEW_internals
    3 points
  40. I used to think the future of LabVIEW was bright. I thought CompactRIO was amazing and thought everyone would want to use it for all kinds of control systems. LabVIEW was just intuitive to me, jobs and well paying contractor gigs were plentiful and hitched the first decade of my career to it. Got to do some interesting things but decided it wasn't such a smart idea to be locked to the fortunes of one company, whose decisions didn't really make sense to me. Yes LabVIEW will be around in the same way LISP is. 20 years from now people will reminisce about visual programming and how advanced it wa
    2 points
  41. There is and it is called Interapplication Communication. Which one to use depends on the platform and your familiarity with a specific method. - File IO (multiplatform, trivial to setup, difficult to manage as you have to deal with concurrency of two applications trying to access the same file) - DDE (Windows only, ultra ancient and much older than legacy, don't ever use it if you can help it) - Shared memory (super high throughput, complicated to use, pretty different APIs and methods on each platform) - (D)COM (Windows only, complicated to use from anything else than C(
    2 points
  42. @The Q started such a thing on the LabVIEW Wiki: https://labviewwiki.org/wiki/Text-Based_terminology
    2 points
  43. I've fixed quite a few bugs and changed the way timestamps are handled, now using JDP Science Common VIs for RFC-3339 You can follow on GitHub
    2 points
  44. Actually swiss cheese doesn't have holes, french cheese does. Sometimes proverbs are inaccurate. I'm french.. so no 😉 Lots of white flags in my code 😆
    2 points
  45. I've submitted a new version to the Tools Network.
    2 points
  46. It could make sense if the PostgreSQL DLLs were compiled with Microsoft Studio 2010 or 2012 or similar (not sure which Visual Studio version is used for compilation of LabVIEW 2015) and set to use dynamic linked MS C Runtime library. It is old enough to not be standard on a recent Windows 10 installation and not new enough to not be tightly coupled with a specific Microsoft Visual C runtime version. Since about Microsoft Studio 2015, the Visual C runtime has stayed at version 14.x and doesnt with each new version require a new runtime. It's still possible that a newer Visual Studio application
    2 points
  47. From what we have discussed so far, the Messenger Library certainly seems to be a perfect fit. It'll provide you with the infrastructure to run any number (and type) of workers and communicate with them in a command-like fashion. It is, however, a much more advanced framework than the simple message handler from my examples. As such, it will take more time to learn and use properly. As someone who enjoys the company of technicians who get scared by things like "classes" (not to mention inheritance 🙄), I strongly suggest to evaluate the skill levels of your maintainers before going too
    2 points
  48. Version 1.0.0

    676 downloads

    Hi everyone, Since GRBL standard is open source, I decided to post my Library that I used in LabVIEW to interface a standard GRBL version 1.1 controller. Not all GRBL function has been integrated, but this is a very good start. Enjoy and let me know your comments. Benoit
    2 points


×
×
  • Create New...

Important Information

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