hooovahh

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.

So glad to hear that. I swear I looked into this less than 4 years ago and found the array searching code. I made the Variant Repository code because I wanted something light weight, and fast. I wouldn't have made my own if CVT at the time met my needs.

Well some people started using Bing, I never used it but I hear you can Google with bing. I hear it is a good website for doing internet searches, I know this because I googled it.

So in a presentation about XNodes I was asked a question about what were the valid "Reply" options for an XNode ability. Some abilities have a reply as a 1D array of string and it appears to work like a QMH where you provide a list of states to go to and it does them one after another. I didn't know the answer but I knew scripting could help. So I scanned a bunch of XNodes for what strings were on the block diagram going to the reply and here are the abilities, along with the reply strings I've seen used. AdaptToInputs UpdateTerms UpdateImageAndBounds GenerateCode ForceAdaptToInputs Copy GenerateCode UpdateTerms UpdateImageAndBounds FailTransaction DoubleClick FailTransaction UpdateTerms UpdateImageAndBounds GenerateCode GenerateCode PreserveUserCodeGUID GetError Message UpdateTerms UpdateImageAndBounds GenerateCode FailTransaction ForceAdaptToInputs OnFontChange UpdateImageAndBounds UpdateTerms OnOperateClick UpdateImageAndBounds GenerateCode OnResize UpdateTerms UpdateImageAndBounds GenerateCode OnDrop UpdateTerms UpdateImageAndBounds GenerateCode OperateClick ShowMenu RefeeChanged GenerateCode UpdateImageAndBounds UpdateTerms RespondToDrop GenerateCode UpdateTerms UpdateImageAndBounds SelectMenu UpdateImageAndBounds UpdateTerms GenerateCode FailTransaction ReplaceSelf Size UpdateImageAndBounds UpdateTerms GenerateCode UpdateState GenerateCode ForceAdaptToInputs IssueWarning UpdateStateWithRef UpdateImageAndBounds UpdateTerms GenerateCode ReplaceSelf So the unique values that I've seen put into the Reply are the following. I am unsure if only some abilities only support some replies. UpdateTerms UpdateImageAndBounds GenerateCode ForceAdaptToInputs FailTransaction PreserverUserCodeGUID GetError ShowMenu ReplaceSelf IssueWarning As for what do these do? Well some are more obvious than others, but here is some text I found in one of the XNodes that helps: FailTransaction: LabVIEW will abort the current transaction. This will avoid putting transactions in the undo list when the user just hit cancel. GenerateCode: This will cause a type propagation if appropriate, and will cause the XNode to GenerateCode when type propagation is run. UpdateImage: LabVIEW will call Image and invalidate the XNode. UpdateImageAndBounds: LabVIEW will call Bounds and Image and resize and invalidate the XNode. It will not call Size. Size is only called if the user resizes the XNode (so that you may update your state and return this reply). Make sure that if your terminals need to change size or location, you also return UpdateTerms. This reply will set the transaction type. UpdateTerms: LabVIEW will call Terms and create, delete, and move terms as necessary. ForceAdaptToInput When mutating an old, unconfigured Express VI, we need to ForceAdaptToInputs before code gets generated. AdaptToInputs used to always get called before GenerateCode. But that is no longer the case in LV2011.

Perfect, then just make a shortcut for "Chooser" or "CH" or whatever you want, now you can type that instead of traversing the palette. BTW I know you have tough skin, but I don't want to be unnecessarily harsh or snarky. All the benefits of 2009 you mention are things that I have no interest in. But the benefits I've seen in the last 7 years are things I use daily. This is probably short sighted, but if NI decided to only support Windows, and only support 64 bit, I think they would benefit overall. They would upset a few percentage of the user base, but cut out a decent percentage of regression testing and development. Now if I were in that few percentage of the user base I admit I wouldn't be happy. From one year to the next I agree with you about upgrades. If you are on 2009 no need to pay the multiple thousands of dollars to upgrade to 2010. But if I were on 2009 I could justify the cost of upgrading, assuming I don't have the limiting issues you mentioned.

So the advanced user track seemed to be a pretty good success but maybe I'm biased. The user track presentation content can be found on the NI Community here. Or possibly in the NI Week Content subforum, and of course Mark was awesome enough to record all the sessions and has it's own thread here on LAVA. If you attended any of the sessions (or any NI Week session) I encourage you to give feedback wherever NI takes NI Week feedback. I word it that way because I've heard reports that the session surveys had issues.

Okay now that LabVIEW 2016 is out, and the Mac version of 2016 is also out, I went and downloaded these VIMs that were in the user.lib. I hope I'm not doing anything wrong in posting them here, because these are files that are just available in the evaluation install anyway. When asking around the unofficial name for this new structure that automatically enables which ever case has no broken wires is the "Type Enabled Structure". It looks and behaves very similar to the disable diagram structure but specific cases cannot be enabled by the developer, and the border is a bit thicker. As always with unofficial features, don't be surprised if it changes functionality, or support, or gets removed with new versions of LabVIEW. My presentation on XNodes, and VIMs is available here, under the 2016 Advanced User Track. 2016 User.lib Macros.zip

The CVT is extremely slow (is that an overstatement?) and the variant attributes look up table will probably be on the order of 100X faster (no test at the moment). I've been using my Variant Repository (which uses Variant Attributes) for a few years now for messenging APIs because I figured it was the fastest solution. This improvement just makes it even faster and I'll likely update my Variant Repository to use the IPE instead.

