Jump to content

hooovahh

Moderators
  • Content Count

    2,918
  • Joined

  • Last visited

  • Days Won

    197

Everything posted by hooovahh

  1. The VIM Array package is a dependency, and actually included in this VIPC release. It was just easier for me as a developer than trying to remove the dependency, and easier for you guys if everything is in one file.
  2. I haven't tested everything in there on NI Linux RT but a few of them I have. The only thing that uses any thing questionable is the Circular buffer has a compression option where it zips the circular buffer before logging it to disk. I used the native LabVIEW zip API so I suspect it works on Linux RT...but I forgot to test it before posting it. Everything else is just pure G and I see no reason it wouldn't work.
  3. View File Hooovahh's Tremendous TDMS Toolkit This toolkit combines a variety of TDMS functions and tools into a single package. The initial release has a variety of features: - Classes for Circular, Periodic, Size, and Time of Day TDMS generation with examples of using each - Reading and Writing Clusters into TDMS Channels - XLSX Conversion example - File operations for combining files, renaming, moving, and saving in memory to zip - Basic function for splitting TDMS file into segments (useful for corrupt files) - Reorder TDMS Channel with Demo There is plenty of room for improvements but I wanted to get this out there and gauge interests. The variety of classes for doing things, along with VIMs, and class adaptation makes for using them easier. If I get time I plan on making some blog posts explaining some of the benefits of TDMS, along with best practices. Submitter hooovahh Submitted 12/12/2019 Category *Uncertified* LabVIEW Version 2018 License Type BSD (Most common)  
  4. Version 1.0.0

    15 downloads

    This toolkit combines a variety of TDMS functions and tools into a single package. The initial release has a variety of features: - Classes for Circular, Periodic, Size, and Time of Day TDMS generation with examples of using each - Reading and Writing Clusters into TDMS Channels - XLSX Conversion example - File operations for combining files, renaming, moving, and saving in memory to zip - Basic function for splitting TDMS file into segments (useful for corrupt files) - Reorder TDMS Channel with Demo There is plenty of room for improvements but I wanted to get this out there and gauge interests. The variety of classes for doing things, along with VIMs, and class adaptation makes for using them easier. If I get time I plan on making some blog posts explaining some of the benefits of TDMS, along with best practices.
  5. I also can redownload it, you likely need an account.
  6. Now we are digressing a bit but I also have an old piece of marketing I like to show off inconspicuously. At NI Week the last few years NI has various buttons that say phrases for that years' theme. Usually people grab a handful of buttons and put them on the lanyard you wear with your badge on it. I won't go too over board but I'll grab a few and put them on, but mixed in with them is a LabVIEW 7 Express pin I was given years ago by someone that was at NI Week the year LabVIEW 7.0 Express was released. It is old enough that it is starting to rust on the back a bit but LabVIEW 7 (and 7.1) were my favorite versions for a long time so I wear them. Last year someone was looking at my various buttons and saw that and asked where they could get the retro NI Week pins and I had to explain where it came from.
  7. I don't have anything to add other than I've seen this but not in any recent projects I've worked on. It always frustrated me when I'd drill into some VI that was taking forever and it would be some property node or Read/Write/Open that was supposed to have a small timeout.
  8. One quick comment on the can opener thing. I might well be using the can opener incorrectly, and I'll try the horizontal way next time, but I think my habits came from an old wall mounted can opener I used at my grandparents for years which was vertical in design. Also I included an ad for it because the thought of giving a can opener as a perfect gift to the "queen of the kitchen" would probably not go over well.
  9. In the Facade, set the background pane color to the transparent color value. This doesn't make the facade transparent when developing it, because...well it can't really. I believe when editing the VI the pane will appear black. But when the XControl is running in a new front panel, it will have a transparent pane color, meaning it will be the color of the front panel on that VI. The transparent color value is 0d16777216. https://forums.ni.com/t5/LabVIEW/Can-a-Color-Box-display-the-transparent-color-16777216/td-p/172288 Also is this documented somewhere or just tribal knowledge?
  10. So when I was playing around with this I would map my build folder, to the www folder of my webserver, with a symbolic link. This way I would build and it would already be in my web server folder ready to be used. Here is a very loose set of steps I did to map a folder from a build to a place that the webserver uses. I don't know of what NI uses on the hosting side and I've always just used XAMP which is Apache. Windows has a built in server too that works well enough for basic stuff.
  11. The "Check your internet" is a catch all error basically saying it couldn't install, and it must be because the internet is down right?...right? For me I got that error when I had a bad stick of ram in a computer, and it would uncompress a package, and then the CRC would fail. I'd restart the installer over and over until it worked but the computer had all kinds of other problems. The Offline installer including drivers and several other things is a bit crazy. I mean will the community edition also be 25+GB in size? I'd usually download the whole developer suite in the past anyway so it is on the order of the same size as that was. The Web install however was perfect. It would prompt you on what you wanted to download and then install offline using those things worked great, but no more. Sorry I'm not from the 2.x era LabVIEW and the idea of installing it in anything other than the default install location of "LabVIEW 20xx" seems crazy to me. I suggest embracing the change...from 2003. Package manager does decide where it goes and I saw several people complain that they couldn't even install LabVIEW to any place other than C:\ drive without editing the registry. When I go to a new version of LabVIEW I just leave the one that's already there. I mean I usually don't upgrade all projects at once and some maybe in the older version so I just install them side by side. I think the most I've had installed was probably 7 or 8. I guess what I'm saying is I've never uninstalled a version of LabVIEW, and I would expect problems if I did. I mean honestly it should work just fine, but I wouldn't expect it to.
  12. It really depends on what you are trying to do so I get that. For me even just setting the VI file to read-only would be enough, but I ran into a few times when a mass compile would want to overwrite the VI despite it having separate compile code, but that was years ago. For me the purpose was that a developer would be drilling into the code and not realize they were in a reuse function and would start messing around with it and changing things that will now make the program behave differently on one developers machine, than the others. A gentle reminder to not mess with something was all we needed. But I get your points.
  13. Not trying to derail the thread even more, but every time I hear that argument I say that is why you can lock a VI without passwording it. Which is what my Pre-Build action on building a package does. Need to edit it and do a test? Sure just unlock it. Drilling down into a VI and not realize it is part of the reuse library? You will when you see it is locked. But whatever. I still tell the quote from NI R&D saying off the record that the protection you get from password protecting a VI, is about the level of protection you get from tissue paper.
  14. Oh yeah I forgot about that. This is the Salt that gets applied to the MD5 of the password. Starting in 2012 NI started salting the block diagram passwords. The salt that gets applied is something like the number of all String, Path, and Numeric controls connected to terminals. I think this does go into clusters and arrays so the work actually needs to be recursive. This ends up being a 12 byte salt, but I think 9 bytes are always 0. Of course you don't need to do all of this, to figure out what the salt is. I mean all you need to do is guess three numbers, all of which are the number of controls on a terminal so you know that the value will probably be small. So when I wanted to figure out what the salt was I would just keep guessing until a match was found. It was easier than trying to look into the VCTP block to find all objects, and then all terminals, and blah blah blah. If you have a VI that is passworded correctly then the only unknown in the equation is the salt. I mean lets use this example equation (note that the actual one is different): Result = MD5(Hash 1 + Hash 2 + Hash 3 + Salt) In a valid passworded VI I can pull out each of the variables from the VI other than the salt. So I just made a VI that sets salt to 0,0,0, then 0,0,1, then 0,0,2, etc, until the equation matches. Fun story: Years ago we were in a meeting with a few LabVIEW champions and LabVIEW R&D and the discussion of protecting intellectual property came up. Someone was asking NI about ways they could tighten up their security. I made a suggestion of encrypting the password with the number of string terminals in a VI, knowing that this was something NI already was doing. Another LabVIEW Champion said that was a bad idea since that could be figured out by simply opening the VI and looking at it. I had to inform them that I said that knowing that that scheme was actually used by NI, and I put that out there to subtly let R&D know we know about it.
  15. When a VI is in a library, the password is stored in the VI, and in the library, and there is some kind of link in the password of the VI to the library, in the VI. So if you recreate a VI, and it doesn't have a password but the library does, or if the two passwords don't match, then you will get that error. Now that I'm searching for it I can't find much, but Flarn also had some code for getting file structures of a VI. His personal site had a few things but seems to be down at the moment. http://flarn2006.dyndns.org/llvim/#downloads Just be aware that most of his stuff is viewing and editing the objects in a VI, so I'm not sure how useful it will be. But he should have some general file parsing stuff.
  16. I reversed the PHP code into LabVIEW here as well, adding just a few features. Also you've probably come across Flarn's stuff, he has some code for object deconstruction getting into pulling out and manipulating objects in the LabVIEW source. Which is neat but probably isn't what helpful for what you are doing.
  17. It is not. They will not. As stated this is how all programs work. You cannot keep the executable safe, while also having it be open enough to execute it. I do hope you share anything you discover with the community, I just expect what you will discover is that reversing a binary of any kind to its source will take forever, be error prone, will be incomplete, and won't be very useful. This will especially be true for LabVIEW as the tools for this disassembly are less mature than other languages.
  18. This likely won't get you very far. Yes you have the files that are in the EXE extracted which is useful. And in theory you should be able to add all those files to a project and rebuild it. But if you are trying to do this so you can rebuild in a newer version of LabVIEW, or so you can edit some part of the EXE, then you aren't going to be able to. When a set of VIs are turned into a binary, they are compiled for that that target and runtime version. Then in almost all situations the block diagrams are removed, and in many cases the front panels are removed. What is in the EXE is then still VI files but most are just the compiled component with no source, and no way to edit them. If when you built the EXE debugging was enabled then block diagrams and front panels will still be included, and then extracting the files will mean you can get the VI source out, and then it can be recompiled or edited like any normal VI. So the files you extracted could probably be added to a project, and then rebuilt, but you won't be able to edit anything in any of the VIs. I guess you might be able to replace one of the VIs with a new one from source if you recreate all the functionality of it, and have the same connector pane and name but I've never tried that. Still anything you discover is good information and the community welcomes any thing you are able to figure out.
  19. VIPM packages support Post Install VIs, and Post Uninstall VIs, and in there you could have a VI that edits the LabVIEW.ini file to add or remove things. I also don't have a 2009 machine to test it with, but if this ever became an official thing I'd encourage the use only after the point NI made VIMs official. I didn't use VIMs in pre-2016 for anything real just experimenting and don't know the stability of it in earlier versions.
  20. Oh another consideration with this is currently OpenG Array tools work in LabVIEW 2009+. This would make a version which would only be compatible with 2017+.
  21. SMorRES - Scalable, Modular, Reusable, Extensible, Simple. I do like architectures and frameworks to be simple, but not at the cost of scalability, modularity, reusability, or extensibility.
  22. Sure, why not. OpenG array tools are great but could have used improvements over the years, from inlining, to conditional terminals, and now VIMs. But to pump the brakes a little, I heard some rumors NI might also be in the works trying to make their own VIM array functions. No solid timeline and no idea what functions they are tackling, or distribution method. Then again we don't need a rumor about what NI might be doing to dictate what we are doing. Also I have no idea who is in charge of OpenG, or how to contribute to it. <shrugs>.
  23. I just tested on a fresh 2019 machine and I also needed SuperSecretListboxStuff=True in my INI.
  24. Well some of these posts are from 11 years ago, and there have been lots of back end changes since then. We try to keep all the content we can but in some migrations things are lost. That being said I can download the newest attachments. A while ago before I was a moderator there was a pretty catastrophic crash with all content of the forum being lost. One such awesome engineer realized he had setup subscriptions to the forum, and would get an email for every reply someone made. Because of this he had a record of all communications made on the forum and provided it to the site admin. I wasn't a mod then so I don't have all the details but with the help of Michael and this guy they were able to bring back lots of the old content as LAVA 1.0 Content which you'll see from time to time. I'm unaware of what happened to attachments then, but I assume they were all lost, or manually reuploaded. Edit: Here's more info on the crash.
×
×
  • Create New...

Important Information

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