hooovahh

Pretty neat, here's one of the scopes that are popular with the hobbyists. http://www.amazon.com/Rigol-DS1054Z/dp/B00N222I6C I don't own one (yet) but one reason why it is so popular is because someone reverse engineered the licensing scheme for their line of scopes, and by entering the right code into the scope you can convince the firmware it is actually a 1104Z instead, which is a scope with twice the memory, twice the speed, RS232, SPI, I2C decoding and a bunch of other features. Your $400 scope is now as capable as the $1,000 scope. Here is one of the most Canadian hack videos I've seen describing the steps involved, but note the site he references no longer exists but I assume others do. EDIT: Oh interesting tear down that I haven't watched all the way through yet. http://hackaday.com/2014/10/22/how-to-reverse-engineer-featuring-the-rigol-ds1054z/

I was referring to the fact that Channel Wires can be pass into subVIs, and diagrams where your XNode implementation cannot. The idea is you can then follow the data of the Channel Wire and find all those involved in generating or consuming the data. Would a 3D environment help? I'm not sure, what benefit does that give me? It certainly adds another layer of complications, but organizational-wise I think it would be too much to work with. Processors naturally have parallel operations with multi core work, FPGA even more so. So having a 2D environment with parallel operations seems like a good design. I guess if processors had another layer, maybe if each core of a processor was made up of N cores, then a 3D environment could be used and development might help write code for processors of processors. But since the coupling between cores is not that big of a deal, and the compiler takes care of the FPGA side, even here I don't think it would be very useful. Besides we only have 2D screens, lets wait to make LabVIEW 3D until we have holographic monitors.

I don't use Macs but it might be related to this. https://lavag.org/topic/15619-ctrlshift-shortcuts-sometimes-not-working-in-labview/

This is kinda fun, it does a few things you don't see in XNodes very often. That being said not being able to pass wireless data into our out of subVIs, or even structures is pretty limiting. Thanks for sharing.

It's feedback like that, that I'm guessing NI is looking for. But if you were to ask R&D I think their answer would be something along the lines of how LabVIEW has some weaknesses when data flow isn't followed. If I have queues being opened by name, it can be difficult to know where messages are being enqueued and dequeued. With a Channel Wire you have the ability to trace back where the data came from. Visually debugging can be easier. It can probably confuse the hell out of new developers but honestly NI had catered to new developers in other ways, and I'd rather not hold back a language in favor simply because it is a concept that beginners struggle with. It is a balance for sure. While this technology fascinates me, the implementation is also interesting. All done in G code, creating the VIs as they are needed, and keeping a cache of the ones already made. Sure XNodes would have done this for you too, but if XNodes can be avoided, and still get the same (or similar) functionality I understand the design choice. It opens the way for other developers to make other cool right click scripting tools.

Check out the last 10 minutes or so of the augmenting the right click presentation named: 2015 NIWeek_08_Augmenting Right-Click Menus in LabVIEW 2015_Stephen Loftus Mercer-Darren Nattinger.mp4 It can be found on the FTP site of NI Week videos: https://lavag.org/topic/19154-ni-week-2015-videos/ It has lots of features, but the most accessible is the ability to write data in one place, and read it in another place, and have those two places linked by a wire that doesn't force data flow. Edit: Oh here's more. https://decibel.ni.com/content/docs/DOC-41918

I've actually never used that ability and wasn't sure what it is used for. Here is the description pulled from the resource files in LabVIEW 2014 for GetDisplayName3. I wonder if the warning comes from the fact that in 2014 there is actually two things to return, Type Name and Instance Name, where the older GetDisplayName2 looks like it only has Name. The GetDisplayName2 is probably deprecated. Still in the future when this ability is used it is probably easiest to just pull the name of the owning library and use that as the Name. Then this ability is more generic and would work on all XNodes.

I had a somewhat similar experience, where I was talking about how I wanted a way to breakup the TDMS file, defrag the parts, then combine them. This would give me the ability to have a progress bar on a defrag, and a cancel. Here is a post detailing some of my work. I eventually did come up with a solution, but the defrag time increased quite a bit. Glad there is a native solution, even if it doesn't allow for a cancel.

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.