hooovahh

Well it is possible but a pain. Is there a minimum version of LabVIEW you want to support? I think that function came around in 8.2 or so. What I'd suggest doing is create a VI with just that function in it, and save it in the lowest version of LabVIEW you want to support. Then ensure each version of LabVIEW installed is configured to use VI Server from localhost (basically make sure VIPM can connect to each version). Then you can have a VI that opens a connection to each version of LabVIEW installed using the Open Application Reference function, then use the Open VI Reference passing in the path to the VI you saved earlier and using VI Server run it. I created a tool a while ago that sits in your system tray and allows you to launch any version of LabVIEW installed. It also allows you to abort all VIs running in all versions of LabVIEW and it uses this technique by having a VI saved in an older version of LabVIEW and embedded in another VI, and then runs this VI in every version of LabVIEW installed. The source for this can be found here with the topic on LAVA here.

Any improvements you can make are appreciated. I clearly don't know much about the web page side of things, I mostly was able to get done what I did with a lot of googling. Plenty of room for improvements, but I am using it on a real project and it meets my needs. As for the future of LabVIEW are you talking about the Tech Preview? http://www.ni.com/en-us/support/software-technology-preview.html WebVIs and porting the runtime engine to Java Script are things that have been announced, but the timelines mentioned (or not mentioned) makes me think it will be business as usual for a while longer. I'm not saying it isn't cool, and I'm not saying it isn't going to replace, or deprecate some of the work we are doing here, but I am saying you can use the code posted here today for free to create interactive webpages, and who knows when you'll be able to do the same with native NI technologies.

