hooovahh

Oops, so there is apparently an INI key I had that I didn't realize made this work which might be another reason to not use it. You need this: ExternalNodesEnabled=True With that you can wire an array of strings to the VIM I attached earlier in 2015.

Nope you can just drag and drop the VIM I attached to a BD and it works as expected.

That's not true. In 2015 (and several versions back) you could rename a .VI to .VIM and the inputs and outputs would have type propagation throughout the subVI just like it does in 2017. The difference is that in 2016 and older it was implemented as an XNode and had issues with class (something XNodes have a problem with) and as a result working with the XNode and forcing an update also wasn't as easy. Oh and the wires wouldn't break if there was a type problem, it would just not work and tell you the subVI was broken, but wouldn't allow you to see the VI or know which wire types it didn't accept. VIMs worked back then, but not nearly as well as 2017 and I wouldn't really recommend using it. I presented on XNodes and VIMs at NI Week 2016. EDIT: Apparently you also need this in your LabVIEW.ini: ExternalNodesEnabled=True Remove Duplicates 2015.vim

http://digital.ni.com/public.nsf/allkb/F0FC362A73C794BA86257C6700692B0B And an idea exchange item to make this easier. https://forums.ni.com/t5/LabVIEW-Idea-Exchange/Add-right-click-option-to-delete-class-mutation-history/idi-p/2594921

In my typical development cycle I keep looking forward to the next release (2017 SP1) imagining it will fix all of my stability issues. Not that my system is unstable, just that long delays in editing, and saving, make for a painful development process. Oh right positive. Rapid prototype and performance testing with small VIs is fun. For performing some kind of custom filtering, I'll sometimes write it 2 or 3 ways to get the same result, and then throw random data at it and see which performs the best. Then implement that into the main application.

Thanks rolfk for saying what I was thinking. That being said if we are talking about a cRIO with an embedded UI thing in theory things work the way you described, but I simply haven't heard enough from other developers, and haven't had enough experience with it to say one way or another if it behaves differently. YMMV indeed. If you are seeing some reproducible issue I'd ping NI on it. It is possible there is a bug in some UI behavior, or optimization that could be made.

While I do multiple user events, the payload is all Variant, which is again how I can get away with building them into an array and registering for them all at once, or subscribing and unsubscriping to events at runtime.. The scripting code generates the VIs that flatten to, and unflatten from, the type def so everything is still strictly typed, but there is a common payload for all events. If there were N events, all with their own registered case in an event structure I couldn't do this as easily. But I admit other parts of the application would be cleaner.

I don't have a link to someone at R&D claiming this to be so, but I know that some amount of resources are freed up by not showing the UI, this includes even minimizing the window. Now the question remains is there some amount of system resources being used up by a UI not being seen and it is just much less than if the UI is normally shown? No idea and some testing would be needed to know. In extreme cases I do things like write code which keeps track of which UI is being shown, and if it isn't, then to not go into the state in the state machine that would update the UI. I've also done this with tab controls where I know I don't need to update the controls in a tab if that tab isn't being shown. Even so I think the most common case for CPU usage on a UI is a graphs with many data points, or very large MCLB with individual cell coloring or properties, and not for individual scalar controls.

This sounds like a stacking issue as ensegre said, but looking at your decorations, they all have transparent centers, and you should be able to click right through them. I'd first suggest moving it to the back as already suggested. But if that doesn't work try using some other decorations and see how they look. I prefer a system looking UI, and so I often use the System decoration box.

I prefer having N user events, one for each message I want, and one for each reply (if applicable). If the data types are all the same (ie. Variant) you can put these user events into an array, and register for all of them at once. You will have one event case handling all of them, but the point is that you can have a publisher/subscriber model where modules (actors) can subscribe to N of them at once.

The way I handle this is the UI event that is generated when the user interacts with stuff, will generate a user event for some work to be done. Then when I want that work to be done anywhere else in the application, all I need to do is generate that same user event. Now the code that my sequence calls, is the same code that my UI calls. This makes debugging sequence issues pretty easy since I can just manually perform the same steps as what the sequence would be doing, by performing the actions with the UI, which would generate the same user events as the sequence would. It is a lot of upfront work, and does feel like an unnecessary layer of abstraction, until changes in how something behaves is needed, and now I no longer need to update both the code in my UI event case, and the code in another case.

Yeah I'd also suggest testing with an explicit open, read write in parallel, and single close. I'm not certain that the Read/Write will force a blocking call but if this doesn't work then I'd suggest the VIG that you call which forces it to occur serially.

Very cool, I suspect there is probably an Idea Exchange item for this somewhere requesting this feature be native. Thanks for the shout out.

Oh fantastic solution. I used TrueCrypt in the past and had forgotten about it. Glad to see it lives on.

