hooovahh

Crosspost

Oh well sorry I showed you a powerful tool that is something to be cautious about. The source is quite easy, just look at the template. All that is really needed is to set the number of cluster elements to the right number and it should work as a non-xnode which can be invoked as a merge VI. Just don't forget to set that number of cluster elements everytime the cluster size changes.

Yeah as others have said. The biggest ones for me are: Right click menus API, and a bunch of new right click menus built in TDMS defrag is faster, with an optional progress bar Perform TDMS operations on a file in memory, instead of on disk Delete data from a TDMS file on disk Hyper links in comments on the block diagram I think Quick Italics and underline (am I imagining it?) And the super secret feature, the Asynchronous Wire Faster executing code (I haven't tested) There are others and I forget way more than I remember but still for me this is a decent list when compared to the things I cared about most in 2014.

Sorry to answer an off topic question but I found more information on a comment. I just learned of a way to get an event generated on minimize or maximize. You can then choose to not update the UI if you have lots of power updating it. The event window resize is generated on minimize. You can then use the property node on the VI to get the front panel state. It has the previous state in the event but not new state for some reason.

So I talked to John about possible ways to do this and what I suggested was something like zip all external dependencies. Then send that zip streaming the binary representation of the zip file. Then keep the zip on the host and use it again if that same zip is attempted to be sent by looking at MD5. Then extract the zip to a temp location and run it. This way it doesn't matter what is in the zip (llb classes ppl) and it can run in an exe if you choose to include VI.lib dependencies. Will it work? No idea but I can't see why not.

BTW in 2014 a new feature was added for finding and reviewing enum changes like this.

On mobile so quoting fails me. I never have an actor be killed unless they all did. But if I want an actor to restart I send a message to it telling it to restart and it is in a state machine so it just goes to the data cleanup case then the macro initialize.

Not sure if you were talking about me or not, but I had forgotten that I made such a tool, which I never got to finish here: https://lavag.org/topic/16003-another-create-polymorphic-vi/ If I were to write that again I would have done things differently, but the tool mostly works. Give it a template, tell it what controls to replace, with what other controls, and then a bunch of VIs were made for each control type you picked.

You should ask for generic VIs, or XNodes . Okay but seriously the options today are to use polymorphic VIs, where you write your code to work on each type of array you expect, and have it auto pick the right one based on the type wired to it, or you work with variants and expect the user to convert the variant back into the array of their type that they put in. LabVIEW is a strictly typed language, and there is no easy way to do what you want in a scalable way. For examples look at OpenG. Their array tools work with multiple data types because of polymorphc VIs, but if you give it an array of a type def there isn't a VI for, it uses the array as a variant and you need to convert the variant back into the data type you gave it. A very experimental, not official technology is XNodes which NI uses to accomplish something like this. If NI ever officially releases XNodes I would recommend you use them, until then you're stuck with variants, and polymorphic VIs. Here is an example of taking the OpenG array tools and turning them into XNodes which accept any array data type. Again, not recommended yet.

You know one thing to think about is no matter what type of changes are made to error redesign, there is going to be more overhead than the current implementation. Having multiple errors in a history, or timestamp of when the error occurred, or having custom dialogs with images and text, variant attributes for meta data, or using classes to override features. All of this is going to have more VIs to load into memory, and more processing power to perform actions. And someone, somewhere is going to complain that they don't want all of that extra fluff when the 3 element cluster (or just the code) is all they need. Especially on RT targets where performance is always trying to be optimized. I think the benefit (if done right) will out weigh the cost, but maybe this is one reason why NI is apprehensive to change.

Sorta. Mark does this out of the kindness of his heart, and his enthusiasm for the community. Things happen and he might not be able to record a session, or the camera might break, or a presenter might ask him not to. There are reasons Mark might not be able to record and upload the sessions and I think having him publicly state which sessions he is going to attend might be unfair to him. That being said I sure hope Mark is able to record some of the sessions I can't go to. As usual there are a bit too many I want to go to on Thursday, and other days are lighter. If you do meet Mark, be sure and buy him a beer at the BBQ or some other event, he deserves it.

Yeah the original package you couldn't install is just a package that has nothing to it, except a dependency on the other packages. Sorta like a main release, made up of all the smaller releases. The new main release isn't made every time a smaller release is made, but instead once a significant number of updates have been made. It looks like it's been a while since there was a new release, so attached is a VIPC that should contain the updated versions. Note that the packages themselves are included, so internet is needed to get the packages if they don't exist in your cache already. OpenG 7-30-15.vipc

What version of VIPM? If a package is made with VIPM 2014 you have to use 2014 or newer to install it. 2014 added some features that aren't backwards compatible, and don't have a very useful error. But that being said I wouldn't expect OpenG to be using this newer format. Can you install the individual packages that library depends on? OpenG Application Control Library >= 4.0.0.5 OpenG Array Library >= 4.0.0.9 OpenG Boolean Library >= 4.0.0.7 OpenG Buttons Library >= 4.0.0.7 OpenG Comparison Library >= 4.0.0.3 OpenG Dictionary Library >= 4.0.0.4 OpenG Error Library >= 4.0.0.12 OpenG File Library >= 4.0.0.20 OpenG Large File Library >= 4.0.0.3 OpenG LabVIEW Data Library >= 4.0.0.7 OpenG LabVIEW ZIP Library >= 4.0.0 OpenG MD5 Digest Library >= 4.0.0.5 OpenG Message Queue Library >= 4.0.0.15 OpenG Numeric Library >= 4.0.0.5 OpenG Picture Library >= 4.0.0.13 OpenG Port IO >= 4.0.0 OpenG String Library >= 4.0.0.6 OpenG Time Library >= 4.0.0.2 OpenG Variant Configuration File Library >= 4.0.0.5 I also see a conflict with these packages, but I would expect VIPM to prompt you saying it will uninstall them if you continue. nilib_rectangle >= 1.2 ogmnu_appcontrol_plus >= 0.3 ogmnu_classic_sync >= 2.5 ogrsc_dynamicpalette >= 0.19

There is this thread on it. https://forums.ni.com/t5/LabVIEW/Remove-the-stacked-sequence-structure-from-LabVIEW/td-p/2680191 It's a fun and long read.

Just use the invoke node on the Sequence reference, and use the Convert to Flat Sequence. The two objects don't belong to the same direct parent class so methods on one don't always translate to the other. In 2014 the Stacked Sequence structure was removed from the palette, it is still supported just maybe close to being deprecated.

Never mind I made the VI. Attached is a VI that makes a new VI, sequence structure, VI invoke node, boolean, and wires the boolean to the structure. Make Sequence Boolean Invoke Node.vi

Okay I think I understand what you are trying to do, can you post the scripting code already that does the sequence and invoke node. EDIT wait where would this boolean be wired to? just the sequence structure not the invoke node? Because that invoke node doesn't have a boolean input.

TLDR: Delacor has some cool stuff, and I had some cool stuff. Wow very cool Fab. I'm starting to wonder if everyone has developed something like this in secret and just not published it. I didn't really get around to getting permission to post my version publicly, but I talked about it and even named it Glued. Lots of Glued's functionality is mirrored in your QMH but here's a few of the differences I see so far. DQMH and Glued both had scripting for adding new modules, and messages. Glued didn't have one for removing messages so good on you. Glued also had the ability to create global messages, which is a message all modules listen and react to. This makes messaging 1:1, and 1:N, I never came up with a good N:1 scheme but then again I didn't really need it. When doing a Do Something Wait for Reply, you use a user event to send the message and a notifier to wait on the reply. I found this to be a bit problematic when doing a shutdown. If I have a sequencer running that is requesting analog data and waiting on the reply, but at some point the user closes the software. That close is going to be a global event telling the whole application to shutdown. If my analog actor loop shuts down, but my sequencer doesn't get the request to shutdown, before requesting a read, then all actors will shutdown except the sequence, which will be waiting for the reply from the analog. In Glued a user event sends the request, and a user event is used for sending the reply. The reason for this is because when waiting for the reply we also register for the quit event. This way if the quit event is fired while waiting for a reply, we will also stop waiting for the reply and shutdown. DQMH has a timeout where Glued by default had a -1 timeout and with this change I didn't see any kind of issue. For the messaging there are essentially three functions you need to have. Sending the request, convert the request variant to the request type def, and send the reply. There were also two type defs, one for the request data one for the reply. In Glued this was all contained in one polymorphic VI. The purpose of this was to quickly find where in the code a request was being sent, or a reply was being sent by right clicking on the polymorphic instance and selecting Find All Instances. Then I could find all places I was requesting data, where I was acting on that, and where I was sending that data back. The Request, or the Request and wait functions were in the same VI, and there was a boolean input for Wait For Reply. In Glued modules has the ability to send a message to itself using the same polymorphic request VI mentioned before. There existed a manual screen module. This module was a place for all other modules that had manual panels to be seen. It basically was a listbox of modules, and a subpanel to insert into it. This is where sending messages to itself would come in handy because the buttons on the FP of the module invoked the same code as that message would coming from any other module. In this manual screen actors could be undocked, which would just make floating windows of each. If a module performed a request and waited on the reply, the reply would contain the data and the error from the request. So say you send a request to read an analog and wait on the reply. The DAQmx calls perform the operation and the error out is sent back with the reply data. So from the caller it has a single VI with a request in, reply out, and error out. This helped make the caller handle errors when it could instead of the module. As mentioned before the state machine was an array of strings so having this information would help track down the case where the error happened. The request and reply data used a variant, but used variant attributed combined with the Variant Repository so data like who sent the request, where it was going, the payload, and the error could be also sent if desired. I prefer state machines that have the ability to have multiple cases queued up. Either a multi-line string like JKI, or an array of string, or even an array of enums if you want. I'm sure you are familiar with the pros and cons. Glued used an array of string, but I've been using a modified JKI lately and think I prefer that. There existed an error control module. All modules that gets an error in continuous operation would just send that error to the error actor which would log it, prompt, and try to act. In practice this wasn't very helpful because it was an asynchronous process, but it was nice to have a single log for errors. Another benefit of this is it would keep track of what module the error originated from, and the state machine states that lead up to the error. Because the state machine used an array of string it logged this information too. There existed a config module. This module was a central place for setting all application settings and would publish data the config data as a second level variant repository, and would send out a global event when settings were updated. This would cause all modules to go and read the new data and perform any operation it needed to with this new data. Like if a new COM port was selected, we might want to close the current port and re-open a new one. Changing settings while running a test were limited to prevent issues with this. For debug I had an actor probe which registers for all events, request, reply, and global events, and has a central place to see all the events, and their data in the order they are generated. Here is a post talking a bit about it and showing it. And lastly Glued had no cloning of actors. In my design I haven't really had a need for it. So if I needed a CAN actor for doing CAN communication, I would make that actor and call it in parallel with all the other actors. They all started at the same time, and all stopped at the same time. No actor ever shutdown, without sending a message to shutdown he other actors. This again might be because I focused on request reply more and sending a request to an actor that doesn't exist, had issues. Actors not being clones makes debug a lot easier. At any point in the software I could go to the main VI, hold CTRL and double click the actor, which would open the BD of the actor VI that was running, and start probing wires. If I had N CAN cards it would be handled by having one CAN actor with with an array of hardware references to work with. Oh and I noticed this is for 2014 and newer only Glued was 2011 and newer, but I think that held it back a bit because of some of the improvements in 2012, and 2013. Wow wall of text so sorry, can't wait to meet up with you next week and we can talk more if you are interested. Thanks again.

...what? Post your code and what you want. You can make a sequence structure, and you can make the invoke node, but you can't wire a button (boolean control) to the close invoke node? I think it is as easy as getting all terminals for the invoke node object, then finding the one that is of boolean data type, then using the invoke node on the terminal wiring it to the control terminal (of the boolean).

Okay a few good points there. But let me ask this having honestly not known the answer, what new language features does C++ today have, that it didn't have last year, or 5 years ago? If we talk about other more abstracted languages like Visual Basic we may get a different answer of which I also don't know the answer. But just like LabVIEW they might be features that I won't fully appreciate unless I'm an expert with it. Correct me if I'm wrong but isn't this panel resize or pane resize? And what good is the minimize? Is it to stop updating the UI with new things when the window isn't being seen? I'm guessing (with no real information) that this might actually happen anyway. If this isn't the case then you should make an idea exchange post on this. Maybe LabVIEW is just so awesome it doesn't need major new features...eh maybe it's just you get used to what you have. There are major features I could want, and see as language changers. Certainly XNodes is a bit of that, I mean code that writes code as you interact with it, is a big deal. Also my argument sorta started with trying to say how 2014 is better than 7.x because you listed events and XControls as changes in the language. With that in mind look back at my list. Now I need to look back at the 2015 beta and look for language changes. I think there are features that will make you go 'wow' for sure but I can't remember any specifics on language changing. BTW so sorry OP for doing this, I had forgotten the original topic, beer for you if you're going to NI Week. And two for you Shaun if you're going

You can't be entirely serious. Maybe you haven't used these new features but they are awesome and going back you realize what you are missing. But seriously since the event structure? That was LabVIEW 6.x right? (maybe 7.0?). Project explorer. What about classes, and libraries in general? VI Server has had major upgrades since then. VI Scripting that is a ginormous feature. XNodes (unofficial but still major new feature). Static VI references, along with the other asyncronous tools (run dynamically). Application builder API. Icon editor API. System Configuration API. Was there even dynamic user events in 2009? I know they didn't have priorities. Event Inspection Window, Bookmark manager. Events being lossy. Conditional/concatenating tunnels. QuickDrop and other QD related features. Do they have make type def from a block diagram constant? Native JSON and XML. DVRs (couldn't remember the version they came). Native FTP, HTTP, SMTP Email, WebDAV, Bluetooth. Not sure when Network Streams, and network shared variables, and Web Services came about. Libraries with licensing restrictions. The list literally goes on and on. I might not use all those features daily, but there have been major improvements over the years. And 2015 has some really compelling features for me personally. But this is true, that no one at NI is saying errors will be improved in the near future.

