Jump to content

Aristos Queue

  • Content Count

  • Joined

  • Last visited

  • Days Won


Everything posted by Aristos Queue

  1. Note above where I quoted another NI engineer about the complexity of answering that question given the variations of Pis available. We (NI) does not own one of every possible Pi. We are able to give the tech specs of what is supported, but the model numbers are not so straightforward in their mapping. Therefore, the table will have to be crowd sourced over time. If you're shocked that the community has not built it yet, well, LV2020 CE only dropped on Tuesday. πŸ™‚
  2. Most of the existing customers surveyed like NXG. They just don't like how limited it is at this time. I, for example, really want to be able to use NXG. It has so many nice things. It just ain't ready for me yet. But it will be. And in the meantime, LV 20xx continues to be a thing. Used interfaces yet? πŸ™‚
  3. The Pi Zero is apparently a particularly complex case to figure out : I had to look it up. The PiZero uses a broadcom chip that is Arm11 era. But the same page also has links to Arm9 and even Arm7. So I believe the Zero uses an Arm11 or less which is V6 architecture.
  4. I went to ask. πŸ™‚ Answer: Yes. ARM V7 Pi or greater. The ARM standard is very hard to keep straight. Various vendors add their own suffix and number to indicate something they extended. I believe the correct statement is that we require that it have ARM architecture of ARMv7 or greater, as shown on the Wikipedia page. There will likely be some corner case that makes it harder to describe. As an example of confusion, the ARM8 is actually an ARMv4, the ARM11 is a V6, the Cortex M3 is a V7, etc.
  5. https://forums.ni.com/t5/NI-Software-Technology-Preview/ct-p/techpreview
  6. If you do not already have your own personal list of "Wow, NI really missed the mark here" bullet points, well, it makes me happy that we made at least one customer happy with that design. That makes me happy because I thought the count was zero. I'm not being sarcastic. The project window was a good first attempt, but it quickly showed problems, and we've never fixed those. But if it works for you, I'm not going to try to convince you otherwise.
  7. A) GUI isn't higher or lower priority than those language features. There are multiple teams working on NXG. B) The GUI generally is not seen as particularly broken. The particular UI for classes is (in my opinion) cumbersome but functional. The priority was getting classes working. There will be UI improvements over time. Honestly, NXG team has more credibility with that than I do in LV20xx. The "new class" experience in LV20xx has been terrible for how long? And we only got it fixed in LV 2020? NXG has shown a far better track record for releasing a language feature and then improving t
  8. The plan is to record it. Lots of new technology involved in this, so fingers crossed.
  9. The directions have changed rather radically on many points in response to user feedback. The new component system is completely redesigned twice from customer feedback, and that's another thing I definitely wish LV20xx could backport. They dropped work on interfaces to prioritize scripting because of overwhelming feedback that the scripting tools were higher priority for getting work done in NXG. (Interfaces help some large apps... scripting helped almost every developer either directly or in the tools written for others.) I am not on the NXG team, and yet I can point to decision after d
  10. Because the refactoring is so much better. I would make this change in a heartbeat in LV 20xx if I could do it without breaking compatibility. I would differentiate the icons in the project tree, which NXG chooses not to do. Take a look at LV 2020*... interfaces and classes use the same file extension, and it is way better for refactoring hierarchies. BUT we use distinct icons in the project tree and various other places. You can read the details of this decision in the document I published yesterday about interfaces. I even go into detail about where we deliberately do NOT differentiate
  11. Official answer from folks at NI: The answer is unfortunately no. We compile our VIs for ARM V7 architecture. Pi Zero is less capable, doesn’t support all instructions.
  12. I'm not sure where you get that. The execution engine is the same engine that LabVIEW 20xx uses. Classes and typedefs are the same things that they've always been. The limitation of gtypes being inside classes is one I've complained about personally... it is entirely a limitation of the UI, not the underlying nature of the entities involved. Yes, both .ctl and .lvclass use the same .gtype file extension. That makes refactoring G code to change between the two a lot simpler. But what the files represent? That hasn't changed. There are still 25 fundamental LabVIEW types, of which LabVIEW class i
  13. Without going into anything NI confidential, yes, NI has lost significant sales opportunities because the old fashioned UI of LabVIEW 20xx does not appeal to the next generation of engineers and scientists. Redesigning the UI from the ground up was the primary mission of NXG -- incremental adjustments were considered and rejected early on. NXG's design is very much driven by data from sources such as user testing, customer feedback, and sales numbers. Any issues NXG has had getting off the ground with customers are less from going in the wrong direction and more from having so many parts that
  14. This IS fixed in LV 2020, but it got left out of the Upgrade Notes*. I have posted details here: https://forums.ni.com/t5/LabVIEW/LV-2020-Upgrade-Note-Altered-rules-for-named-Bundle-and-Unbundle/td-p/4035624 The fix is very healthy for most apps, but we did find one internal-to-NI app that was dependent on the dumb-luck-that-it-sometimes-works behavior. We had to fix that one up by using the Coerce To Value primitive to set a name of the element in the caller. But going forward, such antics should not be necessary... the adaptation rules of named bundle/unbundle are now well-def
  15. LabVIEW Community Edition 2020 is now available for download. The commercial edition will follow sometime in May. We prioritized the Community release for all the engineers stuck at home under quarantine. LabVIEW 2020 introduces interfaces as a companion feature to LabVIEW classes. I and Allen Smith will be presenting what would have been our NIWeek presentations as a webcast this Friday. Two topics, one time: Intro to Interfaces (Stephen Loftus-Mercer) Interfaces and the Actor Framework (Allen Smith) Friday, May 1 10am, CDT Join here (Microsoft Teams required): LabVIEW 20
  16. I don't want to just remove the privates completely ... if you're working inside the class, you may need those. But there's an old compromise in the actual palette code... if a library is locked (not just read-only but actually locked) or password-protected, then hide the community and private scope methods. Our theory was that if a class is locked then its internal development is finished and published and any of its friended components are probably also done (or they know that they are friends and can go get that information). Similarly if all children are either non-existent or also l
  17. You cannot use any reference to the class itself within the class. Technically, we could enable some things, like a DVR of the class within the same class, because the default value is Not A Refnum. But we chose -- consciously -- to make the rule "no references to yourself in your own private data." It's an easier rule to teach, and it has various performance benefits for initialization (that mattered more on the hardware from 13 years ago than they do today). And it has come up very rarely. In fact, I think you're the first person whose asked me specifically about the VI reference case. All t
  18. No. I didn't take the time to do that. Would be cool if it worked though. If you decide to patch it up (there's no passwords on those VIs), I'm happy to ship the revision.
  19. In LV2019, I extended the right-click plug-ins to be able to attach a graphical palette so you can drop items from the menu. Then I added the right-click menu item to populate the palette for classes. And I just found out (thanks, Darren) that LV2020 doesn't update this graphical palette for methods coming from parent interfaces. Haven't even released... already have a patch list. *sigh*
  20. > Admittedly, it has been probably a year since I heard that discussion. About a year... yeah. πŸ™‚NXG's G scripting priority was... shall we say... re-evaluated after the European CLA Summit in 2019. It was kicked up a few notches after some very pointed comments from the user community, confirmed by Americas CLAs later that year. I'm not on that team and haven't kept tabs, but there should be some scripting support soon if it isn't already there.
  21. Bah, Crossulz! You are definitely not invited to the next White Elephant gift exchange. You'd show up with a wrapped present and just announce, "It's socks. Just so you know."
  22. You know how all LV objects are represented as cubes? What do you call just the surface of a cube? πŸ™‚
  23. > I have heard directly from NI that there are no plans to delay the releases that were planned for NI Week being in May. A few are moving a bit earlier even. I'll be flagging LV 2020 on LAVA as soon as it is available (if the NI marketing folks don't beat me to it). I'm maybe perhaps just a little bit excited about this particular release.
  24. That pretty much defeats the purpose of the VI. The whole point of the exercise was to figure out how big to size the VI relative to the monitor so the caller VI could maximally lay out its controls without taking up the whole screen... and if I don't know which monitor it is on, it doesn't work. πŸ™‚ BUT... you made a great point about the run-time engine. You're right that I should have avoided the use of scripting, esp since there's a dead obvious existing VI to use -- the subVI itself! So I eliminated the app reference (HUGE performance savings closing that reference), and the crea
  • Create New...

Important Information

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