The "easy" solution as far as I know is the one already described, where you can place a transparent path control on top of your graph and set it to visible when your VI is not active (or mouse leaves the window, I'm not quite sure what works best). Then when you drop a file from explorer it will be dropped on the transparent path control, which generates the Value Change event, and from there you can get the path of the file dropped. It is not ideal, and if there isn't an idea on the Idea Exchange for this to be improved yet, I suggest making one, I'd vote for it. I wouldn't recommend using the Windows Queue API. With the advent of x64 versions of Windows several of those functions don't work, or will work most of the time, but won't work some times.

Set the front panel window to the window to hidden using the Invoke Node on the VI class (Front Panel >> Open - State). And in your built EXE you may need the HideRootWindow = TRUE in the INI of the application. My LabVIEW Tray Launcher uses this code to be minimized to the system tray, you can checkout the source here.

See I didn't realize this was a limitation. In my situation LabVIEW Libraries are the main container for code modules, not classes and this appears to be a limitation of LabVIEW classes which is why I've never seen this. So in my situation I can open both Windows Main, and RT Main VIs at once, and run them independently, or develop in either context with few issues (one being you need to sync code after making changes). Here is the article put out by NI (which was found in the idea exchange) that describes the issue with classes.

Why is this the case? If you have two different types of targets in your project, you have the code added to each target, and can open them independently right? I guess I haven't developed on two different RT systems at once so I don't know I just assumed it worked like the two targets I have in Windows and RT, although those have different top level VIs which might make the difference.

So it seems everyone here at least is passingly familiar with the issues I'm describing, but I wanted to document it a bit and I did this with some screen recording software. I also posted this on the NI thread that is partially discussing this: So last night I uninstalled all LabVIEW 2015 code, restarted several times, cleaned things up, and reinstalled 2015 and the RT module. Today I still have some recompiling issues when going back and forth. Here are two videos (because they are limited to 5 minutes using jing). The first shows opening a project, opening the Windows Main, showing the compile window, then opening the RT main showing the compile window, then resave everything, close the project and reopen. The second video shows re opening the Windows and RT main showing that files have to be recompiled yet again. Part 1 Part 2 So separate projects is the solution people are using? Man that seems like it could be a pain. I'm going to continue having it in one project for now. I have yet to see the brokenness but running issue. Seems like there are many issues with developing for multiple targets, and for RT in general. Honestly I'm surprised because like I said RT development has been a thing for around 10 years now.

So I decided to make a new thread on the dark side because this weirdness keeps getting weirder. It now does it on multiple versions of LabVIEW, and does it on the Place Palette Object On Cursor method.

Crosspost Honestly not sure which thread has more discussion. (BTW Shaun I gave you a like)

Nope, I stay logged in, Chrome 52.0.2743.116 (also Chrome is on version 52! Do they just increment it for the fun of it?)

Well this seems like a real issue, and one that people must have been struggling for for the past 10 years or so. Yes I am a big proponent of reuse, banging that reuse drum all I can. Which is partially why so much of my code is reused between targets, much of it resides in user.lib, or in libraries that are project specific but still reused between targets. The conditional disable diagram is used pretty often. Many templates used are the same between RT and windows targets, with slightly different things like timeouts and polling control values on RT, and disabling other fancy UI things when on RT. Some of the VIs that it shows having to recompile over and over do have conditional disable diagrams, but some don't, some are reuse, some aren't. Also last night I deleted my object cache, and reopened the project new. The issue still remains, that if I open the RT target some VIs need to recompile, and then if I close and reopen the Windows target those same VIs need to recompile again, but oddly the number of objects that recompiling is reduced down to only 22 VIs, making life a bit easier.

Is that a joke? Cause I like that.

The files I see it recompiling don't have a common theme other than the fact that they all seemed to be part of polymorphic VIs. I saw some from OpenG, which don't have the separate compiled code on, I have some from our reuse library which do have separate compiled code on, and I saw some that are unique to the project which happen to have separate compiled code on. I checked out my compiled cache file and it is almost 300MB, that feels a bit large so before I leave today I'll try deleting it, and having it rebuild for primary project I'm working on. Separate projects is an option for this design, but like you said I'm not sure it would fix my issue, and might actually cause some more. I do like how a project knows that I've been editing some code for one target and haven't synced my changes to the other. I'm not sure that would happen between different projects.

Examples like this are hard to give, since they often rely on multiple built EXEs, the right run time engine etc. But the basics of it, is you can use the Open Application Reference to open a session to LabVIEW, or a LabVIEW built EXE, if the settings and port are enabled in the INI file for LabVIEW or your application. Once this is open you can use the application reference to do stuff like list all VIs that are open in that application. From there you can use the Open VI Reference, using the application reference from earlier, and the VI name (or VI Path). Then you can use functions like the Traverse For GObjects to find objects in that VI that have the label and type you are looking for. There is also a function in the Hidden Gems package that can find object references by name. You can then cast these object references to their More Specific reference, and if that class type is a control you can use the property node Value Signaling event on that control reference giving it the data type associated with that control. Did I lose you yet? This is why I suggested editing your program to support the functionality you want, rather than try to augment it externally. Neither are easy, but one is more difficult than the other, and one is more susceptible to breaking if your code is updated, and your tool isn't.

So lets say I have a single project, and in it is two targets, a Windows host, and the RT. Many of the libraries I use in the Windows side, I also use on the RT side. But I think that this is causing lots of unnecessary "Compiling" of VIs over and over depending on which target I'm open the code from. Here's an example. I have a Windows Main.vi, and a RT Main.vi both under their appropriate targets. If I open the Windows Main.vi it opens relatively quickly, and loads about 2000 VIs and shows the main. But if I then open the RT Main.vi, it goes through and compiles about 200 of those VIs taking several minutes to open. So after both are open I perform a Save All, thinking whatever it needed to compile and do it should be done with. If I then close the project and re open it, and then open the Windows Main.vi it has to recompiles those 200 VIs presumably for the new target, and then if I open the RT Main it has to recompile those 200 VIs again. Is this how it is supposed to be? Every time I reopen a VI on a new target am I supposed to see it recompile for that target back and forth depending on where it was opened last? The project has a mix of VIs that have separate compiled code on and some with it off. Not sure which is better for this. My computer is relatively powerful, but lately doing LabVIEW development makes me feel like I'm using a 10 year old PC. Everything about my computer seems fast except LabVIEW development. Is there tips or tricks, or options I should be using to help make my LabVIEW development more responsive, and require less recompiling when switching targets? EDIT: It seems that the VIs that need to recompile all the time are VIs that are in a Polymorphic VI, so the majority of them are reuse and OpenG VIs. Double Edit: It seems this thread from an older post on LAVA claims that the compiled cache has separate entries for a VI on multiple targets, so I'm not sure why these VIs need to recompile every time...

Using another LabVIEW program control values can be changed easily. Just open a reference to the VI, get references to the controls, (usually by name), and invoke the Value (Signal) method on the control, all using VI Server. A better solution might be to add functionality into your application to perform automated testing, which invokes a state machine.

Well I started wiping my INI settings and found that removing the QuickDropKeyboardShortcutMappings line fixed it, but removing just the QuickDropPanelShortcuts and QuickDropDiagramShortcuts didn't fix it. Still LabVIEW doing weird stuff, but just to me I guess.

So on the topic of weird LabVIEW stuff I had a few today. I noticed a couple my quick drop functions not dropping what they should be. Now this might just be a result of my custom quick drop shortcuts, but I don't have any shortcuts for the Copy or Delete functions. I recorded my oddness here. Anyone seen anything like this?

NI themselves do not record sessions, all recorded sessions are from volunteers who bring their own equipment, and provide their own bandwidth. Since Mark could only be in one session at a time, he only has the sessions he attended available. Apparently the FTP has both videos from Mark, and Shane (Intaris). All the videos numbered 001-017 were recorded by Mark The videos numbered 101-112 were recorded by Shane As for other recordings they are all done by individuals and you'll just have to talk to others who choose to record sessions. I haven't seen any posted online yet, other than the ones already posted here.

Well that sounds terrible, but also something I can't say I've seen. Do you have a simple VI that exhibits the issue that can be ran to reproduce the issue? What OS and LabVIEW versions?

So I'm not changing the calling VI for the fun of it, and I believe I'm doing it in a safe-ish way. I know it isn't conventional but it has a purpose. And the intent is to leave the VI the way it was found when the user right clicked. So the the purpose of the code in the for loop is to detect if the disabled structure that was right clicked was a normal Disabled Diagram Structure, or a Type Enabled Structure. I could only think of two ways to determine what type of structure was clicked on. Either export an image of the structure and do some image analysis on it since the borders differ, or the more obvious solution was to try to set a case to be enabled and then see if it actually gets enabled. If it doesn't then that means the structure is a Type Enabled Structure, and if this is the case then I don't want the menu to show up to replace it with a Type Enabled (because it already is one). As for the creation and removal of frames. I thought of a case where a structure exists with only one frame that is already enabled, how could I test to see if this is a DDS or a TES? So if there is only one frame, then I add a second frame, try to enable it, and then delete it when I'm done, so the user couldn't have right clicked that frame, because it didn't exist until after entering the builder VI. So if I enabled a case for a test I will enable the original one back, and if I added a frame I will remove it with the goal being that the VI is untouched, with the only purpose being to detect what type of structure it was the user clicked on. But to be fair I can think of another solution. I could copy the structure to a new temporary VI, then do this test on the newely pasted structure, but that sounds slower, especially if there are N structures to evaluate. Maybe the image manipulation method would be better. I suppose it is too much to ask for a way to detect what type of structure it is through a private method or some super secret tag, or something? Edit: It seems my other method might not work either, is getting the image of a object resetting the undo stack as well?

Sure thing, attached is a somewhat crude approach that isn't easily scaleable but I think it is pretty simple. You have 4 shift registers for the data to log, and 4 more for the data in the graph instead of chart which has the benefit of having it's own buffer, but you have less control over it, like when it gets updated. If you have more than 30 samples of data log it, this should be roughly once every 500ms. This can be increased or decreased as needed. After getting 30 new sample the data is appended to the end of the graph data, but if more than 1000 samples are in a graph, only the last 1000 are kept and shown. Also the graphs will only be updated at most every 250ms. Then after it stops executing the samples in the buffer that haven't been logged yet, are logged. This will be samples between 0 and 30 that haven't been logged because there wasn't more than 30 at a time yet. I also added a feedback node to measure the loop rate and put it on an indicator and chart. Removing this will likely cause better loop rates, but if I were you I'd be curious what rates you get, and maybe remove this code once you are sure it is working well enough. TDMS_Logging_Simple_4chan hooovahh edit.vi

As far as the code goes I think it is pretty simple, and looks right. You have continuous sampling which is good, multiple finite reads is something I wouldn't recommend here. I might suggest a few improvements to have better performance, not that what you are doing is wrong. But I notice you are reading 28 samples at a time, and your DAQ session is setup to sample at 1612.9 Hz. This means your loop rate will be no less than 17ms per iteration. This seems relatively fast. Imagine if updating the graphs, and redrawing them, and logging the samples to disk takes 20ms what will happen? Well samples won't be lost, right away it will just lag behind, and the data you log will be more and more from the past, until your DAQ read buffer fills up and then you'll get an error and stop. Also even if you don't full the buffer and error out, clicking Stop will stop and the data in the buffer that you haven't read out yet won't be logged either. To help with this you can choose to not update the UI with every iteration, but instead just update it a couple of times a second which will probably be enough for most users. Also instead of logging each sample as they come in, you can build a buffer of samples, and then when you get so many, log them at once. The overhead of logging single point data to a TDMS can be larger than the payload of data to log. This may mean a few changes with shift registers to keep track of the data in your own buffer, and changing the charts to graphs. Of course a more simple solution if you can get away with it is to take more samples at a time, or making a seperate loop where you log, and update the UI.

So I'm apparently terrible at handling the undo stack but I can detect when you right click a TES or a DDS. All you need to do is attempt to change the enabled case away from the current one. A TES can't have an arbitrary case enabled, it will always enable the first one with no broken wires. So with scripting you try to enable case 1 and if it doesn't get enabled then it is a TES if it does get enabled it is a DDS. I tried fixing the undo but I just couldn't figure it out. Currently right clicking on any structure will wipe away the undo stack. I tried doing a begin and fail but an undo begin has already started as part of the right click API so I'm not sure what to do in that case. Replace with TES.llb

I haven't used one personally, but the answer I got from NI was yes. Things like right click events, mouse down, mouse up, etc in an event structure work, but I think they only work from the embedded UI, and not from the remote front panel connection if you are connected from a host.