hooovahh

You must know the second half of that expression...NOW WHERE'S MY MILK? (sorry for shouting but it felt appropriate). I'd love for a way for the XNode itself to state that it will or won't contain code that allows inlining since auto detection is mostly impossible. But it sounds like that will likely never happen. Thanks for the the help.

This really does seem like a feature of an XNode. Somehow telling the IDE that it can or can't be placed into a VI that is inlined. Looking at the XNode in a text editor doesn't seem to help, nothing jumps out at me as a value stating it can or can't be inlined. And the output of the generated code doesn't seem to indicate anything either. The only hint we might get is from someone at NI...that might be reading this and wondering if they should give the mouse a cookie...the mouse says "yes".

This isn't true for all XNodes so you are right there must be something else going on. If you drop the Error Ring XNode (made by NI) it appears to work as expected, working on inlined VIs.

Okay I think I figured it out. An XNode gets inlined into your VI automatically. But there are some functions that aren't allowed to be in an inlined VI, like New Data Value Reference, and property nodes. So if your XNode contains something that normally can't be inlined, then the XNode is fine, but it can't be in a VI that is inlined. Make sense? This is also why VIMs in 2017 can't contain property nodes since they aren't allowed to be inlined.

It seems the two functions used are uncompress, and compress, given a string input, and generating a string output. I'm unsure of if or how the LabVIEW native zip functions could be used in place of these but if you can do that this will be more multi-platform. Also how in the heck did I miss this toolkit all my life? Very cool.

I did find a work around for this. If you add an Always Copy to the ReadDVRData.vi coming out of the read function, this VI appears to work as expected.

I'm starting to feel the same way. I was super excited when this came out cause I had some real places that I could start using it right away. But I found a bug on RT (which I've submitted no CAR yet) which can cause RT applications to crash if you access a reference that is no longer valid (Queue or DVR). This is bad but the answer for now is just don't access invalid references until this is fixed. The problem is I've seen plenty of times where after I enable read-only DVRs, the reference goes invalid in some places causing a random crash. Debugging these crashes is really hard, and isolating it into a small reproducible project that NI and others can test with is also hard. But it is also difficult for NI to fully test these new features on a large production level project because that's not what NI does, we do. Thank you for posting it to NI, hopefully we get a fix as an F patch.

I have some software I've written that outputs to the non default speaker (headphones in my case too). It worked as expected changing the device ID in Windows 7 x64, but I haven't tried running that software in Windows 10 since upgrading my OS. I'll try to remember to try this out when I have access to that computer. Edit: Okay a little bit more on my situation. I had a desktop PC with audio going out on the HDMI to a TV. I would plug in head phones, which Windows would make the default audio device. I didn't like that so I changed the default audio device back to the HDMI output and all normal software would output to that. I would run my LabVIEW VI to output specific audio that I wanted to hear on my headphones, and not interrupt the HDMI audio.

I've used Mercurial with LabVIEW in the past, I'd recommend you checkout the TortoiseHG which has similar explorer functionality you are probably used to in TortoiseSVN. https://www.mercurial-scm.org/wiki/TortoiseHg As for separating source. This feature has been in place for several years, and while there could still be bugs with it, most of the initial problems problems people have had with it have been ironed out. That being said I do sometimes still need to purge my compile cache to force things to work, but I think that issue could happen on non separated code as well. As for the read-only locking functionality. I remember having this but I don't remember how to configure it to behave this way. But with DSCC I think the idea is to not need to first ask to get locks. The intent is anyone can make changes and then push them to the repo as they need. I have only worked with DSCC a couple of times, but I don't remember stepping on any other developers foot much.

It's somewhat non-trivial to setup. But you can create an x86 based Linux RT VM to test this type of thing.

I'm contacting Michael. Is this possibly an IT issue? Proxy issue? Corporate firewall? Just trying to gather information.

Okay what is the error message you get?

Dang and I thought I read every post clearly. Anyway I can't talk about the beta, and if a thing appears fixed in the beta or not, but I think I can say that I made NI aware of this in the beta forum. If a CAR is assigned I'll post it here.

