hooovahh

Thanks for the kind words. If you haven't found them yet there is a nugget series on the certification board. Whenever you feel like looking into the CLD be sure and read up on the information there.

It's a system level DLL call that's documented here. https://msdn.microsoft.com/en-us/library/windows/desktop/aa372693(v=vs.85).aspx The SystemPowerStatus type is defined here. https://msdn.microsoft.com/en-us/library/windows/desktop/aa373232(v=vs.85).aspx

You can use NI's licensing technology, and your tools can activate, or have trials, just like NI tools do. http://sine.ni.com/nips/cds/view/p/lang/en/nid/209107 https://decibel.ni.com/content/groups/third-party-licensing-and-activation-toolkit

Well that is concerning for sure. Unfortunately I don't have 2015 SP1 yet, but this might be as good of reason as any to start the long download process of that whole software suite. But the fact that this happens on the save makes me even more confused. If it were on the wire operation then I could do some debugging and look into the VIs that get ran, when the wire operation takes place. But the fact that the wire operation works just fine, and it is just on the save, makes me think it might be something more difficult to troubleshoot and resolve. Well I guess I'd send the report to NI...and hope for some support.

You can set the default value of a control using scripting. But I don't think this is what you want. Very few scripting functions work in the run-time engine. Scripting is generally a thing that makes LabVIEW code, or edits LabVIEW code. These are not the types of things you do in a run-time engine. In a built EXE for C++ you wouldn't generate new source code that is compiled and then used in that EXE. It would be something like self modifying code, and probably should be avoided. But what you can do is use a function like the OpenG Write Panel to INI, and Read Panel From INI. This will take the control values for every control on your front panel, and save them to a human readable INI file. Then on startup of your program you can use the Read Panel From INI and it will set the control values to what they were last saved to. Where you save the INI is up to you, but you may get into some permissions issues if you try writing and reading to files under Program Files, which is why most programs are gravitating to using the Application Data folder, or ProgramData for all users. These two wonderful OpenG functions can be found in the Variant Configuration package.

I haven't used the NI one, but the little amount I played around with the JKI Caraya unit tester, it seemed pretty slick. Have you used that unit test software? And did you also find it to be slow?

I've never heard of an Academic Partner, but here are some links on NI's academic information. http://us.ni.com/academic https://decibel.ni.com/content/groups/ni-academic-partners It would probably be best to contact NI directly for this type of question.

Oh yeah that is a sticking point isn't it. So I made a VI that is set to run when opened, and when it runs it just reads the Command Line Arguments using the property node. I then opened this VI (and ran it because it was opened) using a command line call to LabVIEW.exe. It opened and ran the VI just fine, but any command line parameters passed to LabVIEW.exe were not then passed along to my VI, I was hoping they would be. A launcher would work, you could then write to a temporary path, or the ProgramData folder, and your VI could then open it. I wish there was more documentation on the behavior of LabVIEW.exe when it comes to command line arguments, it might be possible to do what you want but I'm not aware of any other simple solution.

Not really. I mean turning VI source code into a compiled piece of binary, is the responsibility of the compiler. In a built EXE, there is no compiler, this is in the LabVIEW IDE only. So when you look at a VI file that has separate compiled code, the compiled binary is saved in a temp location that I can't remember at the moment, but I suspect it is in ProgramData or AppData somewhere. If this tools needs compiled code to execute, and you don't have it in the VI file, and you are running from the run-time engine, then you have no way of using this tool. But if this tool can run from the LabVIEW IDE I think you should be fine. You can still invoke a VI to run programatically from a command line, and get functionality that looks like a built EXE, but runs from the IDE. LabVIEW.exe supports a command line parameter, which it will attempt to open as if you did a File >> Open. If this file is a VI, and it is set to run when opened then this might be a solution for you.

The TDMS use is the only one I can think of too. Basically if we have data on an FPGA and we want to log it into a TDMS file on the host side, then the old method would be to transfer using a FIFO over from the FPGA to the host (making the data in two places), then write it to a TDMS file. The DAQmx VIs have the ability to log directly from hardware to disk. So this means instead of reading an AI from the hardware (which makes a copy) we can log directly from the DMA of the hardware, and log it to disk. This FPGA external DVR is apparently the same thing. Log directly from the memory on the FPGA to disk, without making copies, without extra data transfer, and reducing that load from host operations. Personally I've never done this but it is a neat concept if you have lots of FPGA data and just want to log it, of course in practice I think I'd want to do more than just log it.

It sorta is dynamic. Actors can unregister or register to new events at run-time, but in practice is never really needs to. And the messaging structure is based on user events, and you can't register for an array of user events, unless each of the data types of each event are the same, which is where I used the variant as the data type. Also there are times when I might only want some information from the variant, and I don't pull out all of the payload, something like meta data instead, and I believe this is most efficient with a variant attribute, where you don't have to read everything.

Yeah I have other issues with the CVT, like performance. And when writing a messaging library that is uses a wrapper constantly for variant data, I wanted it to be light weight, and generally I didn't find a wrapper for a look up table that wasn't better when it comes to performance than Variant Attributes.

Well think of running your VI, similar to running a program for the first time, then closing it after the VI is done. So when you open up a new copy of Word, how does it know what your recent documents were? Well it can't just keep it in memory, because it is a new execution, unless it writes some data to a place on disk that will be maintained between runs. But a more simple way to accomplish this, is instead of using the Run button to do a new calculation, which again will run once, then stop, similar to running a program and exiting it, you can instead wrap the whole VI in a while loop, so the program keeps running until you tell it to exit. This is basic application design in LabVIEW, and while there are some work arounds, like reading and writing to local variables between runs, this design is not the appropriate method.

