Jump to content

Leaderboard

Popular Content

Showing content with the highest reputation since 12/08/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 accept it might be necessary to charge for FPGA stuff where I presume you license Xilinx tools. NI is and has always been a hardware company. Make all toolkits free. See the above point. Remove all third party licensing stuff. Nobody makes any money from this anyway. Encourage completely open sharing of code and lead by example. Take all the software engineering knowledge gained during the NXG experiment and start a deep refactor of the current gen IDE. Small changes here please though... we should not have to wait 10 years. Listen to the feedback of your most passionate users during this refactor. NXG failed because you ignored us and just assumed we would consume whatever was placed in front of us. I am talking about the people like those reading this post on Christmas day and their spare time because they are so deeply committed to LabVIEW My eyes are not what they used to be, so please bring in the NXG style vector graphic support so I can adjust the zoom of my block diagram and front panel to suit accordingly As part of the deep refactor, the run-time GUI needs to be modernised. We need proper support for resizable GUIs that react sensible to high DPI environments. Bring the best bits of NXG over to current gen. For example the dockable properties pane. (Sorry not much else comes to mind) Remove support for Linux and Mac and start to prune this cross compatibility from the codebase. I know this is going to get me flamed for eternity from 0.1 % of the users. (You pretty much made this decision for NXG already). Windows 10 is a great OS and has won the war here. Get rid of the 32-bit version and make RT 64-bit compatible. You are a decade overdue here. Add unicode support. I have only needed this a few times, but it is mandatory for a multicultural language in 2021 and going forward Port the Web Module to Current Gen. All the news I have heard is that the Web Module is going to become a standalone product. Please bring this into Current Gen. This has so much potential. Stop adding features for a few years. Spend the engineering effort polishing. Fix the random weirdness we get when deploying to RT Open source as many toolkits as you can. Move the Vision toolkit over to OpenCV and make it open source Sell your hardware a bit cheaper. We love your hardware and the integration with LabVIEW but when you are a big multiple more expensive than a competitor it is very hard to justify the cost. Allow people to source NI hardware through whatever channel makes most sense to them. Currently the rules on hardware purchasing across regions are ridiculous. Bring ni.com into the 21st century. The website is a dinosaur and makes me sad whenever I have to use it Re-engage with universities to inspire the next generation of young engineers and makers. This will be much easier if the price is zero Re-engage with the community of your most passionate supporters. Lately it has felt like there is a black hole when communicating with you Engineer ambitiously? What does this even mean? The people using your products are doing their best, please don't patronise us with this slogan. Take the hard work done in NXG and make VIs into a non-binary format human readable so that we can diff and merge with our choice of SCC tools Remove all hurdles to hand-editing of these files (no more pointless hashes for "protection" of .lvlibs and VIs etc) Openly publish the file formats to allow advanced users to make toolkits. We have some seriously skilled users here who already know how to edit the binary versions! Embrace this, it can only help you. Introduce some kind of virtualenv ala Python. i.e. allow libraries and toolkits to be installed on a per-project basis. (I think this is something JKI are investigating with their new Project Dragon thing) For the love of all that is holy do not integrate Git deeply into LabVIEW. Nobody wants to be locked into someone else's choice of SCC. (That said, I do think everyone should use Git anyway, this is another war that has been won). That is about it for now. All I want is for you guys to succeed so my career of nearly 20 years does not need to be flushed down the toilet like 2020. Love you Neil (Edited: added a few more bullets)
    14 points
  2. TDF team is proud to propose for free download the scikit-learn library adapted for LabVIEW in open source. LabVIEW developer can now use our library for free as simple and efficient tools for predictive data analysis, accessible to everybody, and reusable in various contexts. It features various classification, regression and clustering algorithms including support vector machines, random forests, gradient boosting, k-means and DBSCAN, and is designed to interoperate with the Python numerical and scientific libraries NumPy and SciPy from the famous scikit-learn Python library. Coming soon, our team is working on the « HAIBAL Project », deep learning library written in native LabVIEW, full compatible CUDA and NI FPGA. But why deprive ourselves of the power of ALL the FPGA boards ? No reason, that's why we are working on our own compilator to make HAIBAL full compatible with all Xilinx and Intel Altera FPGA boards. HAIBAL will propose more than 100 different layers, 22 initialisators, 15 activation type, 7 optimizors, 17 looses. As we like AI Facebook and Google products, we will of course make HAIBAL natively full compatible with PyTorch and Keras. Sources are available now on our GitHub for free : https://www.technologies-france.com/?page_id=487
    6 points
  3. Two questions about this: 1. Does something like this already exist? 2. Is this something that could be useful? Every once in a while I need dynamic UI components that can be generated at runtime. One nice thing to use for this is a picture control; however it doesn't lend itself as well to keeping other pieces of function such as mouse click events and such. I put together a mini library of UI functions for this that has the ability to be extended. The UI can be generated dynamically at runtime and be any picture thing that you can draw. Using Standard layout techniques that you might find in other GUI libraries. The hierarchy generation can always be simplified by using some type of templating string. Example1.vi Front Panel on Pgui2.lvproj_My Computer _ 2021-07-02 14-03-54.mp4
    6 points
  4. So I managed to find the underlying issue and at least one solution to it - sharing the information here. The Icon editor enumerates the font list in linux with command 'fc-list'. With OpenSUSE 43.2 / LV 2016 combo the fontlist looks like this: The listed fonts are essentially a list of the font files with full paths, and that does not work well with the font tool LV uses. If this list looks similar to yours and the fonts are not looking pretty, I have a solution for you - read on. To fix this a command 'fc-list : family' should be used instead, to come up with a list like this: There are two solutions (and I'm sure there are more) - you can decide which one to pursue depending on your expertise. As the Icon Editor in LV2016 (starting with LV2011 I think) is in packed library for execution optimizing purposes, the Icon Editor code can't directly be altered to fix this. One can come up with a solution where the command 'fc-list' is overridden in linux so it will always use the (proper for LabVIEW) format 'fc-list : family'. This may have some unwanted side effects if other programs use the command in similar fashion, so this may not be the best solution. It would be pretty easy to use for assessing whether this could be your problem also. There are multiple trivial ways of implementing this, so I won't be giving an exact solution - here is a list of them: https://lmgtfy.app/?q=override+command+in+linux Darren Nattinger has provided the source code for Enhanced Icon editor in https://forums.ni.com/t5/Enhanced-Icon-Editor/Icon-Editor-Source-Files-for-LabVIEW-2016/m-p/3538808 - You can replace the packed library LabVIEW uses as editor with this source. There are easy 3 step instructions on the site - even I managed to do that. Please give kudos to Darren should you go this way. When you have the shipped Icon Editor replaced with the source, you can directly edit the file in /usr/local/natinst/LabVIEW-2016/resource/plugins/NIIconEditor/Miscellaneous/Font/Linux.vi so it uses the correct form, like this:
    5 points
  5. 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 combined with a card like the 1473R, though it's falling behind without CoaXPress Units - yes no-one uses them , but they can extend strict programming to validation of correct algorithm implementation Parallel and multi-threaded programming - is there any language as simple for constructing parallel code? Not to mention natural array computations Real-time programming Data-flow - a coherent way of treating data as the main object of interest, fundamental, yet a near-unique programming paradigm with many advantages and all integrated into a single programming environment where all the compilation and optimization is handled under the hood (with almost enough ability to tweak that) Unfortunately NI appear to be backing away from many of these strengths, and other features have been vastly overtaken (image processing has hardly been developed in the last 10 years, GUI design got sidetracked into NXG unfortunately). But the combination of low-level control in a very high-level language seems far too powerful and useful to have no future at all.
    5 points
  6. 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
  7. Since Latin for six is "sex", we could have gone for "sexidecimal".
    4 points
  8. View File BlueSerialization Serialize and deserialize LabVIEW classes using either JSONtext or TOML Official documentation: https://github.com/justiceb/BlueSerialization Submitter bjustice Submitted 08/05/2021 Category General LabVIEW Version 2018 License Type BSD (Most common)  
    4 points
  9. Are Italian LV developers more prone to producing spaghetti code? 🤨
    4 points
  10. VISA is ok but not everyone uses it so...
    4 points
  11. Version 1.5.4

    956 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 Tools Network. JDP Science Tools group on NI.com. Copyright 2017 JDP Science Limited
    4 points
  12. 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
  13. 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 to make architectures that your less experienced developers can use and understand. If they can't use OOP, then your OOP architectures will not be effective. So should it be REQUIRED? No. Highly recommended? Absolutely.
    4 points
  14. We have noticed in the last few years that the outstanding support from NI technical support quickly detorated to the level of standard untrained technical support that call centers located in some low income countries often provide. However I have to say that this trend seems to have been reversed in recent times. I had three technical support questions in the course of about one year now, non was standard and included things that were simply not possible because the feature was officially not present. The support people were very helpful in trying to find workarounds and in two cases provided even solutions that were based on information that was gained directly from the product owners and developers to access the feature through direct behind the scene configuration files and APIs. In both cases with the strong warning that this was not the officially sanctioned way to do things and that there was a real chance that it may break in future versions, but that it was at the moment the best that could be done.
    3 points
  15. Try: apt install xfonts-75dpi xfonts-100dpi Then reboot.
    3 points
  16. "The software you are refactoring had one and it is too costly to change the training materials". How's that? It is likely that a great deal of pressure had to be applied to even allow a rewrite and the manager probably had a hard time arguing for a budget to do it. Getting hot under the collar over a button isn't a hill I would die on. I would concentrate of making my life easier supporting it going forward than what it looked like-which was decided a long time ago.
    3 points
  17. Shameless plug but feedback would be great since there's a lot that's changed. A few more eyes on it would help immensely before going live. The Encryption Compendium for LabVIEW (ECL) has had a major update. It's completed and a couple of weeks away from release as the documentation is in progress so there may be a few errors on that front. It's a commercial package so the gibs free crowd will, I hope, be disappointed. So what's new? IPv6 support (Thanks Rolf for your help with that). I've been wanting this for sooooo long but it required moving away from the NI primitives and nasty text programming. I bit the bullet and now have it, although a lot less hair SFTP Since NI released their poultry offering I thought I'd productionise the SFTP I had in my back pocket for quite a while and offer something actually useful. It comes with a full client example and supports recursive uploads, downloads and deletions (be careful with that last one). It also uses events for progress and status feedback in a similar fashion to the Websockets below. The event topology will be come a common feature of protocols in future additions. Websockets The ECL is a better home than a separate product since it was very difficult to distribute when trying to support TLS. Reworked from the ground, up it sits nicely in ECL and is the start of more encrypted protocol support in the future. Oh yes. Almost forgot. The ability to use Windows Certificate Store because ... why not? (and I wish I had thought of it ) If anyone would like to play before its release proper in a couple of weeks time, I can give you a trial copy (valid for 30 days). PM me and I'll send you a link.
    3 points
  18. I can say without any doubt that online clothing stuff is good quality or not.
    3 points
  19. I like resizable UIs, and that often means custom code to handle some of the operations in the UI. One such feature I like is a vertical array, that shows more rows, as the window size gets larger and can show more. I've used code like this a few times and figured the community might like it too. When doing this there are times when I want a user to be able to add more rows, and some times that it needs to either be static, or set by some other outside variable. So in this demo is also a way to link a vertical scrollbar that is a separate control, and have it move, and get set, so that it looks like it is linked to the array control. But this will coerce, and not allow more rows to be seen, than the number of elements in the array. At the moment this only supports 1D arrays, and only in the vertical direction. Code is saved in 2020. Array Resize and Scrollbar Link.zip
    3 points
  20. Or even better: Replace "Write To Text file"/"Read From Text File" with "Write To Binary File"/"Read From Binary File". The output of "Flatten to String" is not text. (String != Text)
    3 points
  21. Right-Click on the "Read From Text File" method and unselect "Convert EOL". The number "13" (0xD or Carriage Return) gives it away. If you look at the HEX representation of what you save and what you read from file, you'll notice the 0xD gets converted to 0xA unless you uncheck that box. Tip: If you deal exclusively with HEX/binary data, you might want to save it using byte arrays instead. The result will be the same in your file, but you won't get bitten by hidden config parameters in your node...
    3 points
  22. LabVIEW Software Engineers, here's your opportunity to work with us at SpaceX! I'm hiring for a Sr. Software Engineer on the Ground Software team. We build control and monitoring systems running the Falcon launchpads, mission systems launching astronauts to the International Space Station onboard Dragon, and a fleet of sea-faring recovery vessels bringing spacecraft and rockets back to shore. The screens you see in Mission Control are the UIs we build. Read more about the role and apply here: https://boards.greenhouse.io/spacex/jobs/5480997002?gh_jid=5480997002
    3 points
  23. There are many links on the Internet to tell you how to configure git to use custom tools for VI. Many are wrong. Yesterday, I and another developer outside NI worked through the sequence and got it working repeatably on both of our machines. Here is the process. Save both of the attached files someplace permanent on your hard drive that is outside of any particular git repo. We used C:\Users\<<username>>\AppData\Local\Programs\GIT\bin _LVCompareWrapper.sh_LVMergeWrapper.sh Modify your global git config file. It is saved at C:\Users\<<username>>\.gitconfig You need to add the following lines: [mergetool "sourcetree"] cmd = 'C:/Users/smercer/AppData/Local/Programs/GIT/bin/_LVMergeWrapper.sh' \"$BASE\" \"$LOCAL\" \"$REMOTE\" \"$MERGED\" trustExitCode = true [difftool "sourcetree"] cmd = 'C:/Users/smercer/AppData/Local/Programs/GIT/bin/_LVCompareWrapper.sh' \"$REMOTE\" \"$LOCAL\" [merge] tool = sourcetree [diff] tool = sourcetree That's it. There are lots of ways to edit the .gitconfig from the command line or by using SourceTree's UI... if you know those ways, go ahead and use them.
    3 points
  24. 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
  25. 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 for breaking bug fixes, then there is a testing, packaging and testing again cycle for the Beta Release, which typically takes a month or two alone, then the Beta phase of about 3 to 4 months and finally the release. So about 6 months before the projected release date, anything that is not considered ready for prime time is simply not included in the product, or sometimes hidden behind an undocumented ini file setting. Considering that, the expectation to see any significant NXG features in LabVIEW 2021 was simply blue eyed and irrational. I agree with you that LabVIEW is a unique programming environment that has some features that are simply unmatched by anything else. And there are areas where its age is clearly showing such as lack of proper Unicode support, and related to that the lack of support for long path names. Personally I feel like I could tackle the lower level part of full Unicode support in LabVIEW including full Unicode path support quite easily if I was part of the development team, but have to admit that the higher level integration into front panels and various interfaces is a very daunting task that I have no idea how I would solve it. Still, reworking the lower level string and path management in LabVIEW to fully support Unicode would be a first and fundamental step to allow the other task of making this available to the UI in a later stage. This low level manager can exist in LabVIEW even if the UI and higher level parts don't yet make use of it. The opposite is not possible. That is just one of many things that need some serious investment to make the whole LabVIEW platform again viable for further development into the future. This example also shows that some of the work needed to port NXG features back to LabVIEW require first some significant effort that will not immediately be visible in a new LabVIEW version. While such a change as described above is definitely possible to do within a few months, the whole task of making whole LabVIEW fully Unicode capable without breaking fundamental backwards compatibility, is definitely something that will take more than one LabVIEW version to eventually fully materialize. There are a few lower hanging fruits that can help prepare for that and should have been done years ago already but were discarded as "being already fixed in NXG" but the full functionality just for full Unicode support in LabVIEW is going to be a herculean task to pull off, without going the path of NXG to reinvent LabVIEW from scratch (which eventually proved to be an unreachable feat). My personal feelings about the future of LabVIEW are mixed. Not so much because LabVIEW couldn't have a future but because of the path NI as a company is heading. They have been changing over the last few years considerably, from an engineering driven to a management driven company. While in the past, engineers had some real say in what NI was going to do, nowadays it's mostly managers who see Excel charts, sale numbers and the stock market exchange as the main decision making thing for NI. Anything else has to be subordinated to the bigger picture of a guaranteed minimum yearly growth percentage and stock price. The traditional Test & Measurement market NI has served for much of its existence is not able to support those growth numbers anymore. So they are making heavy inroads into different markets and seem to consider the traditional T&M market by now just as a legacy rather than a significant contributor to their bottom line.
    3 points
  26. 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
  27. 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
  28. 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
  29. 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
  30. Shaddap-a you face!
    3 points
  31. 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
  32. 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). LabVIEW will probably stay what it is today and only receive (arguably exciting) new features that NI will leverage from the NXG codebase to drive their business. Unfortunately NI hasn't explained their long-term strategy (I'll assume for now that they are still debating on it). In particular what LabVIEW/G will be in the future. Will it be community-driven? Will it be a language that anyone can use to do anything? Will it be the means to drive hardware sales for NI and partners? Will it be a separate product altogether, independent of NI hardware and technology? There are also a lot of technology-related topics they need to address. Does LabVIEW Support Unicode? - National Instruments Comparing Two VIs in LabVIEW - National Instruments (ni.com) Error 1316 While Using .NET Methods in LabVIEW - National Instruments (ni.com) Using NULL Values or Pointers in LabVIEW - National Instruments (ni.com) Not to forget UX. The list is endless and entirely different for any one of us. If and when these will be addressed is unknown. Don't get me wrong, I'm very excited and enthusiastic about LabVIEW and what we can do with it. My applications are driven by technology that other programming languages simply can't compete with. Scalability is through the roof. Need to write some data to text file? Sure, no problem. Drive the next space rocket, land rover, turbine engine, etc.? Here is your VI. The clarity of code is exceptional (unless you favor spaghetti). The only problem I have with it is the fact that it is tied to a company that want's to drive hardware sales.
    3 points
  33. 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
  34. At one point I heard NXG called "Better LabVIEW" and someone else suggested the real name was "Beta LabVIEW". I've also heard of it called to as LabVIEW 20xx, or Current Gen (CG). I like Lab-deja-VIEW.
    2 points
  35. Fortunately Dataflow G have released this toolkit - dataflowg/g-audio: An audio library for LabVIEW. (github.com) It satisfies all the requirements 🤩!!!
    2 points
  36. I take it you don't have a dedicated connection between the two devices. Things that can break the system that come to mind is the routing and if there are duplicate IP addresses on the network.
    2 points
  37. And it will be the highest numbered icon to date.
    2 points
  38. I don't understand this website. They are pushing this whole "chat with other attendees", but there are no chatrooms? You have to search for someone by name?
    2 points
  39. https://meh.com/forum/topics/building-the-plane-on-the-way-up tl;dr the ground based decoder for some of the comms on Voyager was built *after* the craft was launched, and it still to this day reliably receives data. Wow!
    2 points
  40. Just saw Nintendo announce this programming game, and a few comments comparing it to LabVIEW. It looks pretty cool, and a fun intro to graphical programming. I don't have a Switch, otherwise I'd probably pick it up. https://www.nintendo.com/games/detail/game-builder-garage-switch/
    2 points
  41. I don't have these numbers. What I know is that a few years ago, NI noticed that their sales figures were starting to flatten. For a company used to have high two digit growth numbers year after year this is of course a very alarming signal. 😀 They hired some consultants who came to the conclusion that the traditional T&M market NI was operating in simply didn't have left much more air in it to continue to support the growth NI had been getting used to. And strategic decisions were made behind the scene. Not to much of that has been openly communicated yet, but the effects have been quite obvious in the past few years. NI has deprioritized the PC based test and measurement hardware, completely abandoned any motion ambitions, marginalized their vision ambitions and put much of the traditional DAQ hardware into legacy mode. And their whole sales organization has been completely revamped. No field sales offices anymore, highly centralized technical support by typical call center style semi-outsourced places. Behind the scene they do large scale business and have increased their sales further since that alarming consultancy report. So somehow it seems to work. One reason they may not have been very public about these changes is probably that it did change their old model of relying very heavily on external Alliance Members for actual application support of all their customers. In a few strategic industries they now have moved in to deliver full turn key systems themselves directly to the customer. For the typical Alliance Member that probably doesn't directly mean loss of business, since the customers and projects NI serves in this way are accounts that only very few Alliance Members would dare to even consider to look at, as the volume of the business transaction is simply very huge. However it certainly has other effects for all Alliance Members. The contact with NI has been getting very indirect with all the regional sales offices having vanished and the efforts from NI to compensate that with other means haven't gotten much further than marketing presentations with lots of nice talk up to this point. As to LabVIEW: It's demise has been promised since it was first presented. First because it was clearly just a toy that no engineer ever could take seriously, then because NI didn't push for an international standard to formalize the LabVIEW G language, later because they didn't want to open source it. I'm not sure any of these things would have made a significant difference in either the positive or negative direction. It's clear that LabVIEW is nowadays a small division inside NI that may or may not find enough funding by the powers to be, to maintain a steady development. If you look at the software track record of NI it doesn't look to well. They bought many companies and products such as HIQ, Lookout with Georgetown Systems, DasyLab, and quite a few more, and none of them really exists nowaday. Of course a lot of them such as DasyLab were in fact simply buying out competition and it was clear from the start that this product has not a very bright future in the NI stall. Lookout was marketed for quite some time, a lot of its technology integrated into LabVIEW (LabVIEW DSC was directly build on top of much of Lookouts low level technology and the basis for the low level protocols used in Shared Variables and similar things). LabWindows/CVI is lingering a semi-stasis existence for several years already. It's development can't quite keep pace with the main contenders in the market, GCC and Visual Studio. In view of this, acquisitions like Digilent and MCC may look a bit surprising. On the other hand it might be a path to something like a HP/Agilent/Keysight diversification. NI itself moves into the big turn key semiconductor testing business (and EV testing market), one of these other companies takes over the PC based LabVIEW, DAQ, and instrument control business.
    2 points
  42. Hi! I found this discussion while doing research on test automation framework. There is an open source project for test automation that I also found while researching called OpenTAP. It is an open-source test sequencer that is well document and has a pretty decent community. Its extendable and has a .NET core. There is another one called OpenHTF that was created by some Google engineers that is a Python test framework, but it has limited documentation. I don't know if this helps because I have limited software and testing knowledge, but this is what I've found.
    2 points
  43. @The Q started such a thing on the LabVIEW Wiki: https://labviewwiki.org/wiki/Text-Based_terminology
    2 points
  44. 2 points
  45. My intension for this template was to fill the gap between the Actor Framework and standard QMH. I never wanted to recreate the AF. When I first got a look at the AF I didn't get it. After a tutorial on youtube I got the understanding of AF but I feel somehow a distance I can't describe to the AF. It feels like AF is free floating in Hyperspace or so. Because of this I wanted to create a template with some benefits of OOP but more grounded and I started this template. And yes, AF is great way to get things done but in my opinion not very easy to understand. Thanks, Peter
    2 points
  46. 1. What type of source control software you are using? Git on GitLab with Git Fork or Git Tower 2. You love it, or hate it? LOVE it!! 3. Are you forced to use this source control because it's the method used in your company, but you would rather use something else We get to choose, and git is the scc system of our choice. 4. Pro's and Con's of the source control you are using? Pro: Decentralised, very popular (i.e. many teams use it), very flexible, very fast, feature branches, tagging, ... Con: Complicated to set up if using SSH, Exotic use cases/situations can be very hard to solve and sometimes need turning to the command line 5. Just how often does your source control software screw up and cause you major pain? Never. It's always me (or another user) doing something wrong. For our internal team of 5, it never happens. For our customers, the occasional problem occurs. As mentioned above, we use Git Fork and/or Git Tower as our graphical UIs to git. IMHO, using a graphical client is soo superior to working with git on the command line (but I'm posting to a LabVIEW forum, so who am I telling this?). In order to avoid having to merge VIs (we actually do not allow that in our internal way of working), we use the gitflow workflow. It helps us with planning who's working on which parts of an application (repo). I honestly can count the number of unexpected merge conflicts in the last few years with one hand. On top of git, many management systems like GitHub, GitLab, Bitbucket etc. offer lots of functionality like merge requests, integration with issue tracking, and other project-management-type features.
    2 points
  47. 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
  48. 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 it now), as discussed elsewhere, it looks like NI doesn't have the resources to bring the vision (whatever it was originally) to fruition, and their recent decision to abandon it will probably lead (or has already led) to morale cratering and talent effusion, so I wouldn't hold my breath... One thing I'd add to the list is this: stop the yearly versioning breaking backward compatibility. This is frankly moronic and the clear and only reason why this exists is NI pricing scheme. Adopt the scheme suggested in the first paragraph and this can go right away.
    2 points
  49. The future is Python for many of the applications, it is easy to get in to for newcomers to programming, works great has a strong package management system and large community, and can be applied to virtually any OS you can think of, as well as it can be even used to program GPUs if you are so inclined. The huge advantage of using G and LabVIEW is that paired with NI Hardware, in the hands of someone skilled with LV you can bang out a solid prototype of a product or a Test and Measurement system so fast it will make people's heads spin. NI hardware is absolutely top notch for High End use cases or rapid prototyping, complex one offs , scientific use or complicated Test and Measurement end of line test space. However in the IoT there is strong competition for the NI SB RIO line up, for a SB RIO you will pay 1500 US. There are so may cheap programmable & capable pieces of hardware, such as Jetson Nano (ARM7+NVidia GPU for vision) or Raspberry PI (ARM7 1.4 GHz with 8GB RAM) or even Asus Tinker Board ... which will serve so many purposes and have onboard GPIO and can be purchased for 50-60 bucks ... that in that space Python paired with Linux knowledge is really making headway. And if you want to go with ZynQ from Xlinix you can get a board with FPGA ~300 Bucks, which is basically the same HW as SB RIO, all you have to do is use different software tools. If NI would consider unlocking the ability use NI FPGA with the ability to deploy to non NI Hardware ... I think this is where G absolutely would take off like wildfire and be used on millions of IoT devices everywhere in the world that are powered by and ARM7 + FPGA module... but as it stands now if you use NI FPGA you must deploy on a target you've purchased from NI. I'll really be a stickler but if we're talking about the programming language we should talk of G. LabVIEW the IDE. Never say never, I am not aware of any other graphical programming language which could be used for general purpose programing and is as complete as G. If you have come across something interesting I would like to look at it, but I feel that it would be at best an academic project, which I would not use in production code.
    2 points
×
×
  • Create New...

Important Information

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