Leaderboard

I think NI shares a lot with the community. There are a lot of internal details about LabVIEW in the NI KB. There are special INI tokens documented, how we flatten data, how LabVIEW behaves in a lot of solutions. You might want to look through some of our KB articles if you're curious about the internal workings of LabVIEW. However, I do not think that alpha releases are for incomplete features. Just because we have a feature that's half-done doesn't mean that everyone should be able to use it. There are good reasons we don't finish some features -- they aren't stable enough, they're too resource-expensive, they don't meet the needs of our customers, etc. If we release a feature, we will support it. We still support some decade-old hardware. NI has great technical support. But we can't support everything. I don't speak for NI, but I suspect we would rather support everything we release rather than release everything and have holes in what we support.

Looks like you put in a lot of effort into this. One thing I noticed is the list of existing scales show all scales, even ones that are not appropriate for the current tab. So if I have a linear scale, but am on the Map Ranges tab, my linear scale shows up in the list, and trying to edit it doesn't work. Why not only populate the drop down with the scales for that type? Also is there a reason you are doing this all manually instead of using the DAQ Assistant? Attached is a quick VI I made to edit or create a scale. You may need to update the path constant on the block diagram to point to your DAQ Assistant because the path is set currently to a 64-bit Windows, running LabVIEW 2011. Add Edit Scale.vi

Badly in need of vacations . and btw i'm old enough to have earned the right to be grumpy every now and then. While I understand his desire to dig deeper in some other posts he did, I have to say that I do not see any sense in trying to see a specific intention in a pattern on screen that was chosen over 20 years ago, for some reasons, that might be obscure or not. And I would also like to have a peek at the LabVIEW source code, except that I would most likely have to realize that it is just way over my head, so I pass that opportunity and keep myself in the illusion that I might understand it.

Good point Bobillier. However, this may only be an issue if many relays are switched simultaneously, plus it depends on the relay coils. Still, it's always a good idea to design with isolation and protection in mind.

I believe the ULN2803 will work for you. Just be sure to connect a 12V supply to pin10 and then you'll be alright.

drjpowell: Re: 1) Yes. Re: 2) Yes, it is easier to code than watching for all the messages to come back. I wonder, though, if it might also be easier to design a "round robin" message: create a message with a list of processes to visit, send the message to the first one, it adds its info, then passes the message to the next process on the list, coming back to the original process when it is done. That would reduce the "do I have them all yet" bookkeeping and still be consistent with asynch messaging. I've never tried to build anything like that.

Djed: Second, xnodes were not designed as a feature for customers but as an internal tool. - I am not a customer. As such, believe me!, they are buggy, under documented, flaky, dangerous and unfinished. - I did not bother me. They are nowhere near a feature we can support and we are not allowed to talk about them. - This is the forum, you do not have to speak. You know what it is "LabVIEW_LabVIEWInternalTag_PKG"?

Aristos Queue: If you want something for knowledge of the "xnode, externalnode",it write on priv. Anyone know what is "LabVIEW_LabVIEWInternalTag_PKG"?

I usually buy the "it is too complicated for the masses" argument until I try using XControls. Compared to those XNodes are a walk in the park.

Oh, man… The number of times I’ve double clicked on a subVI, double clicked on its icon to bring up the editor, made a copy, closed the editor, opened another VI’s editor, pasted. What a waste of time!