Jump to content

Leaderboard

Popular Content

Showing content with the highest reputation since 01/17/2022 in Posts

  1. Update to this post: My sabbatical has ended. I went from Blue Origin to Microsoft, but as of a couple weeks ago, I have now returned to LabVIEW development. At some point, I may put together a public summary of my experiences as a full-time G dev. For now, be assured that I am feeding that experience back into the feature backlog priority list!
    6 points
  2. Thank goodness I've finally got that promotion. Y'all were holding out on this until I went back to writing C++ code for you, I assume. ;-)
    3 points
  3. I think you're more of a sidekick.
    3 points
  4. I'm a collaborator and I'm not sure I like that. I'd prefer to be in the resistance.
    2 points
  5. Indeed and LabVIEW DSC is on the way out. There have been no updates to it in years and support questions are blissfully ignored for a long time. HIQ was acquired in the first half of the 90ies and had the potential to compete with Mathematica and Matlab back then, but NI mainly used it to cannibalize some of its mathematical routines and add some of it to LabVIEW and then lost interest on it. Lookout was acquired around the some time. It was a very unique DSC software package with a rather interesting object oriented architecture. NI used the low level components to create its Logos network protocol infrastructure on which things like Datasocket and later Shared Variables were implemented. They also used various components of Lookout to convert the originally purely LabVIEW based BridgeVIEW system into LabVIEW DSC. After that Lookout spend its existence as a rather badly cared for step child in the NI product portfolio and eventually nobody was left over to support it anymore. LabWindows/CVI changed from yearly updates with new features added regularly to two year updates with not much more than cosmetic bugfixes for several years already. It's worse in terms of new features added than LabVIEW ever was for many years. But with LabVIEW they used the excuse that all effort was directed towards LabVIEW NXG and LabVIEW was going to be replaced by it one day. NI MultiSim used to be two products from the same company (Electronics Workbench) who were named Electronics Workbench and ULTIboard before they got acquired by NI and were at that time one of the leading EDA products in the educational market worldwide. Nowadays they are completely insignificant in the EDA market. If you have the money you will subscribe to Altium Designer, if you try to be a bit cheaper you may use Autodesk Fusion 360 or if you are an old time Eagle user then maybe Autodesk Eagle PCB and if you insist on Open Source then KiCAD will be very likely your choice (which has made large strides since CERN has decided to back it). Electronics Workbench (or NI MultiSIM) is not on that list for sure. I have used it a few times since it is part of our Alliance Member software lease but it is not up to the task of creating modern PCB designs and hence not worth the effort to learn its many specific mechanisms and bugs.
    2 points
  6. Re-use libraries whenever it is possible. I rather not reinvent the wheel. As for unused code, VI analyzer will find that. If a project has a Sub VI with no callers, I remove it from the project.
    1 point
  7. We normally just make the executable reboot the cRIO/sbRIO it runs on instead, through the system configuration function nisyscfg.lvlib:Restart.vi, but here are two discussions on killing and restarting just the rtexe on LinuxRT: https://forums.ni.com/t5/NI-Linux-Real-Time-Discussions/Launching-startup-rtxe-from-terminal-or-linux-window-manager/td-p/3457415 https://forums.ni.com/t5/NI-Linux-Real-Time-Discussions/Is-it-possible-to-close-and-re-open-RTEXE-through-Embedded-UI/td-p/3707540
    1 point
  8. Get the desired PropertyItem from the Properties[] property of the Property Node reference. Then you can set the isWrite property as desired.
    1 point
  9. What was the answer here? I'm trying to figure out the same exact thing.
    1 point
  10. 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 in later years working with the NXG team to design a future G. I really wanted it to fly. There is so much good in that IDE, including some amazing things that I just don't see how we ever do in the LabVIEW codebase without just shattering compatibility. But at the same time, I was watching good friends toil on something that the market just wasn't adopting. The software had some problems that were going to take a long time to solve. The issues were all solvable, but the time needed to fix them... that was harder and harder to justify. NXG gave us a GREAT platform for other software: Veristand, FlexLogger, etc. That code is extremely modular and can be repurposed for all sorts of tools. We also learned a heck of a lot by building NXG -- some things that I thought we could never do in LabVIEW now seem possible. NXG gave us a sandbox to learn a whole lot about modern software engineering without putting the delivery schedule for mature software at risk, and those practices [have been|are being] brought back and applied to LabVIEW -- that will decrease cost of maintaining older code. All in all, NXG was valuable -- the expenditure was not a complete loss. I am very sorry to the few customers who did migrate to NXG. We don't have a reverse migration tool, and building one would be absurdly expensive. Leaving those folks stranded is going to hurt -- I hate letting our customers down and just saying, "We have no solution to help you." There aren't many of those folks (that's essentially the problem), but they do exist, and they are basically stuck having to rewrite their NXG apps in some other tool. I can only hope that they pick LabVIEW. I don't know if this will help us or hurt us with customers in the future... on one hand, people may say, "Well, you let us down on NXG, why should we trust you will be there for us on any new products?" On the other hand, this decision was clearly made listening to customer feedback, and it takes a lot of humility to swallow a loss that big, which may make customers trust our judgement more in the future. And, really, there's nothing to compare with the scale of NXG -- an entire computing platform -- so this does seem like something that needs to be judged in isolation. I really like programming in G. I like being able to expand G to make it more powerful. I wanted NXG to succeed because it had the potential to be a better G. It failed. Its failure means more resources for the existing LabVIEW platform, which will directly help our customers in the short run. It leaves open some big questions for the long run. So, in summary: I think it was a decision that had to be made, and I'm happy to work for a company that can learn from new data, then admit a mistake, and then figure out how to correct it.
    1 point
  11. Seriously Monnie? Get your act together. Let that be a lesson to us all not to be a Monnie. (I don't actually know a Monnie, and have never heard of this term before but I love it)
    1 point
  12. So in a presentation about XNodes I was asked a question about what were the valid "Reply" options for an XNode ability. Some abilities have a reply as a 1D array of string and it appears to work like a QMH where you provide a list of states to go to and it does them one after another. I didn't know the answer but I knew scripting could help. So I scanned a bunch of XNodes for what strings were on the block diagram going to the reply and here are the abilities, along with the reply strings I've seen used. AdaptToInputs UpdateTerms UpdateImageAndBounds GenerateCode ForceAdaptToInputs Copy GenerateCode UpdateTerms UpdateImageAndBounds FailTransaction DoubleClick FailTransaction UpdateTerms UpdateImageAndBounds GenerateCode GenerateCode PreserveUserCodeGUID GetError Message UpdateTerms UpdateImageAndBounds GenerateCode FailTransaction ForceAdaptToInputs OnFontChange UpdateImageAndBounds UpdateTerms OnOperateClick UpdateImageAndBounds GenerateCode OnResize UpdateTerms UpdateImageAndBounds GenerateCode OnDrop UpdateTerms UpdateImageAndBounds GenerateCode OperateClick ShowMenu RefeeChanged GenerateCode UpdateImageAndBounds UpdateTerms RespondToDrop GenerateCode UpdateTerms UpdateImageAndBounds SelectMenu UpdateImageAndBounds UpdateTerms GenerateCode FailTransaction ReplaceSelf Size UpdateImageAndBounds UpdateTerms GenerateCode UpdateState GenerateCode ForceAdaptToInputs IssueWarning UpdateStateWithRef UpdateImageAndBounds UpdateTerms GenerateCode ReplaceSelf So the unique values that I've seen put into the Reply are the following. I am unsure if only some abilities only support some replies. UpdateTerms UpdateImageAndBounds GenerateCode ForceAdaptToInputs FailTransaction PreserverUserCodeGUID GetError ShowMenu ReplaceSelf IssueWarning As for what do these do? Well some are more obvious than others, but here is some text I found in one of the XNodes that helps: FailTransaction: LabVIEW will abort the current transaction. This will avoid putting transactions in the undo list when the user just hit cancel. GenerateCode: This will cause a type propagation if appropriate, and will cause the XNode to GenerateCode when type propagation is run. UpdateImage: LabVIEW will call Image and invalidate the XNode. UpdateImageAndBounds: LabVIEW will call Bounds and Image and resize and invalidate the XNode. It will not call Size. Size is only called if the user resizes the XNode (so that you may update your state and return this reply). Make sure that if your terminals need to change size or location, you also return UpdateTerms. This reply will set the transaction type. UpdateTerms: LabVIEW will call Terms and create, delete, and move terms as necessary. ForceAdaptToInput When mutating an old, unconfigured Express VI, we need to ForceAdaptToInputs before code gets generated. AdaptToInputs used to always get called before GenerateCode. But that is no longer the case in LV2011.
    1 point
×
×
  • Create New...

Important Information

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