That sounds like some vary valuable feedback that I'm sure NI would have appreciated in February when the beta opened... But to be less snarky some of the complains you have were brought up in the beta, I especially share the comment about wasted space. The Drag and Drop however I don't have much of a problem with. I have yet to notice an impact on my development style, if anything I think it is an improvement but that's just me. Honestly 2016 isn't full of major changes. The addition of Channel Wires (officially) is one of the few major improvements but it isn't doing anything functionally you couldn't have done before. The other major point I remember is the greedy or not greedy selection (I think it is shift). Beyond that the inclusion of the Type Enabled Structure (no name officially) that Jeff K eluded to is neat, but of course has a limited use. Having VI Macros be slightly more official is nice too. Just name a VI, a VIM and drag it to your block diagram and it works, no INI keys needed. Of course some INI keys are useful for debug. The initiative to have more support for 64 bit has continued too with a few toolkits I actually use. There is also the IPE structure for Variant support, of which I haven't benchmarked yet but intend on using. I remember hearing a few new right click menu options were added, like convert to color box and back for constants. There are of course other features that I heard about, but are pretty specific and fixes or improvements for hardware. In general if I were an independent developer and needed to spend an extra few thousand dollars for 2016 I wouldn't justify it given the preview program I hope you now understand maybe a bit why releases have been light on the new features. But if I were stuck on 2009, I could justify the cost of upgrading. Far too many of my applications use some newer features that would make life a bit of a pain for sure. Oh and to answer your original question I don't know of any config or INI setting that changes the functionality.

LAVA has won an NI award for LUGnuts at NI Week, the largest independent online user group. Thank you everyone for making the online community something to be proud of.

Yeah if you default to one you are going to upset one group of people or another. I would guess NI's thoughts were it you wanted to read a control just use its terminal, and a developer would be more interested in writing a local variable. If you aren't CTRL dragging yet you would be. I is a bit odd that that operation does something different than a copy paste but I like it.

OOOOhhh, yeah I've never used that feature but it seems to be a feature of the Waveform Chart and not the graph. http://forums.ni.com/t5/LabVIEW/How-to-stack-plots-using-Waveform-Graph/td-p/329917 The good news is a Mixed Signal Graph can look and behave in a similar way. Graph Test 2.vi

I still don't know what you mean by upper and lower stack, is this a graphing term I should be familiar with? Do you mean two separate Y scales? Cause that can be done as well with one on the left and one on the right. This was also why I asked for a picture since I wasn't sure what you were talking about. Glad you seem to have something working or close to it.

If I understand you right you want this. Here I did it with a Waveform Graph, but it could be done with XY, and probably a chart. Graph Test.vi

I don't think what you are asking is too difficult, but I'd rather see a picture of what you are trying to accomplish. So I understand where the 6 lines come from, A Minimum, Maximum, and Value for two separate measurements. But what are the 2 stacks? I think this can be done pretty easily with an XY graph but I might be misunderstanding your needs. Also keep in mind that the XY graph also has the ability to place static images on top, or behind graphs using the Plot Images property node. With this you should be able to also overlay anything you might want on the graph that isn't immediately respectable with XY data.

I don't understand. Are you writing CAN or reading it? Are you using NI-CAN or NI-XNET? What is your hardware, is it NI based even? Post your code. That being said I've never had any problem reading or writing CAN frames at different rates in any API. Oh and if you are new to LabVIEW here is some free training: NI Learning Center NI Getting Started -Hardware Basics -MyRIO Project Essentials Guide (lots of good simple circuits with links to youtube demonstrations) -LabVEW Basics -DAQ Application Tutorials -cRIO Developer's Guide Learn NI Training Resource Videos 6 Hour LabVIEW IntroductionSelf Paced training for studentsSelf Paced training beginner to advanced, SSP Required

Yeah I have a hard time trying to figure out how to use this function and never have, nor have I known anyone to use it. So I can't say if it is a bug or intended.

I would love that however VIMs (as you know) aren't really a supported and documented part of LabVIEW. OpenG has generally been seen as stable, and well tested. If you start adding unofficial technologies in it I would be very concerned that the stability can't be guaranteed. But yeah this is something I think I'll do for fun some day, just re-write and update the OpenG Array tools as VIMs. Especially with the new structure Jeff mentioned which would allow for one VI to handle the scalar and array permutations.

Well it's been about 7 years since any update was made to the Array package that did much, and the last fix was 5 years ago. I can't say it is under no maintenance but if it is being supported I would say don't expect to see changes happen quickly. I'm sure it can be frustrating but there are plenty of people who don't monitor these boards daily. JGCode last posed on the forums in February and he seemed responsible for that fix 5 years ago. Volunteers like him have a work life, and a home life. If you want to discuss OpenG issues, this is the place to do it. If you want to see OpenG releases, please be patient. Personally I would love to see especially the array package revisited. There are plenty of optimizations like inlining, and conditional terminals that could make array operations much more efficient than they were for this code that was originally written in the 5.x era.

Oh well you just haven't researched it enough! (just kidding of course) I mean you can do plugin architectures without OO but in LabVIEW I can see that being a bit more difficult with needing to enforce or check for types, and all that is involved with adding new types. Having seen plugin architectures with and without OO in LabVIEW I would say the simple ones tend to be over complicated by adding OO, and the complex ones tend to not scale well without OO.