Jump to content


  • Content Count

  • Joined

  • Last visited

  • Days Won


Everything posted by hooovahh

  1. Someone from NI can chime in, but I think this is not possible and is one of those limitations of LabVIEW Scripting. QuickDrop has a CTRL+Shift+B that operates on a property node and it has a limitation of not working with "dotted properties". I assume that's due to a limitation with LabVIEW's scripting otherwise NI would have supported it.
  2. Yeah but I wonder how much of a format this really does. I was experimenting with reading/writing NTFS drives from within Linux RT. All that was needed was a few commands to install the appropriate package through opkg. After that it could read and write NTFS USB drives just fine. At some point I wanted to start fresh so I formatted it through MAX. But after the MAX format I was still able to read and write NTFS drives. So I suspect this isn't so much as a format as a "Remove all NI software and config, and copy over the base image". All OS level things might just be left alone. I never really followed up on this, and I do have several controllers so I could have mixed one up and formatted the wrong one, I'll try to reproduce this test later today to see if it is reproducible. See edit, I thought MAX format didn't wipe everything, now it seems it does wipe more than just NI software as OPKG installed packages are removed. EDIT: Okay a few other things for anyone that cares (just me then?). If you are using the Legacy FTP, you can read NTFS drives but cannot write to them. Running LabVIEW VIs, and the web interface to look at the U drive returns errors, and empty drives, but FTP can read and transfer files. This is where my confusion came from. I formatted the controller and FTP could still read the drive. But since I couldn't write to it or transfer data to it without extra packages being installed, this means a MAX format does uninstall OPKG installed packages, so it probably does wipe everything and start from a fresh image.
  3. I downloaded the web install last week and speeds were as slow as I expected due to our infrastructure issues. By that I mean it didn't seem any slower than usual, maybe the developer suite's are cached differently. Also geographic location can be a factor since NI has several data hosting locations and it is supposed to pick the one closest to you. Since all my internet traffic is routed half way around the world while at work I have no idea where my download came from, but I'm in the Detroit area.
  4. I'm still searching but I had a similar issues. Someone mistakenly ordered the Windows version of the 9132 when we wanted the Linux RT. I asked NI what it would take to change it over and they said we would have to send it back getting a refund (probably minus stacking fee I can't remember) and then buy the new one. The reason was that the part numbers of the product were different and one example was that if we ever needed support it would be directed to the wrong place, and a replacement would give us the wrong one. I can't remember if I had this conversation in an email or online, or a private message I'll post it if I find it online.
  5. Okay I'm in the process of downloading the fall bundle but I can say that I am thrilled to find that the F1 patch fixes a major crashing issue with access violation, and illegal operations I've been having. The cause is unknown but I suspect it has something to do with subpanels, splitters, and call asynchronous nodes, but to be honest it could be anything I couldn't nail down the issue. And if patches are like the ones in the past, the 2018 SP1 F1 patch must be installed over top 2018 SP1. I suspect this was a patch discovered after going gold with 2018 SP1 and being sent through the validation, and DVD pressing process. A pain for sure to have to download a huge thing install it, and then realize there is more to download and install, but if it finally means being able to get LabVIEW working again I'm happy. EDIT: Seems my issue was likely CAR 715018
  6. I ran into this several times in the past and haven't experienced it lately. I'm guessing NI has fixed it in future versions. It is still annoying and so I'd update to the latest patch level you can in the hopes it is resolved there. Like I said if you know where there is an issue just add an Always Copy, but the problem is when VIs are behaving that way and you aren't aware of the issue.
  7. So a while ago I wrote a XNode that would add functionality to the traverse for GObjects. One thing it would do is order the references based on their positioning on the front panel or block diagram. The most common use for me was for something like a grid of buttons. I would want them ordered from left to right and top to bottom so I made an enum input to the XNode that orders them after finding them. It would also return the reference as a boolean so no casting was needed after. Of course this goes with the normal "XNodes are experimental" statement but you could look at the code and see how I did it if you wanted to not use it.
  8. Your usb2RS232 device is likely a counterfeit Prolific, or FTDI chipset. The official makers of Prolific and FTDI have pushed out driver updates which disable counterfeit hardware which previously worked with the official drivers. At one point an FTDI driver disabled the counterfeit hardware making it not work in any computer once it had be used with the official driver. These updated drivers have been published as Windows Updates, and as a result they have stopped working unless you manually roll back drivers and force uninstall the newer ones. Not saying this is your situation but it has been mine. You often have no way of knowing if counterfeit chips are being used. An update will come through and they suddenly stop working. As for the LabVIEW thing yeah that is on NI. But to be fair they can't support every operating system with every version of LabVIEW and the more they cut out the more resources they have for other support issues.
  9. Throw in an always copy liberally and I'm guessing things will work start working. If you can isolate it well enough send it to NI for them to investigate. What version of LabVIEW and patch level?
  10. I don't share your opinion of Windows 10. I haven't had hardware access issues, and as others have said current gen LabVIEW is supported on several operating systems. 2015 SP1 is supported on 6 different Windows OSs according to this table, that seems pretty extensive to me. That means Virtual Bench 15.0 should work fine on XP. Expecting Virtual Bench drivers to support 8.5 seems like a stretch since it came out 8 years before the first release of Virtual Bench (correct me if 15.0 isn't the first release of Virtual Bench) There are things I hate about Windows 10, but the start and tile really doesn't bother me. In the past I have installed Classic Shell to get a basic looking start experience, with a skin that looks like Windows 10. But even on systems that I don't do this on it doesn't bother me. Windows 8.0 with the full screen tiles did bother me, but even then most of the time I just started typing what I wanted, or pinned important programs to the task bar, or used desktop shortcuts on systems I'd deploy to. Most users of my systems don't open the start at all, they just use the software I write anyway. And on systems I develop on I'm free to customize it however I want.
  11. The real death of an API isn't when development stops, but instead the last time someone uses it as a dependency. (loosely quoting several people about existentialism)
  12. VIPM years ago did have an Enterprise version (I think they called it) which was more or less what you described. It didn't have all the features of Pro but could subscribe to feeds. At the time it seemed like it was too confusing. There was free, pro, enterprise, and I think a 4th option. In the early days of package management, people (myself included) were confused about what features were good for what and it was hard to know what was needed. VIPM was the first package manager I ever used and several concepts about feeds, dependencies, and use cases just weren't well understood. JKI simplified this with a Free, and Pro making it clear when you would want one over the other.
  13. I've never used VirtualBench but if the drivers aren't supported, then they aren't supported. The only thing that might help you is that sometimes in the past NI has done things like just used DAQmx for some features, and NI-DMM for others. So if you must use LabVIEW 8.5, I'd suggest trying to find the newest version of DAQmx, and NI-DMM, and NI-Power, that work with 8.5 and install it, and see if MAX recognizes the VirtualBench at least for those features.
  14. So if it wasn't clear, this release had issues. It wasn't intended to be the final LabVIEW 2018 SP1 and was an version between SP0 and SP1 for testing. It was unintentionally released to the public and wasn't intended for the general public to use, and likely won't activate. The release was pulled and if you did download it you are better off not using it until the actual SP1 release. On top of not being intended for an actual release, and not activating, it also has a bug with upgrading from 2018 f2 to 2018 SP1 which is being addressed for the actual SP1 release.
  15. How much time do you have? Packages are version specific at the moment (so a String package needs a new release for every version of LabVIEW supported, String 2017 1.0.0, String 2018 1.0.0, etc). There is no palette editing so you'll need to edit your own palette, make your own MNU files and include them. There are no Pre/Post Build actions, and in fact all Post/Pre actions are EXEs with no option for calling VIs. Only Post-Install and Pre-Uninstall actions are allowed. Package dependencies seem to only be checked between the current feed. So unless I'm mistaken all external dependencies need to be copied to the new feed with all the dependencies brought over. No dependency scanning. No package of packages. No offline single file with everything included (but an installer might make that possible in the future). Packages can't be loose VIs, they must be in something like an EXE, or source distribution first. Basically NI has been saying that NIPM at the moment should be thought of as an installer alternative, and using it for reuse distribution is going to be very difficult. That can change in the future but for now if you want to deploy an application to multiple machines, Skyline can do that because NI Packages are like little installers. Until NI makes NIPM act more like VIPM, reuse and toolkit distribution using NIPM will be much more difficult.
  16. In addition to this being a useful tool for development, I also this this helps demonstrate how to do some commonly requested things in XNodes. This can be seen as a template on how to handle updating the icon based on other objects, filling in the help from other sources, handling single clicking, right clicking, and replacing with non-XNode code via a right click. If anyone is looking to make a well done XNode I'd suggest looking at how some of these things are done with this one.
  17. I've seen in the past that when updates were made to OpenG (years and years ago), they weren't to the newest version of LabVIEW and would support a couple versions back. Since VIMs are officially only in 2017 and newer that would limit those wanting OpenG's new refresh to that version. BTW I think these are the links that were intended for the XNode and VIM versions of the OpenG array tools. Both aren't just direct replacements but have a few other new functions, or new features to existing ones. Other improvements like inlining removing debugging, and automatic error handleing can also improve performance over the ones from 2009 or so. And yes I forgot about the zip utilities which work so much better than the native NI ones.
  18. Yes many OpenG functions have native equivalents, but usually lacking in some way or another when it comes to what it can do. I made several idea exchange requests for Array, File IO, and Clear Errors to act more like OpenG. I heard rumors about a few things that might make their way into new versions of LabVIEW since VIMs are not a thing. Having my customer be my boss means I can get away with using any 3rd party tools I feel comfortable with (license permitting) and OpenG is one of those things I've just always installed on all development machines. I have a single VIPC that has all the OpenG, MGI, internal packages, and various LAVA things. As for OpenG being dead, looking at the last date of package releases makes it pretty clear development has basically stopped.
  19. Yeah there are several reasons why NI's mistake here isn't as bad as Microsoft's. LabVIEW 2018 SP1 wasn't automatically pushed. An uninstall and reinstall fixed the issue, doing something like that in Windows is a lot more difficult. And NI's issue isn't deleting data (that I know of). Still crappy and NI is clearly looking into it. That being said I have 2018 SP1 running on a couple machines already just fine. But yeah having the 2017 SP1 example doesn't instill much confidence. Fool me once kind of situation here. That being said I don't mind being a test subject when it comes to these things. I updated as soon as I could and took the risk on a machine I didn't care too much about.
  20. We use a PreBuild action, which can set the build number of an EXE to the SVN commit version. This means that we'll have software where commit 384 is the source that made that EXE. Having it in the EXE means Windows can tell me what version it is even if I can't run my application and get to an About Screen. It isn't seamless but it works well enough.
  21. Can you describe the issue you had after your upgraded? Maybe we can help NI in finding the issue.
  22. Thanks for reminding me. I just tested it and yes the TDM Importer Version (as reported in Excel) now imports my TDMS files without crashing. That was a major pain because I'd uninstall TDM 18.0.0, reinstall TDM 17.x, but in the uninstall some other dependencies were removed which then needed to be reinstalled...which by default installed 18.0.0 again. Oh and it looks like the download page to this add-on was updated yesterday to the new version too. Other fixes in SP1 I've heard are related to VIMs but am unaware of the details.
  23. I still have some legacy stuff that uses INI keys. The users I trust, know how to edit them pretty easily. Not saying they can't do the same for JSON but it is a more familiar looking format. It's good and bad, but every operating system has a text editor.
  24. Those are all great suggestions. The read/write panel could have other improvements too a list of controls to exclude, or an option to exclude indicators. Do we really need to read and write the Error In/Out? Most likely no. The core of the code is using NI's configuration functions, which are fine for small files but for arrays of clusters of arrays it struggles. OpenG Read/Write takes a long time for large data types that are heavily nested, or array based. The MGI Read/Write Anything work much better when it comes to this.
  • Create New...

Important Information

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