Jump to content

Leaderboard

Popular Content

Showing content with the highest reputation since 12/20/2021 in all areas

  1. What I do not understand about the decision to change it into a subscription model is the timing (and pricing). With the (predicted) failure of NXG, NI should lay low and try to save as many customers as possible from running off scared. Looking at the numbers and seeing how much money they threw at NXG it seems as if they think; well we need to cover that cost... What they should do is conclude that they need to seriously change (revert?) how they run their business (especially the LabVIEW development projects). The true cost of NXG will continue to rise by causing damage to their brand; unless they *simplify* ownership, *lower* the price, increase the work to recruit new (starting with students) and keep customers -AND invest the required amounts into developing a proper "NXG" (it is the foundation for the ecosystem that makes NI great, the cost of it has to be divided on the whole system, not just the SW itself). When that work is well on its way, and only then, they can think about subscriptions (the SSP solution is much more customer friendly though) and increased prices.
    6 points
  2. I think you're more of a sidekick.
    4 points
  3. I get what you are saying, and agree with some of your comparisons. I've seen on the forums a few times when an inexperience LabVIEW developer is like "I know nothing about programming but was able to make a spectrum analyzer using Express VIs." And half the replies will be from people like me saying "You're doing it wrong" and they will replay with "Well yeah maybe, but it sure got the job done without much work." That's sorta how I feel here. Your criticism of Network Steams are valid. And better solutions can be made. I'm just glad that I was able to make a synchronous network transport mechanism that uses VIMs, has status, automatic reconnection, and can target applications running on different platforms and different operating systems. All of this with no networking experience, and the amount of effort needed to make this was pretty minimal. I forgot to update this thread, but I did present this to the user group here, and uploaded the package to VIPM.IO here.
    4 points
  4. LabVIEW, as the Xerox GUI, needs a Steve Jobs... I was an Apple fan back in the 20 MB HDD days. It was only natural to fall in love with LabVIEW as well.🤩
    4 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. Unfortunately I do think there is a strategy behind this. In the past NI was a company centered around hardware sales in the form of computer plugin cards. The fact that they were a lot better in providing good and well designed supporting software for that hardware was for years a distinguishing factor that made them grow while the competition had a hard catch up game to do and eventually all more or less faltered. The software in itself never really was the money maker, much of it even was given away free with the hardware and was considered a supporting expenditure that was financed with part of the profit for the hardware. When they had pretty much the whole market of what they possibly could get, they run into the problem that there was very little grow in this market anymore for them. So they set out to find new markets and moved towards turn key semiconductor testers that they could sell a dozen a time to the big semiconductor manufacturers for big money. Suddenly those pesky DAQ cards and DAQ boxes were just a margin anymore and they were at best a supporting technology, but the accompanying software was getting more an more a costly burden rather than a supporting technology. Nowadays there isn't one NI marketing but each division has pretty much its own marketing department and is also its independent profit center. And then an independent software/LabVIEW division suddenly shows mainly as a post in the cost category that doesn't bring in as much as it costs. So they try to increase the income but I think they missed that train already 15 years ago when they were refusing to consider other venues for LabVIEW. Nowadays the LabVIEW community is a marginalized small group of enthusiast who are looked at by the rest of the industry as a bunch of crazies who can't let go of their pet IDE and the rest of the world has moved on to Python and .Net and will move on to another hype in a few years. And the higher NI management is likely aware of that. While I do believe that the LabVIEW developers and the managers who directly work there really would like to make LabVIEW a good and flourishing product, I feel the higher management has already decided that this is going to be a dead end and have very little intentions to do anything else than let it bleed to death, so they can get rid of that liability.
    2 points
  7. I can amortize 20,000$ one time license costs, I can't amortize 500$/ month subscription. Python seems more attractive every day.
    2 points
  8. 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
  9. Okay here is a quick first update to the Write VIM that has special code if you are writing an analog waveform, or an array of analog waveforms. It will write the waveform properties and then flush the file, then write the 1D array of doubles for a scalar, or a 2D array for a 1D array of waveforms. On the next write it will see the property for the waveform exists, and not write it again, but the dT between the write must match. If it doesn't it generates an error. This is still using just the normal TDMS write. So if you are having memory issues, this doesn't use the advanced stuff, and might not fix it. Partially because don't have experience with advanced TDMS stuff, and also because I don't fully understand the original issue. Write Tremendous TDMS - Waveform.vimSet Waveform Properties.vi Also I noticed that there is a disabled structure that has a partially implemented cluster write. I should probably finish and test that.
    1 point
  10. Never meet your heroes. Unless it's me and you're planning on buying me a Texas Tea at the piano bar. In that case you should definitely meet your heroes.
    1 point
  11. Yes, it is probably the windows clipboard that does the string sanitizing. Strangely, from Notepadd++ to LV2020, I get a space instead of \00.
    1 point
  12. But it existed since around LabVIEW 6.1. You had to add a funkyErrorWire=True or something similar into LabVIEW.ini
    1 point
  13. Yep, LabVIEW 8.20. https://labviewwiki.org/wiki/Cluster_data_type
    1 point
  14. Around there, if I had to guess I'd say 8.0 or 8.20.
    1 point
  15. Okay I may have a solution, but I don't know if it will work in your use case or not. If you wire a cluster to an Add, it will work if all elements in the cluster support the Add function individually. So you could have a VIM that has a Type Specialized structure, and perform a type cast if all elements in the cluster support the Add. Oddly enough in my test I used a Timestamp Constant, and that makes a pink wire, but supports the Add, and is a fixed size. But I'm not sure I understand what you want done into the byte array. If you are just trying to get a byte representation of a cluster, and you want to use a fixed string for those cluster elements, it probably would just be best to iterate over element in the cluster with while loop recursion. What I think you what can still be done with a VIM, using the Type Cast in one type specialized case, and then if that fails, then to iterate over all elements.
    1 point
  16. Thanks for a great tool. One comment though. In the Initialize Periodic TDMS File the timing input should be labeled New File Period [s] and not New File Frequency. Frequency is a measure of the number of events per time period, like [1/s]. Thanks for considering this - albeit tiny but never the less incoherent detail.
    1 point
  17. I think the biggest problem with the subscription model is that it does not set incentives correctly for NI. In the olden days, a company had to actually improve their software and innovate in order to get paid more money every year. Now, with the subscription model, all they have to do is "lock someone in" to their platform, and they get paid forever. Why continue to add new features to your software every year? Your suc......err....customers.... HAVE to pay you. Even if you don't continue to improve the software. In this new model, what financial incentive does NI now have to continue improving LabVIEW? It seems to me like they only need to just enough to keep existing users from leaving. That's not exactly innovative stuff. You know what it leads to? Flat revenue for the product line. You know what Wall Street hates?
    1 point
  18. Maybe I misunderstood, and what you posted is just an example. Anyway, that example shows that the different calculations and sub Vis are run serially, because of data dependency, so I would "streamline" the VIs and use "in place element" structures if possible (and of course for loops with auto-indexing/deindexing). In your example there would be no large data copies at all: "Calc DZPV" (modified so data in passes through) then "Cal S and wa" (modified so data in passes through) then "in place element" structure to index the data, and inside the structure anotheer "in place element" structure to adress the cluster elements you want to change. If the subVIs can be inlined theres no data copy of the whole data in array. Maybe you don't even have to inline the subVIs because the optimizer can optimize away the data copies when passing data to the subVIs, I have no knowledge about these stuff.
    1 point
  19. I've met Eric and Omid. I can't vouch for their intentions, or background. I can say they were friendly energetic guys and on the surface seemed to have good intentions for NI as a whole. Didn't know Eric was worth $14 Million. Also didn't know Jeff K. is worth $112 Million. Anecdotally I've always thought that those at the very bottom, and very top of an organization generally do good things for the company. I've generally seen the corruption, cheating, stealing, and short sited poor decision making happen at the middle management level.
    1 point
  20. The VIs are in <vi.lib>/Utiity/importsl/
    1 point
  21. LabVIEW.exe has a public moveblock method that you can call. I find it is better to call it directly than inside those subvis enserge shows.
    1 point
  22. No! What LabVIEW passes to the DLL in this case is the lower 32-bit of the 64-bit. LabVIEW does not know variable sized numerics for a number of reason. So a pointer sized integer parameter in the Call Library Node is ALWAYS transported as 64-bit integer in LabVIEW. That is totally independent on the OS and LabVIEW bitness. The Call Library Node will generate the necessary code to pass the right part of the 64-bit integer to the actual parameter. But on the LabVIEW diagram (and front panel controls) it is ALWAYS a 64-bit integer.
    1 point
  23. I've setup a number of labs, including the test automation. In my previous couple labs I based the automation on LabVIEW. I enjoy programming in LabVIEW and have become quite proficient at it. Unfortunately, my junior engineers and design engineers can't seem to get used to it. The only reason they used it is because I forced them to. I am going to start a new lab, and I was researching if I should use LabVIEW or... something else. That's when I found out NI has gone to subscription only. My company probably doesn't mind, but I do. It is a sign that LabVIEW is on its way out and that NI has gone completely to the dark side. I can program in Python, but I don't really want to go to Python for the reasons that have already been mentioned by others in this thread. So, plan "B". But there is no plan "B", which is very unfortunate. I know what I want my automation software to do and look like, but it does not exist. I'm not sure I'm up to the task of making my own, so I guess I'm stuck with going to Python, unless NI suddenly changes course.
    1 point
  24. That's about right. I mentioned the 10 year catch-up game NI has to do with LabVIEW. The full 64-bit compiler support in LabVIEW 2009 was one of the last architectural projects NI did with LabVIEW Classic. After that they did not really do much more than add some peripheral libraries, fix bugs and make minor improvements to core functionality of the LabVIEW kernel. Anything that was structurally touching the LabVIEW core code base was deferred to LabVIEW NXG. Even the Map and Set datatype in LabVIEW 2019, while a great addition, was for the most part a completely separate code base that had literally no impact on the LabVIEW kernel in terms of needing any significant changes to it. The problem NI had/has with much of the LabVIEW code base is that some of the most fundamental code modules come from a time about 30 years ago, when C++ was simply not an option at all, NI had to fight with symbol tables in the C compiler exceeding the compiler provided memory space and 8 MB of RAM in a computer was for many users considered an unacceptable minimum hardware requirement. This code is inherently C syntax, and littered with global variables that all had to be protected with mutexes when introducing multithreading in LabVIEW 5. LabVIEW NXG was about getting rid of that entirely by replacing the entire UI system with something more modern. In hindsight I think it was overambitious and NI underestimated the impedance mismatch between the .Net environment and the LabVIEW system and didn't anticipate the vocal push back from non Windows users about the fact that LabVIEW on top of .Net was likely never going to support anything other than Windows, despite their repeated claims that it COULD be made to work on other platforms. But COULD in lawyer speak usually means WON'T and a lot of those non-Windows users are academics who know a thing or two about language semantics too.
    1 point
  25. Speaking about plan "B", I hope that NI will change their decision and will provide perpetual licenses again. Subscription is a way for big industrial companies, but for individuals, small companies and start-ups it isn't an option. Labview was invented as tool for engineers which helps do their job, not just another tool for marketing stuff, it would be nice keep it in mind.
    1 point
  26. What ensegre is getting at is that LabVIEW has never (officially) supported unicode and at one point NI said they don't need to (in classic) because NXG supports it. There are some UTF8 primitives that means you can support UTF8 internally but many of the controls and primitives don't support it (like the file control and functions). For that you have to have replacement windows file functions but that will not help you loading projects and is not cross-platform.
    1 point
  27. It has that feel to it but it is far more powerful. CodeTyphon is really a fork of Lazarus but with all components already packaged. That makes it a bit daunting to begin with as there are multiple components to choose from that are very similar - but not quite - since they are from different tool-sets to do the same things. Just get it installed and have a look through the (hundreds?) of examples (Under Tools>>CodeOcean Examples). The big boon of it though is that the IDE runs on most Desktops and from there it can compile native code for hundreds of targets. At that point you are way down the rabbit hole from the forms editor, though. Another plus is that it can use Lazarus and Delphi components. So if you have 3 different sources of projects and components you can leverage.
    1 point
  28. while Microsoft managed C# and .Net in a better way than NI did with LabVIEW, I'm still not quite sure if I should sell my soul to them! 🙂
    1 point
  29. NI might know something about the value of the Canadian dollars that you may want to know...
    1 point
  30. For the HQ GUI side, use a browser and Javascript. You don't need a web server. You don't really need a web server on the device side either but it's useful to have a HTTP webserver to get a web page as a starting point and to configure things. Note that having a webserver is a security risk so if you are new to all this, I wouldn't suggest you have one on the devices in production but it will help you developing. You will need a Web server on the HQ side if you are doing database stuff but I'd suggest you talk to IT to get provisioning which will probably be an Apache Server-which they will maintain.
    1 point
  31. NI is shooting themselves in the foot with this approach. It is already difficult enough to find LabVIEW programmers. The IDE seems straight out of 2002, proprietary file formats, hard time integrating with version control and CI flows, Do they really want to drive away their potential customers? I use LV for many things, but I avoid the pay to deploy tools (IMAQ, Teststand). If I have to pay upkeep to NI, I'll recommend Python, the 3rd party hardware support is similar with pyVISA. No upkeep, no licenses, no deployment fees.
    1 point
  32. As Francois noted, no, you cannot prevent it. The default instances are useful in many sentinel and error handling situations -- think like NaN in floating point. The defaults can also serve a role similar to "null" but without all the dangers of open references. Details about design decisions of interfaces can be found here.
    1 point
  33. The restriction on DVRs is the same for interfaces as for classes: it allows for constructor/destructor notation for by-reference entities. Please don't go hyper excited and think "Oh, this is the tool I should have been using all along." By-reference designs are fragile and prone to several classes of errors that by-value code cannot create. Stick to the wires where possible; use references only when nothing else serves! 🙂 Details here.
    1 point
  34. Get the desired PropertyItem from the Properties[] property of the Property Node reference. Then you can set the isWrite property as desired.
    1 point
  35. What was the answer here? I'm trying to figure out the same exact thing.
    1 point
  36. Having the Status visuals as a tick or a cross but represented by a boolean. After 17 years of LabVIEW development I still make mistakes when using the error Status boolean and forget that a True means "Error Present".
    1 point
  37. Version 2.7.1.1

    4,486 downloads

    Mark Balla Icon editor V2.7 December 2020 Author: Mark Balla Description: This is a text based vi icon editor The purpose is to help quickly create text base icons. The editor can be used in place of the standard NI icon editor or as a stand alone vi. see instructions. Version 2.7 Updated font table to recognize the standard "Small Font" letters used by the NI icon editor. This will improve the OCR function when importing icons generated by the NI Icon editor. Version 2.6 Added quick drop code to allow the user to switch between NI and custom editor. QD_Swap Icon Editor.vi and support folders will be placed in the LabVIEW quick drop folder ..\National Instruments\LabVIEW 20XX\resource\dialog\QuickDrop To switch LabVIEW to a custom icon editor that uses the lv_icon.vi set a shortcut key to call the QD_Swap Icon Editor.vi. Ctrl-Space Ctrl-<<assigned letter key>> To switch LabVIEW to the NI icon editor that uses the lv_icon.lvlibp use the same shortcut key with the Shift key Ctrl-Space Ctrl-Shift-<<assigned letter key>> Version 2.5 Fixed install bug where lv_icon.lvlibp was not being renamed after LV 2016 2.5 was set to 2017 or later. Instructions: LV 2017 to LV2020 + Ver 2.7 + Here is the intended process. Download package from LAVA Install Package Package will install MB icon editor files Package will install QD_Swap Icon Editor.vi in the QD plugins folder Package will copy the lv_icon.lvlibp And rename it to COPY_ lv_icon.lvlibp Package will delete the lv_icon.lvlibp Popup will show stating you are using the custom editor. Open LV Open QD, click configure and select the Ctrl-Key Shortcut Tab at the top Assign a control key to the QD_Swap Icon Editor and click OKWhen you select Ctrl-Space Ctr-<<Assigned Key>> the QD vi will setup the IDE to use my custom editor. The vi will verify there is a copy of the lv_icon.lvlibp And if not create it. The vi will delete the lv_icon.lvlibp From the ..\National Instruments\LabVIEW 20XX\resource\plugins folder When you select Ctrl-Space Ctr-Shift-<<Assigned Key>> the QD vi will setup the IDE to use the NI editor. The vi will copy the COPY_lv_icon.lvlibp and rename the copy to lv_icon.lvlibp LabVIEW will use the lv_icon.lvlibp If it sees it in the plugins folder. If it does not see the lv_icon.lvlibp It will call the lv_icon.vi which is the name of my icon editor. LV 2010 to LV 2016 Ver 2.4 Install using JKI VI Package Manager LV 2009 Ver 2.3 1:Rename the curret LabVIEW 2009 Icon editor LabVIEW 2009\resource\plugins\lv_Icon.vi to a different name so it will not be overwritten. 2: Place the three files (lv_icon.vi, color templates.bin and the folder lv_icon_Subvis) in the LabVIEW 2009\resource\plugins directory. The next time the icon editor is called LabVIEW will use the lv_icon.vi instead of the standard one. There is a button on the editor that will allow you to use NI's editor (Old editor not the new one) when a text icon is not desired. For LabVIEW 8.2 Use the "MB Icon Editor_V2.3_LV82.zip" file For LabVIEW 8.5 Use the "MB Icon Editor_V2.3_LV85.zip" file For LabVIEW 8.6 Use The "MB Icon Editor_V2.3_LV8.6.zip" file
    1 point
  38. Well. Aren't we a ray of sunshine nowadays
    1 point
  39. 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
  40. Just curious, what is the advantage of the MQTT implementation over off the shelf RTI-DDS now built into LabVIEW for windows and RT Linux
    1 point
  41. Version 1.0.0

    776 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
    1 point
  42. There is also the Data Queue VI in the PtByPt palettes. Personally, I found a fixed sized lossy queue to work very well as a circular buffer.
    1 point
×
×
  • Create New...

Important Information

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