Jump to content

Leaderboard

Popular Content

Showing content with the highest reputation since 12/21/2020 in Posts

  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. Are Italian LV developers more prone to producing spaghetti code? ๐Ÿคจ
    3 points
  3. Shaddap-a you face!
    3 points
  4. 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
  5. You got it right. "Delete branch" will delete the branch on your fork. It does not affect the clone on your computer. The idea is that every pull request has its own branch, which, once merged into master, can safely be deleted. This can indeed be confusing if you are used to centralized VCSs. In Git, any repository can be remote. When you clone a Git repository, the source becomes remote to the clone. It doesn't matter if the remote is on your computer or on another server. You can even have multiple remote repositories if you wanted to. You'll notice that the clone - by def
    2 points
  6. That's not very American. Where's the guns?
    2 points
  7. 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
  8. - LVCompare and LVMerge should be unlocked with the LabVIEW base edition. Or even better, an open source merge and compare tool could be released to the community.
    2 points
  9. In the world of C it is up to us to declare variables such as those Refnums as 'volatile' so the compiler knows they may change despite the appearance of being loop invariants. I would say it is a bug that the LV compiler does not treat Refnums as volatile. I'd say most of your workarounds would work, but are in (slight) danger of being optimized away as the compiler improves. Personally, I'd drop an 'Always Copy' node instead of the IPES.
    2 points
  10. Free is maybe pushing it. Zero technical support without a SSP would be an appropriate model associated with open source. Of course this wouldn't prevent a vibrant community support (independent from NI) from existing, but this is not what the big industrial companies using LV would go for. They would remain NI's proverbial cash cows. I think the misunderstanding on the corporate side of why open source is beneficial for code safety and reproducibility is understandable, as I can witness the same ambivalence if not resistance in academia. As for NXG and webUI (or whatever they call
    2 points
  11. To be honest, I would probably not put them anywhere in that view. Itโ€™s called Class View for a reason. ๐Ÿ˜€ It hadnโ€™t really occurred to me that you would want to have the non-class VIs visible in there. Is that a flaw or just out of the box thinking?
    2 points
  12. My informations from inside NI is that this is largely untrue. NXG team will be re-assigned to other projects and a large part focusing on non-Windows OS support ๐Ÿ˜ฎ I don't have much details but different sources corroborate this.
    1 point
  13. here a post on how to update to the last sql libraries (3.34) to run successfully that example on NI RT
    1 point
  14. This is a named unbundler for clusters; but instead of taking in a cluster value and outputting element values, it takes in a reference to a cluster and outputs references to elements. Sadly, it can't handle a cluster containing a latching boolean. Unbundle Refs By Name_xnode 1_0_0_1.zip
    1 point
  15. Here is the new revamped UI of NI TestStand 2020: Maybe it's just me, but I find it very difficult to work with the new color scheme of NI TestStand. My eyes are burning after few minutes... Am I the only one? Here is the default UI colors of VS Code, the super popular code editor from MS. So much less stress for the eyes. Hoping for dark mode NI TestStand in a near future...
    1 point
  16. NI: "Engineer Ambitiously" "Change some fonts and colours, that will shut up the filthy unwashed masses who are not Fortune 500 companies"
    1 point
  17. So I am not a Modbus expert, but have definitely written information to a PLC in the past. As far as I know you cannot write to input registers, I presume you can write to output registers (are they called coils?). I don't have the toolkits installed on my PC right now so I cannot check. This code below works fine for setting Holding Registers. Have you tried writing to the Holding Registers? I
    1 point
  18. You might want to consider MXI (Either optical or copper) as an alternative. It avoids another layer of drivers. Desktop PCs with Thunderbolt exist, (Mac pro, other high end workstations from Dell or HP).
    1 point
  19. Bearing in mind Antoine's comment with which I wholeheartedly agree with, I would suggest upgrading to 2020 now and plan for deliverables with SP1 or later as and when they arrive. You can have multiple versions installed side-by-side on a machine and you want time to find any upgrade issues with your current codebase and gradually migrate with fallback to your current version if things go wrong. Reasoning for 2020 is that that it supports HTTPS - which none of the previous versions do out-of-the-box and is essential nowadays. 2020 is, by now, a known entity in terms of issues and work-ar
    1 point
  20. I'm sure you'll get plenty of different opinion on that topic. My rule is to only use SP1 versions for customer release (not sure NI will continue using the 202X and 202X SP1 pattern though). I remember reading a blog post from John Pasquarette in which he described the bi-annual release cycle that started in 2009 but I can't spot the article again.
    1 point
  21. Yes, there is many things wrong with this. What about the new adapter icons. What is the point of moving away from the well known product logos and just use the first letter of product name instead? It makes no sense.
    1 point
  22. Are you sure you burned the correct amount of sage during the incantation?
    1 point
  23. Are Swiss more likely to have holes in their code? I hoped you aren't cheesed by this comment.
    1 point
  24. Finally here it is. Refnum_to_Pointer-Linux.zip Refnum_to_Pointer-MacOS.zip Tested in LV 2020 on Ubuntu 20.10 and macOS Big Sur. It's assumed to work in 64-bit editions of LabVIEW only.
    1 point
  25. It never will be until they resolve their distribution issues which they simply do not even acknowledge. Even Linus Torvalds refuses to use other distro's because of that. What Windows did was to move common user space features into the kernel. The Linux community refuses to do that for ideological reasons. The net result is that application developers can't rely on many standard features out-of-the-box, from distro-to-distro, therefore fragmenting application developers across multiple distro's and effectively tieing them to specific distro's with certain addons. Those addons also have
    1 point
  26. Maybe 2021 will be the year of Linux on the desktop, but given that this has been predicted every year since about 2003 I would not hold my breath. LabVIEW will never be open source. It would not make sense, nobody outside of NI would be able to maintain it. LabVIEW is not the Linux kernel which is of huge interest to millions of others. The area of the intersection on the Venn diagram of skilled enthusiastic LabVIEW developers, ultra-skilled C++ developers, and those with enough spare time is approximately zero. The full complement of engineers at NI can barely make any progress into the
    1 point
  27. The problem with the argument about better mergeability if LabVIEW would use a text based file format is that XML and really any format that can represent more complex data structures, can not easily be merged with current tools. It doesn't even fully work for normal text based languages as the merge tool can NOT determine what to do when two code modifications occurred at the same or immediately adjacent line location in a text file. You end up with conflicts that have to be resolved manually. While that is doable although not fully painless for normal text based languages, XML and similar f
    1 point
  28. Good selection by @Mefistotelis Try to figure out what motivates them (games, machines, information, ...) and help them find the right resources. Try different things, perhaps something sticks. If not, move on to the next. Here are two links that can get you started with python in a few minutes. Take your first steps with Python - Learn | Microsoft Docs Python Getting Started (w3schools.com)
    1 point
  29. Depends on a kid. Depends on his interests. If you're just after programming a PC: Scratch is quite popular. There's also similar thing called Blocky. If the kid won't get into things unless that's a game: Baba is you is a great game for kids. He probably already has some favorite games, and many games today use LUA. So he could also start modifying a game he knows using LUA scripts. If he prefers to drive something mechanic, like a robot: There are some DJI products for kids, like Robomaster or Tello. Not the cheapest, but high quality.
    1 point
  30. I actually don't care enough for LV to get triggered by the first sentence. But the last one... ๐Ÿ˜ก
    1 point
  31. I see a lot of people wanting this, but why? We code graphically after all. The way to make sense of the underlying code to a G-programmer is to present it as G-code, not text... Ideally we had a SCC-system made specifically for graphical code, but I do not expect that to become a reality (unless someone made it on top of an existing one perhaps). Personally I live relatively comfortably with the solutions we can set up already, but would prefer to see it better integrated into LabVIEW and/or have out of the box solutions on how to get started with various major SCC alternatives. If
    1 point
  32. One of the key differences in the IDE with NXG is the single window view. It took some digging but I found an old LabVIEW 8 beta that had a similar design. I'm guessing they had usability issues or something as it obviously didn't end up like this. Maybe similar to the ribbon interface and how that was only really used on the Web UI builder and an alpha.
    1 point
  33. Glad to hear it worked out well for you. I wish I had this confidence 10 years ago... I agree. Unfortunately the decision is not always up to us, especially for young teams without expert recognized by higher-ups. In our case it went something like this: NI is also not very helpful in dampening expectations: The rest is history. To be fair, our case was a single incident. The general experience with contractors has been very positive and insightful. Still, I would probably raise an eyebrow if a CLA told me that they don't know how to work with classes. Just see
    1 point
  34. I note that even though I created a framework, Messenger Library, I did not re-architect any existing project using my framework, but instead just used it to add new features to those projects. Then I used Messenger Library for all new projects, armed with actual experience. Trying to rework the entire architecture of a large project sounds very expensive and risky.
    1 point
  35. I tried to import a vector graphic from Inkscape to LabVIEW 2013, but it does not give me proper results. It looks more like a pixel based format as a vector image. WMF looks worse, it is even smaller and it came into LabVIEW with different dimensions after the import compared to EMF. Any idea how I can improve this vector import to LabVIEW? (copy/paste via clipbord from Inkscape to LabVIEW does not work) Rotary XY achsis control - normal.7z
    1 point
  36. Yes, definitely for CLAs. OOP is fundamental in almost every other high-order programming language, why should G be any different. In fact, I believe, NI should teach OOP a lot earlier in the Core classes. If for nothing else, to teach encapsulation. Inheritance and overrides can come later but CLAs should be familiar with all those concepts. See "Encapsulation in King! by Daniel Harryman from GDevCon#1" for a good example of why and how to teach this.
    1 point
  37. You don't need a Ph D thesis. Some people thought they could do <INSERT PROJECT HERE> better with the latest whiz-bang stuff and convinced management they could do it. I've seen it a hundred times.
    1 point
  38. 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
    1 point
  39. I know this is an old post, but just in case someone else tries this code... I just downloaded the code and the TSPopu.FG.Poup.vi was broken, I made a minor modification in the Show case to have the event registration pass through (I don't think the Generate User Event.vi does anything to the reference itself. The code seems to work fine after this change.
    1 point
  40. Ok, Check out the demo in the ZIP file It's not hack code, but is definitely missing documentation. So in lieu of that, here is a narrated story time http://screencast.com/t/dJsMkZkDA0 http://screencast.com/t/9dgIuC97LZwP Ports back to LabVIEW 7.0 at least (original code from 2003) ~,~ The Captain Was Here My Source Distribution.zip
    1 point


×
×
  • Create New...

Important Information

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