hooovahh

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.

So cool, I would definitely use an XNode that does this. Yes the VIM could work with the issues already mentioned, with copying the whole cluster in memory just to grab one element. Props for the idea, and DTaylor's suggestion.

You say it is being ran in a different context, can you provide the context that it needs to be ran in? I'm having a hard thinking of a way to test this. Are you saying you have one EXE running, that the variant data is being passed to from another? Still I would expect the code to work properly since the LVClass.Open is providing the full path to the class. Is it possible the error is coming from some other place? Does this class not have a front panel in its private data? I admit I don't know what happens to classes once they are put into an EXE and would wonder if that is stripped out. Edit: Oh the get class by name will only work if that class is in memory. Just like referencing a VI by name only works if the VI is in memory. If you are loading from a separate context it won't be in memory. You need to provide the path to the Get LV Class Default Value and have it return the class. Then the rest should work (maybe)

I usually try to call it a Quick Start Guide, to help set expectations low. Then if things are missing the user just shrugs it off and figures there is a more detailed manual (which there will be when I finish it). I do a decent amount of documentation as I go, which probably isn't efficient since I'm often updating how things actually are. I don't really find the documentation part dragging on. Oh and I've been asked how long it will take to get a program up and running, and they will sometimes qualify it with. "How long will it take to get 90% of the program done" and I'll say something like "In two weeks I can get the first 90% of the program done, and then all that's left is to do the last 90%."

I definitely get what you mean by burning out. Even on project that is long, it is easy for me to lose interest. With LabVIEW it always feels like getting 90% complete is pretty easy, quick, and there are plenty of results to see. That last 10% seems to take so long to wrap up, and so much work that I find myself just putting it off and doing other work instead. Of course when timelines are involved, and you need to actually work on it, it is hard to stay motivated. Maybe its hard because I enjoy doing LabVIEW and it doesn't feel like work when its fun, but when it isn't fun it is a drag. For large multi member projects it gets a little better since you can all share in the accomplishments of everyone, so staying motivated is easier. From a program management stand point I've seen plenty of projects eat up 8 or more developers full time for months (years?) more than originally planned due to poor management, and unclear requirements. Those are pretty bad sometimes too because the moral of the team is poor. Constantly getting beat up, while working hard can make good people want to quit.

Man I love sysinternals. One suggestion I was going to say was you could try looking into parent child window relationships, and then set the whole parent window to be non active. But in typing this I realize this wouldn't work because in a normal window relationship the desktop is the parent, and so I'm guessing you would have the same problem. I'm not sure there is much you can do for this one. Maybe someone at NI will have a suggestion.

I looked at my code for setting extended style and it is the same as yours (other than mine runs in any thread which I think is a bug). And it sounds like the call is functioning properly for other windows. So this makes me think this is something specific to LabVIEW and how multiple window management is done. Here might be a useful test. Can you built a separate LabVIEW EXE that is your OSK and have it work properly on LabVIEW.exe or other build applications? I suspect this will work but don't know why it wouldn't work from within LabVIEW and the same application instance. I'm guessing this is just one of those instances where LabVIEW and NI are doing something non standard that is breaking normal functionality.