I KNOW RIGHT! Where have you been all my life, and how did I not find it earlier? Anyway I haven't taken to using it in real applications yet. I understand the point you make about hiding design config, and that is true, but the amount of usefulness and features per pixel on the BD make it a winner in my mind. The Error Event is a neat concept that I could see using. With so much talk about error stuff in the past years I'm a little surprised something major hasn't come out yet, I mean other than the couple unofficial things mentioned earlier. I suspect NI is working on major overhauls to error behind the scenes (as AQ has sorta mentioned) just will it ever make it into our hands, or its the R part of R&D?

Often times I find the most useful things tucked away in old threads that I missed. Here is one semi-recently I saw showing one of the most useful express VIs I've seen. https://lavag.org/topic/10836-is-this-the-most-useful-express-vi-ever/ It is an express VI that can perform specific actions, based on the error it gets. Things like retry 4 times if you get error code X, or run a VI if you get code Y. This can help in making of a central error handler for things like logging. I'm not sure how this could improve the core of error handling but I like it a lot. Certainly error in general could be done better in LabVIEW, but I have a hard time describing the way that they could be improved that wouldn't either break things, or have corner cases that are hard to handle. Often times knowing what errors a function can return is part of the problem. If I had a list of what errors I could expect from a given function (and the functions it calls) I would probably be easier to look at the potential errors and come up with custom actions for each, a selection. Another issue I've heard others talk about, is that there isn't a standard way of formatting that source string. It is flexible, but it isn't standard. Adding more complicated data to the error wire, like the array of string for the call chain might help. But honestly most of these things have been discussed in other threads (like the ones mentioned). Looking at the crelf presentation there is the "Wouldn't it be cool if we could" slides which are pretty good list.

While what you posted works, I will tell you for a forth time in this thread, to USE A SHIFT REGISTER (sorry for yelling).

Yup what he said. The shift register should be on the first while loop, and remove the inner while loop all together. You've probably seen these training things before but you should check them out if you haven't already. Learn NI Training Resource Videos 3 Hour LabVIEW Introduction 6 Hour LabVIEW Introduction Self Paced training for students Self Paced training beginner to advanced, SSP Required LabVIEW Wiki on Training