Jump to content


Popular Content

Showing content with the highest reputation since 06/13/2020 in Posts

  1. 7 points
    The core of our business has changed. Fewer users are developing their own test applications; instead, they're buying something off the shelf like TestStand. Fewer users are developing their own data acquisition software; instead, they're buying something off the shelf like FlexLogger. This trend alters significantly the role of LabVIEW (CG and NXG) in the NI ecosystem -- it becomes far less important to support whole application development (though, of course, we still do and will) and far more important to support "just a bit of customization" when the pre-built tools fail. A lot of software has an endless array of switches and options, but LV provides the ability for a user to write a custom routine to specify the behavior they want in some corner niche of a product. Think like Signal Express, able to generate sine wave, square wave, triangle wave or "pick a VI that generates the wave that you need" wave. What's funny about this is that although the app devs are growing rarer, they're also individually growing more profitable for NI as a whole because the companies still paying to develop custom software are the ones that are generally buying a lot of hardware to do something unique in the world (or not in the world, in the case of SpaceX, Blue Origin, Ad Astra, etc.). So I don't expect the big scale parts of LabVIEW to vanish, but I do expect them to be driven by specific requests from megascale customers rather than from the massed collective. The massed collective will be driving more of the IDE developments. At least, that's my suspicion at this time based on the presentations I've seen.
  2. 6 points
    Thanks AQ, you are the first to actually spell this out in words that make sense to engineers. Not sure too many here are going to like it though! ps: I liked your post due to its honesty and absence of marketing weasel words, not because I think this is a particularly good strategy for NI. Maybe I have just had a weird career but in the 20 years or so I have been developing LabVIEW based solutions virtually never would a custom off-the-shelf piece of software like Signal Express or similar come anywhere close to doing what I needed it to and it would require so much customisation that the benefit would be so low. To me LabVIEW is a programming language or RAD tool and the responsibility of NI is to deliver first class hardware with amazing software to help me bring the two together and that is it.
  3. 6 points
    I don't mind the new green on the landing page of ni.com, but elsewhere on the site the new theme is a bit too much. I wanted to fix the near invisible links that @LogMAN ran into, but got a bit carried away: If anyone is interested in using the blue style, you can download it from here. Be warned it's not perfect, there's still lots of green bits on mouse over etc, but I find overall it makes the site much more readable. If blue isn't your thing, the primary color can be changed by setting the root --forrest-green color to something else.
  4. 6 points
    The more I look at the center logo, the more I believe it captures exactly the kind of excitement generated by the whole operation.
  5. 5 points
    @Aristos Queue, I was part of the private preview event and afterwards there were several comments basically saying "I watched all of this and have no idea what NI is announcing". And multiple requests that NI make it clear what they are trying to announce. I thought maybe the public event would be more clear. Nope, dozens of comments were flying in asking what, if anything was changing as the event went on. After the event ended my favorite comment was "That was a great introduction, but when does the actual event start?". Threads on Reddit, LAVA, and NI all have had various amounts of "What does this mean?" other than a new logo and color scheme. After reading and listening to NI's feedback, only your post made it clear to me what NI was trying to say. So while NI marketing may think they are making it loud and clear, the community has also been pretty loud themselves with their statements that they aren't sure what NI was trying to say.
  6. 5 points
    The logo is pretty uninspired and looks lifted from this company. It's going to take some time to get used to the green theme too - in my mind NI = blue + white. I wonder if NXG will get a green coat of paint. I'll reserve judgement on the content until I've seen the webinar, but it's heavy with cringe worthy marketing speak. Also, a moment of silence for Nigel the NI eagle. Soar Ambitiouslyโ„ข, N ๐Ÿฆ…
  7. 4 points
    Hi Everyone, I was just alerted to this discussion (thanks @drjdpowell), so I wanted to be sure I heard all the feedback, to make sure we're staying on top it. Before I dive in, I'll mention there is a version 2020.1 in beta right now (if you can't access this, please be sure you sign up for the beta and/or send me a PM). This addresses many of the points raised here, so please check it out. Also, it's important to mention that VIPM 2020 had a LOT of work (and love) put into it, and the beta+launch was in the middle of COVID-19, so things didn't get as many eyes (i.e. beta testers) as usual. That's unfortunate and we're working hard on the new 2020.1 build. Any feedback/issues you have are important, so please do post them and know we're listening. It's hard to keep tabs on conversations that happen in various LAVA threads, so if you'd like to see something improved/resolved, please do post it in the VIPM forum or PM me. I'll try hard to respond to the good points everyone raised. First, I'll mention that VIPM 2020.1 no longer requires a sign in when installing packages from the VIPM Community Repository. In 2020.0, this was causing issues for some users due to their Enterprise IT/Networking configuration. And, as you've all mentioned, some users really didn't like it, which is fair. There are still some features that use sign-in, like starring packages, and there will be a prompt when those features are invoked. @LogMAN Actually, nothing changed with how VIPM installs itself 2020, as compared to 2019 (and older versions). The issue was that the the VIPM 2020.0 (and older) installer framework (e.g. Advanced Installer) needed to be updated for newer versions of Windows. In VIPM 2020.1 (now in beta -- see link above) we've addressed this issue and it should install without issues. That said, there were some bugs in NI's LabVIEW 2020 installer that causes it to fail to correctly install VIPM 2020, in some cases -- e.g. the issue where it sometimes would fail to start. NI has been working with JKI to fix this. @Neil Pate That's fair We added this feature to make VIPM much more responsive when users are opening packages -- VIPM sometimes runs as a background task, so that it doesn't have to reload itself for each of these operations. This can be disabled in the VIPM settings file, here: "C:\ProgramData\JKI\VIPM\Settings.ini" [General] Start VIPM when computer starts?="FALSE" Start VIPM when LabVIEW starts?="FALSE" @Michael Aivaliotis Thanks for helping everyone out. Older versions of VIPM are available to users -- we have a link on the vipm.io/download page for users. However, since older versions of VIPM use outdated LV runtime engines that are longer be supported by NI and don't work well on newer OS'es, we don't encourage users to use them -- it often creates more problems for them, and a support burden for JKI and NI. As such, we ask that people do not post older downloads and instead direct people to get them from either NI or the VIPM websites. Again, thanks for helping people out. Also, I appreciate everyone's feedback -- I know when things don't work well, it's super frustrating. VIPM 2020 had some bugs and left room for improvement, because of all the new features that had to get out the door in time for the LabVIEW 2020 launch date, and we didn't have the typical level of beta testing. I hope 2020.1 resolves those, and if it's still missing things or not working right, let me know and I'll take responsibility for those issues. Kind Regards, -Jim
  8. 4 points
    In an attempt to standardize my handling of formatting timestamps as text, I have added functions to "JDP Science Common Utilities" (a VI support package, on the Tools Network). This is used by SQLite Library (version just released) and JSONtext (next release), but they can also be used by themselves (LabVIEW 2013+). Follows RFC3339, and supports local-time offsets.
  9. 4 points
    I discussed with @Mark Balla and we figured out a way to get all the old videos that used to be on the Tecnova site up to Youtube. It will take a few days but this is in progress. Probably within a week all the videos should be up. I will update this thread with progress.
  10. 3 points
    This actually sums it up quite nicely ๐Ÿ˜‹
  11. 3 points
    https://youtu.be/4pDHBrBRILQ I've managed to get the runtime happy enough to run on the RockPi S, a 64bit quad core SBC that's a third the size of a Pi. The LabVIEW stuff is still 32bit of course but this opens the door for supporting even more devices. One of the tricks I pulled to get it to work is to first enable armhf (32bit packages) on the RockPi, manually edit the lvrt20-schroot package metadata to remove its dependencies on schroot and python since it was trying to install the 32 bit versions, and just manually install those packages before manually installing the edited lvrt20-schroot package. I also needed to install netbase for the labview service to start and I installed binutils to get the tools on the RockPi to unpack and repack the package. I'm looking to automate this process but I'm not sure how to do all the architecture specifications from the commandline. If anyone has insight on easy ways to accomplish this I'd love to hear them so I can extrapolate this to other devices as well (looking at the Banana Pi M2 Zero next). This assumes you've got the RockPi up and running and can access it already: ssh/console/shell into device >mkdir lvrt20-schroot >cd lvrt20-schroot >echo "deb [trusted=yes] http://feeds.labviewmakerhub.com/debian/ binary/" | sudo tee -a /etc/apt/sources.list >sudo apt-get update >apt-get download lvrt20-schroot:armhf >sudo apt-get install schroot python avahi-daemon netbase binutils nano >ar x lvrt20-schroot_20.0.0-4_armhf.deb >tar xzf control.tar.gz >nano control Remove the schroot, python entries from the Depends: line Ctrl+x to exit, Y to save, use same filename >tar --ignore-failed-read -cvzf control.tar.gz {post,pre}{inst,rm} md5sums control >ar rcs lvrt20-schroot.deb debian-binary control.tar.gz data.tar.gz >sudo dpkg --add-architecture armhf >sudo dpkg -i lvrt20-schroot.deb
  12. 3 points
    I think the longer my relationship with NI carries on, the more the message seems to be that I'm not considered part of the direction NI is concentrating on at all. In a way, the new announcement is a bit like "this isn't designed for you, do you hear us loud and clear?"
  13. 3 points
    It is growing on me too (with exceptions mentioned before). It actually feels refreshing in some sense, which is probably what they intended. It seems to me that they have totally forgotten about their existing customers. I actually haven't received any invitation, message or notification from NI about any of this (did anyone?). We are the ones that are most excited to use their products now and that doesn't seem to be worth anything. We are also the ones who are passionate about sharing our knowledge and excitement with the next generation of engineers. VIWeek, LAVA, LabVIEW Wiki, OpenG, the Idea Exchange and many more initiatives are prime examples of this. It is very easy for excitement to turn in to frustration if you don't know what is coming next. Don't get me wrong, I'm a strong supporter of NI, LabVIEW and anything that comes with it and I sincerely hope that I can continue to do so for the next decades. I'm just frustrated that so many exciting new things are "dumped" in a way that make me feel left out.
  14. 3 points
  15. 3 points
    Personally, I don't mind the logo, or the colour scheme. I prefer the old colours and logo, but no one likes change do they What I resented a little bit is that the webcast has been promoted for about a month, promising 'something extraordinary' In my opinion what was delivered wasn't extraordinary, it was 50 minutes of my life that I won't get back. It offered no value to NI's customers, brought no knew knowledge to the table and just felt like was repeatedly been hit in the face with a PR and marketing hammer. There isn't a problem promoting the amazing things people do with LabVIEW, but it doesn't need such a song and dance. I would have preferred to have seen an open discussion about this 100 year plan that NI mentioned, what areas they are going to focus on in the coming years, how they are planning the transition between current gen and NXG LV. A lot of our careers are pretty heavily tied to NI, we aren't impressed by marketing hot air, we just want to be efficiently kept in the loop regarding what NI is doing and how it is going to affect our companies. (I say 'we', that's my opinion, but I would be surprised if I was the only one who thought this)
  16. 3 points
    NI Week keynote. Pure marketing BS. Exactly what I expected from it.
  17. 3 points
  18. 2 points
    @pawhan11 yes this was done because the "data" said that more people create a constant, so it should be at the top of the menu. Truly wish NI would stop f*cking around with stuff like this and fix NXG. There are tokens to turn it off but I have not bothered and instead just learning to get used to it.
  19. 2 points
    I've seen that with clients I have been working for on LabVIEW related projects. A new software development manager came in with a clear dislike for LabVIEW as it is only a play toy. The project was canceled and completely rebuild based on a "real" PLC instead of a NI realtime controller. The result was a system that had a lot less possibilities and a rather big delay in shipping the product. Obviously I didn't work on that "new" project and don't quite know if it was ever installed at the customer site. That said, we as company are reevaluating our use of LabVIEW currently. We have no plans to abandon it anytime soon, but other options are certainly not excluded from being used whenever it makes sense and there have been more and more cases that would have been solved in the past in LabVIEW without even thinking twice, but are currently seriously looked at to be done in other development platforms. And I know that this trend has been even stronger at many other companies in the last 5 years or so. My personal feeling is that the amount of questions in general has dropped. The decline is less visible on the NI fora, but all the other alternative fora including LAVA, have seen a rather steep decline in activity. Much of the activity on the NI fora tends to be pretty basic beginner problems or installation pericles and pretty little advanced topics. It could be because all the important questions for more advanced topics already have been tackled but more likely it is because the people who traditionally use LabVIEW for advanced usage are very busy in their work and the others are dabbling their feet in it, come with their beginner problems to the NI fora and then move on to something else rather than developing to the intermediate and advanced level of LabVIEW use. Also with exception of a few notable people, participation of NI employees in the fora seems nowadays almost non-existent and except the aforementioned notable exceptions, many times if an NI empoyee eventually reacts after a thread has stayed unanswered from other fora members for several days, doesn't go very much beyond the standard questions of "What LabVIEW version are you using? Have you made sure the power plug is attached?" and other such pretty unhelpful things. This is especially painful when the post in question clearly states a problem that is not specific to a certain version and pretty well known to anyone who would even bother to start up just about any LabVIEW version and try the thing mentioned! It sometimes makes me want to tell that blue eagle (รคah is that a greenie now?) to just shut up.
  20. 2 points
    Thanks for the quick response @LogMAN No problem @LogMAN. I enjoy a good rant, as much as anyone ๐Ÿ˜› I try not to take it personally when it's about VIPM (even though it's been a labor of love for ~20 years), and honor everyone's good intentions to make their development tools better, contribute to the community, and get their work done as effectively as possible. Those are really good points about how to make the VIPM system tray service more configurable in terms of opt-in/-out. Honestly, we were/are trying to take a lean (MVP) approach and listen to people's feedback. That's also hard for developer tools, where people do want access to the whole Swiss Army knife of settings. So, we did our best to at expose those to users via config file settings. This discussion has been helpful, and I've gone ahead and posted an official KnowledgeBase entry to make sure people can find this easily, in case the high-level features don't provide enough granularity. VIPM KnowledgeBase: Disabling VIPM service (System Tray) startup when LabVIEW starts up Thanks again and keep the feedback coming! I'm glad to hear you're going to give VIPM 2020.1 a try.
  21. 2 points
    CINs have nothing to do with LabWindows CVI, aside of the fact that there was a possibility to create them in LabWindows CVI. They were the way of embedding external code in a LabVIEW VI, before LabVIEW got the Call library Node. They were based on the idea of code resources that every program on a Macintosch consisted of before Apple moved to Mac OS X. Basically any file on a Mac consisted of a data fork that contained whatever the developer decided to be the data and a resource fork that was the model after which the LabVIEW resource format was modelled. For the most part the LabVIEW resource format is almost a verbatim copy of the old Macintosh resource format. A Macintosh executable usually consisted of an almost empty data fork and a resource fork where all the compiled executable code objects where just one of many Apple defined resource types together with icons, images, (localized) string tables and custom resource types that could be anything else a developer could dream up. Usually with the exception for very well known resource types these files also contained resource descriptions (a sort type descriptor like what LabVIEW uses for its type system) as an extra resource type for all its used resource types. The idea of CINs was interesting but cumbersome to maintain as you had to use the special lvsbutil executable to put the CIN code resource into the VI file. And in my opinion they stopped short of creating a good system by only allowing one CIN code resource per CIN name. If they had instead allowed for multiple CINs to exist for a specifc name, one for each supported platform (m68k, mppc, mx86, sparc, wx86, wx64, vxwk, arm, etc) one could have created a VI that truely runs on every possible platform by putting all the necessary code resources in there. As it was, if you put a Mac 68k code resource into the VI it would be broken on a Mac PPC or on Windows system and if you put a Windows code resource in it it would be broken on the Mac. Also once the Call Library Node supported most possible datatypes, CINs basically lost every appeal unless you wanted to hide the actual code resource by obfuscating it inside the VI itself. And that was hardly an interesting feature, but was bought with lots of trouble from having to create seperate C code resources for every single CIN (shared libraries can contain hundreds of functions all neatly combined in one file) and also a maintenance nightmare if you wanted to support multiple platforms. As to the articles mentioned in the link from dadreamer, I resurrected them from the wayback engine a few years ago and you can find them on https://blog.kalbermatter.nl
  22. 2 points
    I tried VIPM2020. It was buggy for me. I also didn't like the new login "feature" and the notification taskbar malware. So I reverted to VIPM2019.
  23. 2 points
  24. 2 points
    It is uncommon enough to do the job -- truly unique is hard to do with the limits imposed on modern logos. Color: The folks who study this said that the blue was a color used all over the place in corporate logos; the green is much rarer. There's really only a handful of colors that are available for corporate logos: red and blue are the big dogs, then green/purple/orange. And black. Yellow doesn't have enough contrast -- as we constantly prove trying to put the LV logo on things, so it has to be boxed into stuff. Yes, you pick a shade of those colors, but your logo will be bucketed anyway -- Hulu, TechCrunch, and NI have very different greens, but it's all just "green" when evaluating uniqueness. What that means is, yeah, you can argue about particular shades, but it's hard to actually be unique, so it is all about finding a not-as-common color for your industry. Green works for NI. Symbol: The logo has to be renderable recognizably down to absurdly small sizes, which limits how many places you can put the logo before you end up with a smudge -- which happened to the blue eagle a lot. Something that is easily represented by vectors scales a lot better. The eagle was a distinctly USA symbol in some places -- sometimes a pro, sometimes a con. Or it was recognized as something else. The new logo isn't a representation of anything, so it doesn't accidentally pick up cultural baggage. Is it wild and unique? No. Generally, modern multinational logos cannot afford to be splashy like the old LabVIEW logo was -- too many colors limits where you can use it, and too many graphics limits its scale. But it'll be recognizable. That's the goal more than anything. And it represents a break from the past, and there was a fair amount in that presentation that was different than the Dr. T era. Most of it good, some of it aspirational. We'll see how it goes.
  25. 2 points
    What do you see beyond "package" and "manager" ?
  26. 2 points
    I would like to end the day with positive (and hopefully constructive) feedback, so here is a list of pros on the new design: All the old links still work Broken pages (that I knew of) are fixed The top navigation bar takes less space (148px to 97px), which gives a bit more space to the page content Mobile view works much better than before, at least for general navigation (most of the content didn't change as far as I can tell) All the text in header and footer is bigger than before, which makes it much more readable, especially on higher resolution and smaller screens (not zoomed) It "feels" slightly faster than before. Not sure if it's me imagining things, but the site seems more responsive than before (perhaps they improved on lazy loading?) This is certainly something I can get used to (not that I have a choice anyway). However, I strongly suggest to use a different color palette for content pages. Dark green links, different shades of gray, and black text are almost indistinguishable and look very dull. Please give me some eye candy ๐Ÿ˜ข Other than that, I'm quite okay with most of the changes.
  27. 2 points
    If they would make the product page usable again I wouldn't care one bit. It is absolutely miserable to find a c-series module for example. They did at least move the data sheet link to the pop-up but wow is that thing bloated and terrible.
  28. 2 points
    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...
  29. 1 point
    Which goes a long way towards explaining why it's necessary to use the CLI for so much. (And why there isn't actually a real official GUI to begin with.) I'm not saying you are wrong about the CLI being better for some tasks, but this message seems clear enough to me. That said, GitKraken does not seem to show any warnings at all when creating a detached head or navigating away from one. That's a bit disappointing.
  30. 1 point
    Here you go. This is not a production code. You will have to close references when you are done with a specific object. 2 things to note: 1. Excel, like VB is 1 based. 1st index is 1. 2. Don't leave an empty property node input. Wire a 'missing' type to any gray (optional) input that you don't use.
  31. 1 point
    GIT is that awful, in my opinion. I've screwed up many things years. I try not to use it as much as possible. The reason that GIT has taken over the SCC world is not because of its ease of comprehension or elegance of interface. It is because it is the only tool that can manage the full complexity of massive software teams, parallel releases, compression of features, etc, and the folks who use it daily just deal with it and get used to it.
  32. 1 point
    Quick update. I can send data from my cRIO to an Azure IoT hub, from there pass it to an Azure Streaming Analytics job which pumps the data into an Azure SQL DB and also to a Power BI Dashboard. The pieces of the puzzle are starting to fall into place ๐Ÿ™‚
  33. 1 point
    I do actually receive emails from LAVA.
  34. 1 point
    Is the 7-day trial for community edition or Base/Full/Pro? If it's for the later you can try just removing the license file from the usual license folder to see if it lapses into using the community edition license just fine. I don't know how exactly how the community edition is licensed but that type of thing happens a decent amount with volume license servers (LV complains about software that's about to expire but once it expires it just finds another license and is perfectly happy).
  35. 1 point
    Did you log in with your NI account after the install?
  36. 1 point
    Seems reasonable; added issue. https://bitbucket.org/drjdpowell/sqlite-labview/issues/6/add-a-execute-sql-1d-cluster-results Unfortunately, I've just released a new version, but it will go into next version.
  37. 1 point
    You might try loading macOS LV version into debugger, because it has more debug symbols unstripped unlike Windows and Linux versions. As I recall I was able to read out the rest of the parameters and their types just by browsing the code in IDA. It's mostly about old LV versions before LV 2009. Check LVSB and PLAT resource sections (and maybe LIsb for external subroutines), if you're going to study how CINs work. There are Rolf's articles also, that could help you to put all the pieces together: https://forums.ni.com/t5/LabVIEW/What-happened-to-CINs-And-how-else-can-another-language-work/m-p/2726539#M807177
  38. 1 point
  39. 1 point
    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 ๐Ÿ™
  40. 1 point
    I would say NI is becoming more and more software oriented. Just look at their latest acquisition (Optimal+). But all of the software I have seen are still geared toward hardware sales (FlexLogger to DAQ hardware, Instrument Studio to PXI instruments, InsightCM to cRIO, SystemLink to PXI test systems and cRIO, DAQExpress to DAQ, a lot of tools to the VST). And I don't see a spin off happening that would work well. All of the NI software tools are using a core stack now (reuse!). I saw evidence of this when I got a demo of VeriStand and it looked just like NXG (this was when NXG was still only in CABs). I don't think LabVIEW 20xx is attached in the same way. So I think there is an argument that LabVIEW 20xx could be spun off into an open-source project. But NXG is too ingrained into the MCP to be broken off without taking everything else with it.
  41. 1 point
  42. 1 point
    The worst, but really really rare case, would be for the tool to create damaged binary. But I'm doing a lot of checks to avoid that. And you already stumbled upon some of the checks: The tool does a lot of checks and raises exceptions if anything looks out of the ordinary. The exceptions are then captured and the block which raised them is exported as a binary file, without trying to make it XML. In case of VICD you'll actually always see this, as I didn't published parsing of the data. This means the VICD will just always stay as binary. If you want to be sure the data is identical to source, just go with: ./readRSRC.py -vv -x -i ./lv10/vi.lib/dex/DexPropertyNode.vi ./readRSRC.py -vv -c -m ./DexPropertyNode.xml cmp -l ./lv10/vi.lib/dex/DexPropertyNode.vi ./DexPropertyNode.vi In other words - export the file, then re-create the binary without changes, and compare both binaries. The tool checks whether it can re-create the checksum from your file - after all, it always tries to re-create identical data after export and import. Brute-force scan will happen only on damaged files - where the checksum doesn't match using the usual algorithm. The tool then assumes the issue is in salt. If the tool can't figure out how to re-create the salt used for password, it will export the salt into XML, and won't re-compute it when re-creating binary (unless you modify the XML to re-enable auto-computation). The tool will re-create everything correctly, if only you will modify it in exported form. I could add an option which would make it assume the input file is damaged, and skip that scan. Well, you could use the same code which handles "change password", only replace password work with your fun. But the way to rename blocks using my work model is: 1. Export VI to XML 2. Change the tag name in XML, for example replace "<CLIv>" and "</CLIv>" with "<LIvi>" and "</LIvi>". 3. Re-build the VI from XML Yes, block idents are just the tag names; they are only a bit modified to meet XML standard, ie. "#" are replaced by "sh" and "\0" codes are just skipped; but the tool will re-create the 4-char ident from tag name during import. I see. Yeah, there's no way around that.
  43. 1 point
    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.
  44. 1 point
  45. 1 point
    That server is not available anymore. To find the videos, you can visit the wiki: https://labviewwiki.org/wiki/NIWeek or Youtube: https://www.youtube.com/channel/UCUiBucUImKZERoTzaOtHB5g
  46. 1 point
    Well, they probably didn't find the slider for color and thus decided to fix it later (or their monitors have much higher contrast than mine). For now I have installed Stylish to fix my links. Imagine if this was the default ๐Ÿ˜Š
  47. 1 point
    You can edit that wiki if you have more info. or write your comments in "Discussion" page if you're unsure about editing it directly. I created a whole category of articles there: https://labviewwiki.org/wiki/Category:LabVIEW_internals
  48. 1 point
    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:
  49. 1 point
    Hello world, For ayone interested, here is a complete example how to create a .NET Remoting client with events in pure LabVIEW. No, it isn't impossible The key concepts are: - Extract assembly and object information from the .NET refnum. - Use .NET Reflection to connect event handlers and proxies. The documentation is inside the sample project. candidus HelloClientServer-LV2010-NET4.0.zip
  50. 1 point
    Maybe you'll get Xmas before you know it... I found a way to retrieve all tags from a VI. I basically scan the VI file and get an index to the position of tags in the file. I then extract the tag names. Since I don't know to which objects it is related, I have to scan all objects on FP and BD to associate them properly. Once done, you get a list of refnums and variants for the Object's references and a list of tags to which it is associated. I also included an example of code to write a tag to the Block Diagram. Use the same template to write to FP or any objects. Open the project and launch "Get All Tags from VI". Browse the path to the example file "Tagged Test VI" and that's it. Saved in 8.6 but will work in 9.0 (2009) as well. Note that the versioning is important as tags are seen only through scripting and NI can change the way it is saved from one version to the other. Retrieve Tags 8.6.zip

  • Create New...

Important Information

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