hooovahh

Thanks for the update Paul, when I get a chance I'll back save it to 2012, test it out and upload the new version. For those wondering Paul's new version has these new features: Added a path indicator Now handles multi-layer icons Added a "Save As ..." function

Oh you mean like incrementing counters using the bucket filling technique with queued frames? (Part 9 of my CAN blog) Or even better, having the ability to load the XNet with custom hardware which performs the incrementing counters (and optionally the CRC) automatically? (Part 10 of my CAN blog) If you find this useful be sure and vote for the idea exchange to make this an official feature of XNet. Edit: Just realized that only answers half your question. As for detecting a frame drop out, you'll want to setup an XNet session of the Stream type, or Queued which allows to read every value of a signal or frame. Then just do an comparision that the previous value is one less than the next one and if it isn't perform some action.

Great idea on the package manager, but this is only going to be a solution for those who are online, and are willing to download even more. Having an offline installer is always important, for archival, but also for convenience for future installs.

Also worth mentioning here is the Device Drivers for May 2018. That 21+GB download just became 33+GB.

The upgrade assistant that gets installed can perform a revert in the case of something not working right afterwards. I've never done this and don't expect it to work but it is there. Also this upgrade assistant keeps all these old files only for a month before deleting them itself. After that it will likely mean a format.

Yeah I kinda missing the web install where you selected the things you wanted to download and then had an option to install or download more later. Still storage is cheap these days so I'm just downloading the 21+GB of data then merge the DVDs into a single installer. Probably going to be several hours more before it is done.

But do those machines have the same scaling settings in Windows? This is a bug clearly, but I think if you can control the scaling settings on the deployed machine, then you can just have the building machine match. For me I just make sure all machines I work on and deploy to are set to 100%, too many weird things like this happen when they aren't. No problem just get a couple of 65'' TVs for your computer monitors...of course that makes a some new problems.

I've built lots of packages and never seen anything like this. In Windows do you have any weird scaling settings on your display? Right click the desktop and go to Screen Resolution, then click Make Text and other items larger or smaller. I keep this setting at 100% to avoid some graphical issues. The next thing I might look into is the font settings in your LabVIEW.ini, and possible if you are using any custom fonts in your front panel controls. First make sure your display settings are 100%, and then I'd create a fresh LabVIEW.ini and try again but again these are just guesses. You can also try to build on another machine, or a VM and see if it works there. And lastly JKI has revamped their forums and appear more committed to customer support on them. If you can easily reproduce it you might want to post it there.

What you are sharing with the community is likely too locked down to be useful for others. There is no source code to either the Server, which is just an EXE of which I won't be running outside of a sandbox. And no source for the client which is a packed project library compiled to only run in LabVIEW 2015. Having only 2017 means I can't use it all. If you provide the full source I might be able to use this on a project in the future.

If we are talking the LabVIEW Runtime engine then there is no monetary cost in installing it. Again make an EXE, make an installer, and install it. There are a few toolkits that require a cost for a runtime engine like the Vision toolkit but most don't. If you are mistakenly calling the LabVIEW development environment "Runtime" take Neil's advice. This does have a monetary cost.

Using the application builder you can make an installer that includes all the dependent runtime engines. What this means is you can create an installer that includes all dependencies for your application. In most cases this means you can just run this one installer on a fresh copy of Windows, and it will make your application run without error. Your message isn't clear and so I might be answering a question you aren't asking. If instead you are asking about LabVIEW licensing, just activate it with the serial you have. In most cases it works just fine as NI expects people to have to reinstall LabVIEW from time to time and has a limit on activations which is greater than 1.

Okay thanks for your input. As mentioned on the dark side this is probably something that is possible by the OS, but likely lots of work that I'm not well versed in. I was really just hoping for a tool that I hadn't heard of and had a hard time searching for due to the term similarity with other virtual file mapping. Also I didn't know HDF5 had that feature, something to research for sure, but I think we are a bit too far down the TDMS hole at the moment. Not that we can't change course but it might be difficult and I'd need to see some really compelling reasons to invest in it. And since TDMS is handling all we need (I mean other than this) I don't see that happening soon. I'll either be merging the files early and keeping track that a partial merge has happened, that way I'm still just dealing with reading and parsing one file, or write an abstraction layer which makes reading from multiple files transparent.

Crosspost on the dark side. Lets say I have two large files on disk. These files will be merged at the end of a process, but I don't want to wait for the end of the process to merge some of them for convenience of reading them. I could copy the two files, then merge them, then get rid of the merge, but I'm I feel like that is a waste of File I/O operations, especially if the files are large. I could work with both files independently and when I get to the end of one file open the next. But what would be simpler would be to make a linked file, or a virtual file. A file that doesn't really exist and is just a link to the real files. But the trick is I don't want this link to be just one file, I want this linked file to concatenate with another one. C:\Temp\1.tdms - 1GB file C:\Temp\2.tdms - 1GB file C:\Temp\Merged.tdms - linked file that when opened has the contents of 1.tdms, and 2.tdms. Is this possible? I searched around and only found references to mklink, junctions, and other ways of mapping real files to another virtual place on disk. This is part of what I want but I'd also like to combine the files in a virtual sense. Any thoughts? As I said I could combine them so Merge.tdms is a real file at 2GB in size, but making that copy will probably take a while. And I could write code to read from 1.tdms, then when it gets to the end read from 2.tdms but that complicates functions quite a bit, especially when there is likely a 3.tdms or 4.tdms. Has anyone heard of any feature like this?

