Jump to content

Mads

Members
  • Content Count

    331
  • Joined

  • Last visited

  • Days Won

    19

Mads last won the day on June 26

Mads had the most liked content!

Community Reputation

55

About Mads

  • Rank
    Extremely Active
  • Birthday 12/01/1975

Profile Information

  • Gender
    Male
  • Location
    Bergen, Norway
  • Interests
    Trail running, skiing, science fiction, food and travel.

LabVIEW Information

  • Version
    LabVIEW 2018
  • Since
    1997

Contact Methods

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. Slightly related topic: I wonder what the trend looks like for the share of questions in the NI discussion forums marked as resolved. Based on my own posts there, it seems to get harder to find a solution to the issues I run into. I am not sure if that is just because the things I do in LabVIEW are closer to the borders of regular use / getting quirkier though, or if it is a sign of declining quality in the products involved. I suspect it is a mix of both. It would be cool if such statistics were readily available. A trend of the posting rate per forum/tag for example could reveal shifts in the interests of the users (the mentioned shift towards configurable turnkey solutions vs general application development for example) and/or the quality of the product. The latter might partially be possible to separate from the former by looking at the mentioned share of resolved issues; adjusted for the number of years of experience the questionnaires had (which perhaps could be inferred by how long they have been registered at ni.com and/or the number of posts or solutions made by that user...).
  2. Sure, that's basic (always dangerous to say though, in case I have overlooked something else silly after all, it happens πŸ˜‰). The lvlib and its content is set to always be included, and the destination is set (on source file settings) to the executable. The same goes for the general dependencies-group. The dynamically called caller of some of the lvlib functions on the other hand is destined to a subdirectory outside the executable, and ends up there as it should. But then so does lots of the lvlib-stuff - seemingly disregarding that is destination is explicitly set to be the executable. Correcting other usual suspects (read: additional exclusions) do not produce a repeatable solution either. Perhaps someone else here have observed similar voodoo though, and figured it out?
  3. I happen to have some JKI JSON calls, among other things, in a dynamically called plugin, and it seems that whatever I do in the application build specification to try to get all those support functions (members of lvlibs) included in the executable, the build insists on putting the support functions as separate files together with the plugin (the plugin is here a VI included in the same build, destined to be in a separate plugins folder). (Sometimes I wonder if there is a race condition in the builder; what does it do for example if there are two plugins include din the build that will call the same VI, and the destination is set to Same as caller ..πŸ€”That's not the case just now though, right now the only caller is one dynamically called external VI..) In an ideal world I think I would create a destination for the lvlibs that plugins are to use in a single external support container-file like an llb...In the case of this JSON library though there are classes involved to, so an llb does not work (name collisions etc). Packed libraries are too cumbersome to use I think, for various reasons (having to support multiple targets for example). So as a second best solution I want everything (all lvlibs that plugins may need something for) packed into the executable (works as a single file container, and supports classes as long as it is not using the 8.x file format...), but then the application build seems to behave very unpredictably. At first I would expect that if I included the lvlib on the always included list, and then set the destination of the lvlib to the executable I would be fine, but no. - Suspecting that this only applies to the lvlib-container file itself and not the VIs it owns, I then also set the destination for all dependencies and packed and shared libraries to the executable...- Still the builder puts lvlib-VIs together with the plugin. I have tried this with and without excluding unused members of the library with/without modification...and with and without disconnecting type definitions. In the end I returned to the original build setup (as this was noticed after a conversion from 2018 to 2020), tried a build, got a Bad-VI error on a couple of VIs used by an xcontrol, set those to include the block diagram...and voila - magically this affected where the JSON lvlib ended up as well, even though they have no links in the code. This problem keeps popping up though, and once it is there it seems like getting the lvlib-files to the wanted destination always includes some voodoo...😧 Or does it?
  4. Sounds like a philosophy not exactly aligned with using LabVIEW... I found it now though, it is called the GPM Browser. Re-reading the documentation I noticed a sentence about it that I had overlooked. It is not marketed much though no, you have to RTFM πŸ™
  5. One useful tip when troubleshooting VIPM is that there is an error log in %programdata%\JKI\VIPM\error When you first ran it, did you get the user logon dialog? I had that but was unable to logon, and when I then chose to continue without a logon it never showed any windows...I ended up uninstalling it, deleting the JKI/VIPM folder in ProgramData, and then reinstalling it - and this time I chose to register a new account, and got it to work. That was at home though, at work I ended up with additional issues because the firewall would not accept the certificates of the server used by VIPM. I just noticed now that Jim Kring announced a fix for this on the discussion forum here: https://forums.jki.net/forum/5-vi-package-manager-vipm/ , but unfortunately that is not out yet...
  6. Sure, the focus of NI has always been on hardware sales, and that has directed where much of the development effort in LabVIEW goes, and how it is marketed. I often think that in this respect the customers of NI show more respect to the power of LabVIEW/G than NI does. There is an underlying uncertainty in the use of LabVIEW due to this - and the growth of LabVIEW and G as a programming language is perhaps limited by it. It goes both ways though; the hardware sales has also supported the continued development of LabVIEW - and LabVIEW draws strength from the ecosystem it is part of. I would not be surprised if NI now (wrongly) thinks that they do not need LabVIEW to make their hardware unique (spending so much time and money on NXG might make it all look like waste...). I hope I am dead wrong though, and that they consider themselves just as much a software company ("the software is the instrument" after all!). If not, I hope they at least spin off a separate company soon enough that will. The latter would be riskier for the future of LabVIEW/G than the former (having to establish a different sustainable business model), but might also leave us developers with a higher reward. Especially if the alternative is a dwindling LabVIEW / NXG that is geared towards configuration only.
  7. Having lots of connection issues with VIPM (turned out to be an issue with the JKI server certificate I found out on my own...), I just had a relook at G Package Manager... Is it seriously based on people having to use the command line to install packages?πŸ€¦β€β™‚οΈ The main selling point of LabVIEW is that it is *graphical*....and it is trying to force everyone to use the command line?? At least then integrate it into Windows Explorer so that I can right-click my project folder and choose packages to install then and there. O rhave a graphical browser that displays the pacakges, and let me choose a bunch of them there and then point them to the project directory for one batch install. Installing one package at the time is terrible - it would mean that I would need to install 10-20 packages in every project. If so, make it possible to make package groups at least, so that we can install a bunch of the usual suspects with one click. *Ideally* you would have the packages installed in your user.lib or somewhere else centralized instead, and then if you use anything from any of the packages, they are automatically copied into the project...(yes, this is one of the few places where NXG might be on the right track...).
  8. The idea that customization is enough seems like a variant of the 80-20 fallacy...πŸ€¦β€β™‚οΈ To me LabVIEW is the thing that makes NI unique. It is their greatest product. It happens to also sell hardware because of the limitless possibilities introduced by the concept of virtual instrumentation. The RIO concept strengthens that package, and is why most of the hardware we buy from NI are sbRIOs and cRIOs. Without LabVIEW and RIO we would choose cheaper hardware options. (The hardware ties might unfortunately be one of the things that prevents LabVIEW from becoming all it could and deserves to be though; the graphical champion of all kinds of programming. )
  9. But that is why I do care, because the success of NI is important to us all. Everyone who has invested in their ecosystem is hurt if NI fails.
  10. When it comes to color it is generally a mistake to be "unique". Most cars (and clothes, and houses and...) are one of 4-5 colors. They have their specific effects on the human mind, and you cannot avoid them if you need that effect - which NI does. If you want to project a sustainable image and sell - you need those colors, no matter how many other companies use the same. When it comes to shades most are unusable as they come off as drab, muddy or garish. You can choose a light and "fresh" shade, but move a little too much and you step into the ugly. Choosing green is generally risky, although there are some fresh tones that work in some amounts (like in the logo in this case). The darker greens, used on much of the NI web site, is off that cliff though. I think a majority of the population will tell you that for free. And the screen resolution requirements of the layout sucks on PCs, which is what people shopping for or working on NI related things will use most of the time. The designers have gotten their priorities wrong there. As for the logo, that's totally fine, for many of the reasons you mention. The package manager logo though...🀣
  11. If I have to say one positive thing about the new look, it's that the color palette is probably very very rare....
  12. My train of thoughts about it: Do I have a browser or display issue.... Someone must have hacked the site and messed it up really good - yuck... Wow, they are serious....this is even worse than NXG, someone should turn the ship... Is this an attempt to be appear more "green"? What screen resolution do they think people have? I have to double mine to read this properly... I wonder how this looks like for people who are color blind...(let me try on https://www.toptal.com/designers/colorfilter, nah the welcome dialog blocks that...) This is making me depressed, let me close this thing...
  13. Port 8883 is usually used for TLS (1883 for non-TLS). There are a couple of examples of how to use TLS in 2020, if you search for TLS in the examples finder:
  14. I have successfully used (unsecure) MQTT for LabVIEW, I have not tried it with the Azure IoT broker though. With this LabVIEW implementation for example: https://github.com/cowen71/mqtt-LabVIEW. The connection settings just had to be reconfigured slightly to get the link up and running. Here is a setup that works to connect to adafruit.io....you just need to change the user account and feed name of course, and the password (intentionally cropped out here): You may also need to open the firewall...In my case it allowed the connection, but blocked everything afterwards (producing error 66). I have not been able to use TLS with any of LabVIEW implementations though, but perhaps that can be remedied more easily now that TLS is supported in LabVIEW 2020...
×
×
  • Create New...

Important Information

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