Read from text file, or read from binary file. Of course you won't want to read the whole file at once, you'll run out of memory and crash but you can read it in chunks reading N bytes at a time.

I've seen this before, and I've seen it fixed by adding a small delay before attempting to move the file, as some process wasn't quite done messing with it. I don't think the error is descriptive enough and Duplicate Path doesn't mean what it seems. Another suggestion is to try to use the Windows Move DLL call if this is in Windows. http://forums.ni.com/t5/LabVIEW/Is-it-possible-to-move-files-more-efficiently/m-p/859633#M389528 http://digital.ni.com/public.nsf/allkb/576434CD1B659EE386256F04006909AA This invokes the move operation using the system level calls which I've seen work, when the LabVIEW one hit these types of possible edge cases.

Well at the moment I still do something like: C:\Code\SVN\Database Name\Project Name Sometimes there is only one project in a database, so one level is removed. And sometimes I only have code from SVN so the Code level is removed. Under that I usually have these folders: Actors, Builds (which is excluded from SVN commits), Configurations, Documentation, Sandbox, Shared, Support Files, Validation, Verification. I agree that some users don't have permissions on this more root location, but I've had problems with the path limitation in Windows, especially when building applications or VIPM packages, and having things near the root helps avoid this. I guess one option would be to use symbolic links with mklink or junction to map a path deeper in the public space to one closer to the root. I haven't used it yet but the public documents path would probably be the more correct location for this type of source that all users have access to: C:\Users\Public\Documents Here is a Too Damn Long meme that I've probably made 4 times by now but can never find it when this subject comes up, which honestly is a bit inflated, but does reflect the level of nested folder structure I've seen used in the past.

Attached is an updated version that I think does the same work but in a less Rube Goldberg kind of way, but I think this can be improved more.

Well did you read the description of the error, or look at the data types of the terminals and indicators? Your output is a 2D array of a cluster, and in that cluster is a 1D array of doubles. The Waveform graph can accept multiple data types, but not this. If you read the help on the waveform graph you'll see for a single plot you can either provide a waveform data type, or a cluster with the x0, deltaX, and Y values. You can also have multiple plots by providing a 1D array of these values. But honestly after all of this descriptions of what is what, the simple fix is to right click the for loop tunnel and select Tunnel Mode >> Concatenating. This makes sure the 1D array going in, doesn't get indexed into a 2D array but instead concatenates them. This can be wired to the graph on its own. Also there is a bunch of inefficiencies in that code that can be fixed with some for loops. Is this is how it is presented in the NXG example? Like that for loop will only ever run once.

I was just referring to the fact that the TDMS write function should be called as seldom as possible. So in your case you want to call it twice, once for the Time Channel, and once for the Data Channel. Even if you are enqueueing 1000 elements, and only logging every 10,000, then you should only call the TDMS write twice, for every 10,000 samples. There is a race condition. If your top loop stops, it will destroy the queue. If the bottom loop is waiting at a dequeue when this happens an error will be generated, and then the file close operation won't work properly (since TDMS ref wasn't wired through) and then you won't display the data in the Viewer either. Pretty minor, and probably won't be seen. I'm pretty sure OP meant 1000 samples/sec not files. The posted VI only creates one file.

Norm posted a while ago on this neat string implementation and how it can be used to do things like translate an image by shifting all of the components of the image as strings by setting new offsets. Very fascinating and I've used it several times. Sorry No I haven't seen this memory issue with the picture controls I use.

So I see that you acquire 1000 samples, (not files) and then log those 1000 samples in a separate loop. I'd recommend waiting until more data is in the buffer before attempting to write. Those write operations are probably what is slowing you down, and if you can wait until there is 10,000 samples, or more waiting in the queue, and then call the log function just twice (once for time, once for the data, you will probably be better off. That being sadi I don't think I see anything really wrong with your VI, except maybe that there is a race condition on stop that might not close the TDMS file reference properly. Wire through the TDMS reference through the error case.

Michael did his magic again and it should be fixed.

Was debugging enabled on the VI when it was ran? I assume probing the cluster wire would force the string to be copied into another memory location. Anyway that does sound good since one VIM that takes a few minutes to write could perform some of the same functionality as the XNode. Still would require an unbundle by name, but a Read-Only DVR function could be pretty useful. I think I made one during the 2017 beta replacing the icon now that I think about it.

Oh sorry it was renamed Maleable VI, official feature in 2017 but was implemented as a custom XNode shipped with LabVIEW since around 8.2. http://zone.ni.com/reference/en-XX/help/371361P-01/lvupgrade/labview_features/ VI Macro discussion before 2017 made VIMs official. https://lavag.org/topic/19163-vi-macros/ It has some shared functionality with XNodes (type propagation for inputs and outputs) but other custom things like right click, adding removing terminals, and changing node size and icon at edit time can only be done as an XNode, not a VIM.