There isn't a release date for SP1, but I'd suspect (with no inside information) I'd guess November-ish due to that being 6 months after 2017 release. I must not drag from one BD to the other very often because I didn't know this was an issue. With two relatively simple VIs dragging around works fine and is pretty responsive. But as soon as I try with a project that has actual code in it I see the 1Hz refresh you are talking about. I did however find an INI key you might be interested in which reverts some of the 2016 live drag functionality. If you add LiveDrag=False to you LabVIEW.ini you lose the live drag functionality, but I also found that dragging from one BD to another seems to be improved as a result. EDIT: Or pressing 'x' mid drag to disable it for that drag seems to help.

Yeah this is somewhat known. Some times I have a page up for a while then go to reply, I type in a bunch of text and hit Submit Reply only for nothing to happen, but at least my text I entered is still there. I will copy the text, refresh the page, paste it in, and reply will work due to a page timeout. It is possible your page was just timing out and not allowing for uploads. I'd suggest refreshing the page (copying what you entered first) then paste it, and then try to attach. If you are still having issues I'll contact Michael, since this admin level issue isn't something I can really do anything about.

So I'm missing a VI in that snippet for the decoding part which looks like some kind of NI get icon library. But attached is the VI that was that snippet, and another way of getting the icon if you don't mind opening references. I think Jim was interested in getting the icon without VI Server for its usage in VIPM. Get XNode Icon.vi

Oh only a known bug for 11 years on value change not working properly? Kinda seems like something someone might run into all the time. Oh so true, new quote for a signature? Possibly.

You got me wondering so I went and looked at the service requests I've opened and...it only lists 8 in 5 years. I think it is missing some maybe due to account weirdness, but on top of that I realize I gravitate to the forums a whole lot more for support, which does make it harder to track. Many times I'll have some issue like a crash in LabVIEW when I run a project. Then I'll start minimizing the project to isolate the problem, then I'll post the test VI on the forums so others can try it out and convince me that it isn't just my setup causing the crash. Then eventually someone from NI will chime in and say yes this is a bug I've assigned CAR XXX. If it is a major issue with no work around then yes I'll contact NI directly but if the issue can be isolated it can usually be worked around. Anyway of the 3 service request I've opened in the last year, one couldn't be reproduced, and is still a point of concern but hasn't been an issue in months, one I opened yesterday but is looking good, and one I opened a month ago because of a licensing issue that NI hasn't been able to resolve. That being said I've always been impressed with NI's ability to help out. I also thought Microsoft did a pretty good job with support too. One major downside of the forums for CARs is while it might get more attention at first, it is easy to just lose track or ignore requests.

Oh lovely. Yeah I noticed this was removed for NXG and complained, but didn't realize this extended to current LabVIEW.

Glad you got it working (partially at least) my suggestion would just be to repair stuff. Yeah it takes a while to reinstall MAX, LabVIEW and all the other stuff but it has worked for me most times LabVIEW refuses to start.

Oh the mysteries of .Net. It seems Windows 10 comes with at least 4.6. The code I developed is based on the link you provided, which is why I'm also confused why that works and mine doesn't.

What are some of your environment versions? I've tested this on Windows 7 x64 LabVIEW 2015, 2016, 2017 32-bit, and with some success on Server 2012 x64 LabVIEW 2015. I say some because it runs and works, but the preview images aren't shown in the selection UI. Really that is just a terrible hacky solution and I regret doing it. If I get some time I may try to revert back to the picture control solution. You're issue definitely has to do with the .net stuff.

Search your feelings, you know it to be true. The dark side is the only path forward. (unless someone from NI comes here which does happen but I think this is specific enough of a problem to ask that group) This really does sound like a software limitation, potentially in the kernel. The fact that the 15th device is pluged directly into the cRIO not through a hub is the key piece of information.

I'm curious what USB hardware you are using. It sounds like you have 16 individual devices and might fair better with a single 16 port device. I've used these successfully on Windows, but never had access to one and an RT controller. I know of no reason why this limitation would be there, but NI might and you should probably crosspost here. EDIT: You may also want to update this post with USB devices you were successful with. I haven't found an FTDI, or Prolific chipset that hasn't worked yet.

One work around I've yet to try is I've heard you can set the window to be transparent in the VI properties. And then make it not transparent when the VI starts running. Not sure if this actually works but I've seen it on several of my programs and just haven't looked into fixing it since it is a pretty minor issue that no one has complained about except me.