Jump to content

Leaderboard


Popular Content

Showing content with the highest reputation since 06/04/2020 in all areas

  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
    The more I look at the center logo, the more I believe it captures exactly the kind of excitement generated by the whole operation.
  4. 5 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.
  5. 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 πŸ¦…
  6. 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
  7. 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.
  8. 4 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.
  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. 4 points
    Hi all, friendly LAVA moderator here. I'd just like to gently remind everyone we are all human, and are at times emotional, and at times frustrated with colleges we interact with. Lets all take a deep breath and try to continue to give criticism in a form that will be most helpful. I know I've at times flown off the handle online, especially on the subject of NXG. I personally don't think I've shared code between projects for anything real project anytime recently. But I can remember times that I did it and didn't have any real problem. Likely because I was mindful of what effected what. X do you have some recent examples of code you shared between projects? What made you make that decision, and why were the other options seen as less desirable? Also it sounds like this isn't explicitly forbidden in NXG.
  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
    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
  19. 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.
  20. 2 points
  21. 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.
  22. 2 points
    What do you see beyond "package" and "manager" ?
  23. 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.
  24. 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.
  25. 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...
  26. 2 points
  27. 1 point
    I've seen this behaviour many times. We use OOP and lvlibs heavily in our projects and unfortunately often run into those builder quirks. The fun fact is that sometimes the same project built on different machines produces different outcomes (on one it always breaks, while on other it always succeed, while on third it's 50-50 chance). I never really bothered to investigate and report this to NI as those problems are very non-reproducible. Going to your specific question aboutt VIs which end up outside exe (in no particular order) : 1. Check the dependencies between libraries. The builder hates circular dependencies between them (i.e. something in lib A depends on something in lib B and vice versa). Avoid them - usually the solution is to move the offending VIs between those libraries. You'll also end up with better code design, so double the profit. 2. Enable builder log generation (I think it's in Advanced settings) and see if you can make any sense of what it puts out regarding those "outside" VIs. 3. Try building on different machine. 4. Set "Enable debugging" for the build (also in Advanced settings I think). 5. Try to recreate the problematic VIs under new names - create the blank VI, copy the contents (block diagram) of the current VI, replace the calls. Do not simply rename the current VI and do not Save as..., both of those might retain some hidden problems inside the VI. Also,try to change reentrancy settings and try to make them inline. 6. Try to recreate callers of those problematic VIs in the same manner as above. 7. Separate compiled code from the VIs. 8. On the contrary, do not separate the compiled code. Try to do both and see if there is any difference. 9. Last resort - put the contents of the VI inside the caller.
  28. 1 point
    Now that you mention it I have not either.
  29. 1 point
    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.
  30. 1 point
    Wow, this is good news! I'll give it a try. Point taken, I was going to post on the VIPM forum but then this thread happened and I couldn't resist... You can also disable the VIPM Service in the Task Manager under Startup. That said, I would like this to be opt-in or at least opt-out. Maybe on first start or during installation.
  31. 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.
  32. 1 point
    Yeah I was quite surprised to see the new VIPM hidden away even when I thought it was turned off. Run with Windows start? Hmmm, no there is enough other crap starting then. Run with LabVIEW start? What??? Are you joking? LOL never.
  33. 1 point
    I haven't, and my initial reaction is that I would quit a job like the one you described. The closest I came was when my boss sat me down to show me his 5 year plan for the group since he heard I was planning on quitting soon and he hoped his new road map would inspire me to stick around. I thanked him profusely for showing me his plans, because it meant that I knew I was making the right decision leaving. I quit, he started steering toward an ice burg, then he was fired about a year later. I was contacted by a head hunter saying this job opportunity was a perfect fit for me. I had to inform him I had that job and listed reasons why I wouldn't come back. Someone else that was still there tried getting me to come back, only to realize they were one of the reasons I left. Things have not sounded all that great since.
  34. 1 point
    @Neil Pate I thought I had fixed this bug. It dates from my NIWeek 2019 demo when I made a last minute change from "Destroy" public method to "onDestroy" protected method. You see what happens when you do a TDD project and you skip the tests "JUST ONCE" because you're in a hurry and the boss wants this code deployed ASAP??? Hahaha! I'll do a fix this weekend... Edit: Was fixed in the Develop branch... I'll test, bring to master branch, build and release a new package.
  35. 1 point
  36. 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.
  37. 1 point
    @dadreamer if you're often looking at the binary data, you might have some use of "print-map" function of my readRSRC script: ./readRSRC.py --print-map=RSRC -x -i 'test_out/lv10/vi.lib/Utility/Convert RTD Reading (waveform).vi' test_out/lv10/vi.lib/Utility/Convert RTD Reading (waveform).vi: Warning: Block b'PRT ' section 0 size is 152 and does not match parsed size 128 test_out/lv10/vi.lib/Utility/Convert RTD Reading (waveform).vi: Warning: Block b'VICD' section 0 XML export exception: The block is only partially exported as XML. 00000000: RSRCHeader[0] (size:32) 00000020: BlockData (size:13559) 00000020: BlockSectionData[LVSR,0] (size:140) 000000AC: BlockSectionData[RTSG,0] (size:20) 000000C0: BlockSectionData[OBSG,0] (size:20) 000000D4: BlockSectionData[CCSG,0] (size:20) 000000E8: BlockSectionData[LIvi,0] (size:52) 000000EC: Block[LIvi,0].LinkObject[0].NextLinkInfo (size:2) 000000EE: Block[LIvi,0].LinkObject[0].Ident (size:4) 000000F2: Block[LIvi,0].LinkObject[0].Unk1 (size:34) 00000114: Block[LIvi,0].LinkObject[0].Unk2 (size:2) 0000011A: Block[LIvi,0].LinkObject[1].NextLinkInfo (size:2) 0000011C: BlockSectionData[CONP,0] (size:6) 00000124: BlockSectionData[TM80,0] (size:64) 00000164: BlockSectionData[DFDS,0] (size:388) 000002E8: BlockSectionData[LIds,0] (size:52) [...] 00003A44: BlockSectionStart[VCTP,0] (size:20) 00003A58: BlockSectionStart[FTAB,128] (size:20) 00003A6C: NameStrings (size:34) 00003A6C: NameOfSection[LVSR,0] (size:34) When you use "--print-map=RSRC" it prints what is stored at which offset of the RSRC file. Obviously it can't print compressed data this way, so for compressed sections you can map the specific section, ie. "--print-map=DFDS". And to get BIN file which matches this mapping, you can extract the VI with "-d" instead of "-x" - then you will get uncompressed BIN files for all sections, instead of some being converted to XML.
  38. 1 point
  39. 1 point
  40. 1 point
    This is the only change I made to the MQTT library. Simples πŸ™‚
  41. 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:
  42. 1 point
    I have updated this message, as after trial-and-error takes I've got success finally! As you can see, the VI is in runnable state and behaves without any errors. My steps to reproduce: 1. Unpacked lvlibp with 7-Zip unarchiver (as I'm on Windows currently) and pulled out "2" file (LIBPLBVW resource). 2. Extracted the inner resource blocks with readRSRC.py -x -i "2" command, got 2.xml, 2_DATA0.bin to 2_DATA4.bin and 2_LVzp.bin files. 3. Unpacked 2_LVzp.bin with an unarchiver, got NI_Embedded_Library.xml and Untitled 1.vi files. 4. Extracted the inner resource blocks from Untitled 1.vi with readRSRC.py -x -i "Untitled 1.vi" command, got Untitled 1.xml and a bunch of various resource sections. 5. Renamed 2_DATA0.bin (from step 2) as Untitled 1_VCTP.bin and placed it near Untitled 1.xml. 6. Added the following text to the end of Untitled 1.xml (before the last </RSRC> tag): <VCTP> <!-- VI Consolidated Types --> <Section Index="0" Format="bin" File="Untitled 1_VCTP.bin" /> </VCTP> 7. Packed the .xml and all the resources into a single VI with readRSRC.py -c -m "Untitled 1.xml" command, got Untitled 1.vi. 8. Extracted the inner resource blocks from Untitled 1.vi (again!) with readRSRC.py -x -i "Untitled 1.vi" command, got Untitled 1.xml and a bunch of various resource sections (is done to get VCTP processed correctly). 9. Opened Untitled 1.xml and removed everything from <LIBN> to </LIBN> (including the tags as well) changed the library name extension from .lvlibp to .lvlib (between <LIBN></LIBN> tags). To wit, this line <Library>Untitled Library 1.lvlibp</Library> should be turned into this <Library>Untitled Library 1.lvlib</Library> 10. Packed the .xml and all the resources into a single VI with readRSRC.py -c -m "Untitled 1.xml" command, got Untitled 1.vi. 11. Renamed NI_Embedded_Library.xml (from step 3) to Untitled Library 1.lvlib. 12. Opened Untitled Library 1.lvlib in a text editor and altered the lib URL to point to the new location. To wit, this line <Item Name="Untitled 1.vi" Type="VI" URL="Untitled 1.vi"/> should be turned into this <Item Name="Untitled 1.vi" Type="VI" URL="../Untitled 1.vi"/> 13. Opened the VI (LabVIEW did the library reload from the new path and reported), opened .lvlib. 14. In Project Explorer untied the VI from the library w/ RMB -> Remove from Library menu option, saved the both files w/ File -> Save option. Now the VI runs fine, so it might be a time to simplify this tutorial a little πŸ™ƒ If your tools could support lack of VCTP and recreate it automagically, that would be great for sure.
  43. 1 point
    The whole IDE is unacceptably sluggish. Doing any kind of block diagram create/remove space feels terrible. Everything just takes a few hundred ms to a second longer than it ought to. Tearing out tabs into new windows feels so heavy. When I start NXG now from fresh I get a total system freeze where I cannot even interact with the OS for about 30 s. It does not happen on subsequent openings but is still quite disconcerting.
  44. 1 point
    I've pointed out the sluggishness. It's actually the slowness of opening front panels and block diagrams and in opening right-click menus that is a bigger problem, IMO.
  45. 1 point
    You guys lost me days ago, but I love reading this. Please continue to share πŸ™‚
  46. 1 point
    Ok, here's what I did: I found a lvlibp file in my LV14 installation, and extracted it: $ file lv_icon.lvlibp lv_icon.lvlibp: PE32 executable (DLL) (GUI) Intel 80386, for MS Windows $ wrestool -x --raw lv_icon.lvlibp -o ./ $ ls -l lv_icon* -rwxr-xr-x 1 mefisto None 5377536 2014-06-25 lv_icon.lvlibp -rw-r--r-- 1 mefisto None 5375712 06-10 12:47 lv_icon.lvlibp_10_2_0 -rw-r--r-- 1 mefisto None 704 06-10 12:47 lv_icon.lvlibp_16_1 Then checked the RSRC file from inside: $ file lv_icon.lvlibp_10_2_0 lv_icon.lvlibp_10_2_0: National Instruments, $ ./readRSRC.py -x -i 'lv_icon.lvlibp' Error: [Errno RSRC {:d} Header sanity check failed.] 0 So, I never tried that before, and my tool doesn't currently support these files. But it should be an easy fix, so I will patch it and get back to you with more info. For fixing 'tampered with password' message - what I do is just removing the file from library when in extracted form (can't remember exactly, but I think 3 changes are required, one of them is removal of the LIBN which you mentioned). Btw, NI is inconsistent here - they say the password is just 'unintended modification' avoidance, but the 'tampered' message suggests the intent for creating that functionality was to provide some impression of security. EDIT: Fixed it! Now I'm getting: $ ./readRSRC.py -vv -x -i 'lv_icon.lvlibp_10_2_0' lv_icon.lvlibp_10_2_0: Starting file parse for RSRC extraction lv_icon.lvlibp_10_2_0: Block 'LVzp' index 0 recognized lv_icon.lvlibp_10_2_0: Block b'LVzp' max data size set to 5273600 bytes lv_icon.lvlibp_10_2_0: Block b'DATA' max data size set to 5375472 bytes lv_icon.lvlibp_10_2_0: Writing block b'LVzp' lv_icon.lvlibp_10_2_0: Storing block b'LVzp' section 0 binary in 'lv_icon_LVzp.bin' lv_icon.lvlibp_10_2_0: Writing block b'DATA' lv_icon.lvlibp_10_2_0: Storing block b'DATA' section 0 binary in 'lv_icon_DATA0.bin' lv_icon.lvlibp_10_2_0: Storing block b'DATA' section 1 binary in 'lv_icon_DATA1.bin' lv_icon.lvlibp_10_2_0: Storing block b'DATA' section 2 binary in 'lv_icon_DATA2.bin' lv_icon.lvlibp_10_2_0: Storing block b'DATA' section 3 binary in 'lv_icon_DATA3.bin' lv_icon.lvlibp_10_2_0: Storing block b'DATA' section 4 binary in 'lv_icon_DATA4.bin' lv_icon.xml: Writing binding XML The ZIP is auto-decrypted, so we can now extract it: $ file lv_icon_LVzp.bin lv_icon_LVzp.bin: Zip archive data, at least v2.0 to extract # unzip lv_icon_LVzp.bin Archive: lv_icon_LVzp.bin extracting: NI_Embedded_Library.xml extracting: 1abvi3w/resource/dialog/lvconfig.llb/LV Config Read Boolean.vi extracting: 1abvi3w/resource/dialog/lvconfig.llb/LV Config Read Color.vi extracting: 1abvi3w/resource/dialog/lvconfig.llb/LV Config Read String.vi extracting: 1abvi3w/resource/dialog/lvconfig.llb/LV Config Write Boolean.vi extracting: 1abvi3w/resource/dialog/lvconfig.llb/LV Config Write Color.vi extracting: 1abvi3w/resource/dialog/lvconfig.llb/LV Config Write String.vi [...] Will update after I look at the files I got. EDIT2: Looked at the files: The only real issue is lack of VCTP section. The rest of removing the VI from library is trivial, if you check how the file looks before and after compiling the library. VCTP sections from all files seem to be merged together (after all it stands for VI Consolidated Types), and stored in DATA resource of index 0. That resource is then compressed with ZLIB. Looks like DATA0 is zlib'ed, while DATA1+ are not. I will have to update the tools to handle a situation where the same resource ID has compressed and uncompressed sections. ps. If anyone wonders about the strange shortcuts we're using, I've made a wiki page on this: https://labviewwiki.org/wiki/Resource_Container
  47. 1 point
    There is: https://zone.ni.com/reference/en-XX/help/371361R-01/lvhowto/cli_running_operations/ What are you trying to achieve? To my knowledge there is no built-in way to avoid the splash screen. You can, however, skip the Getting Started window by enabling Skip Getting Started window on launch under Tools > Options > Environment. LabVIEW will then always create an empty VI on startup. Not sure if that is what you want.
  48. 1 point
    I would do it in two steps 1. Discard protocol data (~00D and 037) - This is typically done when reading the data string anyway. 2. Split the payload using Delimited String to 1D String Array.vi.
  49. 1 point
    Here is a Classic MCLB which can have its cells be transparent, and have symbols in all columns. System controls can't be colored, and the modern one I couldn't get to be transparent. It might be possible but the classic was easy. MCLB Symbols In All Columns Transparent.vi
  50. 1 point
    Certainly posting the VI might help. Short of that I've seen this issue when using this function a couple times, all of which were expected if I had stopped to think about it. The first is maybe your front panel has a minimum size set, and the decoration is less than that minimum. In this case you won't be allowed to make the window smaller, so it throws an error. I've also seen it do odd things when there are splitters and multiple panes on a UI, where it will try to scale the window to the largest decoration, but that decoration is only on one pane. I've also seen where there is a minimum pane size, and again the decoration is too small. I'm sure there are other reasons this VI can throw an error. Because of these types of issues I don't use this function too often any more. I also heard someone mention this function does nothing, and returns no error on the new cRIOs running embedded linux, with a monitor plugged in, but I didn't get a chance to debug it.


×
×
  • Create New...

Important Information

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