Listen noob... Oh...let me start again... What is your problem? Because reading your post it doesn't seem like you have any question. You state you have an array of numbers, and you are indexing each one, one at at time. Each element goes into a case statement, and then one of N things happen, based on the value of the that indexed value. So what isn't working? Your title doesn't reflect your post. You are asking about holding a value in the title but not in the code. One thing you might be asking is why is your output only one value? What I mean by that, is you give it 8, 5, and 4, but your output only shows a value for 4. The reason for this is because your loop runs 3 times as it should (by the way you don't need the array size and wiring to the N terminal, that is only needed if no arrays are indexed) But even if your loop runs 100 times, the output of the loop is always going to be the values returned from the last run, and that is because your outputs (the booleans) are scalars, not arrays, and the output tunnel is not being indexed. If you want every boolean value returned, right click the output tunnel and enable indexing. But now you have N booleans being returned but you can only display one (since your boolean on the front panel is just a single boolean) so what you might want is to add an Or Array Elements, which takes an array of booleans, and if one or more are true, then it returns a scalar true. There are of course easier ways of producing this same output. Like the attached code which does the same thing, but in a more scaleible way. You probably have seen these links before but here is some free LabVIEW training links if you have some fee time you should check them out, especially the introduction videos. 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 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

Yeah the XNode version works with any data type. It can read and write references, and ROI's which I think are clusters. The non XNode version would need to have those types added to the polymorphic VI types.

So sorry it took this long to realize you were talking about at run-time, my bad. Here is an idea exchange for that. http://forums.ni.com/t5/LabVIEW-Idea-Exchange/LabVIEW-Spell-Check-For-String-Control-in-Run-Time/idi-p/1661466 And no, I can't think of any other solution. Is there some kind of external spell check library that can be called? Still sounds like a pain.

I know of no other spell checker like functionality in LabVIEW. There are several ideas on the idea exchange for this, none seem to have much traction but this is the highest one I see. http://forums.ni.com/t5/LabVIEW-Idea-Exchange/Spell-Check/idi-p/982762 That being said I doubt NI would work on making a spell checker in LabVIEW, since VIA does works for finding spelling errors in source, which I believe is the most common use case.

I understand your version situation, but the VI Analyzer is now free with LabVIEW Professional 2014 or newer.

We still haven't seen any code, we still haven't seen any example Excel files.

Yes sorta, but you shouldn't need to. Is there some function that only LIFA has that LINX doesn't? LINX is the newer version and I'm sure they are trying to have the same function parity between the two toolkits. That being said one restriction you may find is that you can only use one toolkit on one Arduino at a time. Each toolkit has its own firmware that gets loaded on the Arduino and I wouldn't be surprised if they weren't compatible. Meaning only LIFA can talk to hardware with the LIFA firmware on it.

Yeah sorry, like several others I'm somewhat restricted, and have to choose what I want to attend. Being a big part of the LAVA BBQ means I still need to try to make it to NI Week, and that might mean missing out on other summits for now.

Yeah much of what I learned about .Net picture boxes, image resizing, z-layering, and transparencies in LabVIEW, stems from that one GDI Resize VI that I think started from here. http://forums.ni.com/t5/LabVIEW/Net-image-resize-how-to-convert-to-format-labview-can-use/m-p/2199022#M704093 That spiked my curiosity and I've written several image library tools since then, which have been used in a few tools like my ribbon interface, that I never completed. Say one other thing I didn't think about, is that there is a vi.lib tool for turning a PNG stream of data, into LabVIEW data. I think it is just a DLL call in the background but it might load the PNG in a slightly different way. It is found at this path. <vi.lib>\wsapi\VIs\PNG Data to LV Image.vi"

After you have a package installed, you can navigate to the following directory: C:\ProgramData\JKI\VIPM\cache And you'll find all the packages you have installed. These are the files VIPM uses to install, so you can copy these self contained packages as a backup, and then choose to install them at a later date and not need any network access at all. I've actually done this on reuse libraries. Say I make a whole bunch of reuse code and package it up as a VIPC file. I can then include all the other dependencies (like OpenG or what ever) as a single VIPC file that contains everything needed to install our reuse without needing the internet. As with software libraries they development and support can stop at any moment, but the code in its current state can be backed up.

I think I know this one but I could be wrong. LabVIEW can't handle alpha layer information, so I suspect those pixels are something like 1% opacity which doesn't show up in a viewer as easily. I've seen this where I had a pixel that was black but at a low opacity. When you use the native LabVIEW read it just bumps that up to 100% and then there are black pixels when there wasn't before. I remember seeing some code a while ago that would actually set a threshold and set the pixels to the background color if they were below this level. I just tested this on some PNGs with alpha layers and I didn't quite get the output I expected so maybe this isn't your issue. Still you might want to load up the PNG in an image control that does support alpha layers better. Here is some code I did a while ago to demonstrate alpha layers, and native zooming using the picture box. http://forums.ni.com/t5/LabVIEW/NET-picturebox-convert-to-LabView-image/m-p/3125944#M897890 Is it possible to post the PNG image by the way?

Well NI sorta tried that and it was called External Nodes and it wasn't flexible enough. And to be fair you don't need N templates of subVIs to manage the different permutations, it is just the most straight forward way. I've had an XNode where there are multiple disabled diagram cases, and one case will get enabled based on the options selected. If you code in the smartness then you don't necessarily end up with multiple templates. Heck you don't have to even have one template you can write the VI from scratch, but again that isn't the most straight forward solution, so it seldom is used. I guess one down side I see from accepting multiple data types, then having one template VI read the data type, and then act differently based on it, is that then there is this extra overhead that wouldn't have been needed. I mean the XNode (and VIM) can know the data type it is being used on, and again if the logic is made, you don't need to do things like read the data type and act one way or another, it's just simpler this way.