Looks like Smart Pi already comes with a web interface. Just use the HTTP function in LabVIEW to access the information in the same way a web browser would. These functions a pretty easy to use and the context help should help understand them more. Beyond that there might be an example in the Help >> Find Examples.

Start small, launch a test panel in MAX and see if you see the signal you want. If you do write a VI (or open an example) that just reads the signal and see if it look right there. These reentrant clone like UI's make debugging more difficult and you don't want simple problems related to the setup or channel config taking up your time, when you are debugging the interface.

You can't without other additional hardware. The GPIO on the Pi is a digital only. Add an Arduino with custom scaling, or a I2C or SPI hardware then the Pi can read that and turn it into something useful. There are currently two separate toolkits that allow for writing a LabVIEW VI and having it run on a Pi, the NI LINX toolkit which is 2014 only at the moment and for non-commercial. Or from TSXperts the Pi compiler for LabVIEW which comes in a home and professional license. This option also lets the front panel be viewable on the Pi's HDMI output making for a neat HMI. This is all optional if you are good at programming on the Pi since it can just send take data and send it back to a VI running on a more traditional target, or I've seen hosting a webpage on the Pi.

Yes I've done this but there are considerations for sure. I don't know if this is a hard requirement but the server likely needs to be running Windows, and you need full access to it for installing things like the LabVIEW run-time engine. The VI that is running is what needs to be running on that server, and using the code Thomas linked to you'll basically be pushing the front panel to a webpage. This means that everyone that views that page will be seeing the same VI's front panel. Now if NI were here they would likely say something about NXG and the WebVI technology. This allows for compiling a VI into a webpage running JavaScript. Now each client will be running this page in the sandboxed browser and will have their own view. This also can be put on a webserver and works pretty well within the limitations of NXG, which are numerous at the moment. A major benefit of this design however is that it can likely run on any modern webserver and beyond what comes with XAMPP you don't need anything else.

Samsung is hiring! We are looking for a single LabVIEW developer to help with some new production end of line testers. I'm thinking this person should be CLD equivalent but certification isn't a requirement. Job is posted on ZipReecruiter.

The only thing I've used in a real project is the WebVI features. I create webVIs that get data from current gen LabVIEW programs and this seems to work well enough. So database query, test status, type of information that just gets displayed as a web page. Could it be done in something else? Of course but I like G and I'm good at it. These web based projects are working and deployed. As for full real test applications fully written in NXG, it doesn't seem like something I'll try for a while since feature parity won't come for a while.

I have no info but wanted to say I won't be there this year, and have made that clear to the other LAVA BBQ organizers. I'm choosing to go to the CLA Summit in Austin instead. If I do hear anything I'll be updating threads here, on the dark side, and twitter.

That is seriously small and would be very annoying. Hope you have custom DPI settings for your mouse.

Oh yeah I wasn't suggesting performing the value change on the booleans. I was suggesting getting the coordinates, then performing a mouse move, and mouse click, sicne I assume squish does the same thing more or less.

Zou is probably right. LabVIEW does a lot of nonstandard things in their UI drawing, likely so they can be more easily crossplatform with Mac and Linux. Have you thought about possibly leveraging a LabVIEW EXE to get information about the position of other controls? I could imagine a LabVIEW EXE that opens an application instance to an already running EXE, and then get reference to VI front panel, then references to the controls themselves. It might be possible at that point to get the position of a control, based on the control label in the VI. Then it might be possible for your tool to get the positioning of a control, based on the name. But at that point one could make the argument to just use LabVIEW to control LabVIEW. Nothing sounds like a good solution.

Just an FYI there is an INI key that can turn this off. It is not exposed in the options but probably should be. Changing work flows can be a good thing. Years ago I thought the best way to keep a record of my source code was to zip up all of my source everyday. I'd have a zip for each day with that days snapshot of code in it. I'm so glad I learned about proper SCC and the workflow changes that came with it. QD and conditional tunnels have likely saved me man months of time and I'm grateful for it. SCC has probably saved me more than that in the amount of times I would have otherwise lost data, or opened the wrong version unintentionally. That being said many improvements you don't like you simply don't need to use.

I think most (if not all) AI DAQ hardware have a single hardware timer inside them for triggering the analog to digital converter. This is why only one task can be running at a time. That single task can be configured to read N channels of course at the same sample rate. So one solution might be to create an asynchronous task that has the sole purpose of reading all the DAQ channels in a single task, and throw them into a global. Then the reentrant VI clones just read from that global. Attached is an update which works with my simulated hardware. It will read the first 8 analog signals on "Dev1" device in a loop at 100hz. 4 times a second it will read 25 samples from each of the 8 channels and then push them to a global that limits the amount of data stored. Then in the reentrant VI instead of randomly generating data it reads it from that global. So now you can display 8 things from up to 8 channels but they could all be from channel 1. Now you can have a graph, and a digital display of channel 1, and maybe graphs of channels 2 through 7. If your hardware only has 4 analog inputs you can change the array subset function to that, and then update the enum for signal selection. Signal Selection Demo 8 Way With DAQ.zip