hooovahh

The sequence structure you have shown there is likely a whole lot of stuff right? Is it a single subVI that takes a long time to return? If so pass the queue reference into it and check there. Then in your subVI use a state machine architecture that periodically checks to see the size of the queue. A more clunky solution could also be to call the Calculate subVI as an asynchronous process, and then abort it if your queue gets an element.

Oh and you already missed out on the early bird special...which there was about a 1 week window between being announced and closing. One of the reasons I heard this change was coming, was because NI used to get deep discounts at the convention for going in the summer, but those discounts aren't there anymore. That and people have been complaining about how hot it is. Still I think it will be weird for a few reasons. The academics will be considerably lighter since...well school will still be in. Professors will also likely not be able to get time off so attendance will be down for that group even more. And what about What's New In LabVIEW 2017? Is 2017 going to be released in May? Usually there is a SP1 in February, is NI going to be able to push out a new full release (develop, review, document, beta test, etc) in time? It'll probably be for the better in the long run, but I wouldn't be surprised if attendance is down this year.

You mentioned remote desktop. What's wrong with just using that? If you do something custom you will likely run into issues where taking an image doesn't quite work right. Like I suspect that the right click menus won't be included in a method on the VI reference to get an image of the front panel. Maybe invoking a screenshot with kernel32.dll will include it. What you are describing is probably possible, but the amount of effort involved would be a lot, and there are already other tools for sharing a computer (VNC, RDP, TeamViewer, etc.) and would work probably just as well.

Glad you figured it out. The Open, Operate, Close paradigm (with operate taking place in a loop) is pretty common in LabVIEW and is often see for File I/O, VISA, and other hardware stuff. I'm guessing with simulated hardware an Open and a Close just takes much less time than communicating with actual hardware. There are times when open and close can take place in the loop, but it is generally useful when you only call the operate once in a great while, allowing for the hardware to be used for some other task.

I'd be curious to see how your tasks are created and the type that they are. Are you starting and stopping tasks all the time? I'd suggest setting them up to be continuous, and then just read the values that essentially are in the buffer, then close when you need to modify the task or the application is done. I think you're going to have to do some debugging and figure out where the extra slow downs are occurring, and maybe write some test code to test the performance of doing the same thing, different ways. I've not seen a the type of slow down you describe, and it sounds pretty extreme. Oh are you connected to any USB hub? If this is a desktop try the USB ports on the back of the computer instead of the ones on the front. Any other computers you can test with?

Yup. In the configuration software you make a COM port, then tell it the IP address, and port to expect the ethernet to serial device. Then I think there is a service running in the background that handles the back and forth, but to Windows it just looks like a COM port that any application can use. When the COM port is closed (by any application) by default the connection to the IP device is also closed, so any other computer on the network can open the same device. In our situation we could run a bunch of extra RS-485 cables across our lab, and have each PC have a PCI serial concentrator card, so it has the 2-8 COM ports needed on each PC, but this seems more flexible. We'll see if it holds up.

Wow this is a fantastic discovery. I always knew the OpenG config functions were really slow for large structures but always blamed the NI INI config functions that had to be called so many times. In the past I've switched over to using the MGI Read/Write Anything code (modifying it a bit for my needs) but I'll look into the improved OpenG solution in the future. If someone does take on the updating of this package and code, they also may want to use some of the newer LabVIEW features that can improve performance, like inlining, and conditional or concatenating array tunnels.

I'm a bit confused (not about resurrecting a 6 year old thread). Do they sell only the software? How much for the hardware? EDIT: I see how the software version works now, that is interesting, but seems like a lot of overhead to have a server if the only purpose is to talk to a serial device. We've recently had a need for some basic serial to ethernet devices and bought the UDS-1100 which is a single port to ethernet device by Lantronix. It's only $130 at CDW or $190 for a two port version that I haven't used yet. Software and drivers are free with the hardware which is available for download from their site. Updating firmware for the devices is a bit of a pain, and does have a wizard like UI. I also had a bit of difficulty with the web interface which sometimes didn't look like it saved my settings but would. But once you get it going they work pretty well. We've only been using them for a couple of weeks but we plan on getting more if we don't see any issues.

Sweet indeed. I actually have a list of Idea Exchange items that could be completed with XNodes, and just haven't gotten around to doing them. I try to make my XNodes not have any external dependencies, since it is a bit of a pain to ask users of your code to go get an API that they are unfamilar with, and isn't on the tools network. I've heard good things about the CodeGen Engine NI built, and if you get some time you may want to look into porting some of those scripting functions into VIs that use the CodeGen Engine since that is shipped with LabVIEW and the dependencies won't need to be tracked down. https://decibel.ni.com/content/docs/DOC-47786

Yeah I like that property, but there are still a few instances where a VI could be inlined, but doing so would effect the code in some way the developer needs to be aware of. If you use the Call Chain primitive, then it will return one less level, if the VI is inlined. I only say this so that others are aware that turning on inlining for all VIs that can be inlined, is not always a good idea.

Remembering to version can be an issue, which is why I made a prebuild VI that runs which prompts you for the version. It also sets all installers to have the same version as the EXE you are setting, and I modified it so it sets the build number to the commit number in SVN.

OpenG is free as in beer, and free as in speech. It is licensed under a BSD agreement, The majority of it is licensed under a BSD agreement, which basically means you can use it in commercial applications, edit it, change it, do as you please, as long as you attribute the creator (leaving in the text on the front panel) and there are a couple of other considerations when distributed as a binary.

http://sine.ni.com/nips/cds/view/p/lang/en/nid/209027

Yup, when I have to do something similar I make sure there is only one VISA resource open, and one close. Every read/write calls into an Action Engine that uses the VISA resource. Sure you can get into cases where loop 2 is waiting to perform a write then read, because loop 1 is already waiting on the read to return, but in the end you really only have one port. Data is going to come in and out for multiple devices and a lock of resources must happen at some level. If you truly need 3 loops to run in parallel, and not block each other, then you need 3 VISA resources one for each piece of hardware.

I don't have 2011 installed so I can't test that this opens correctly, but I back saved it into 2011. Again be sure and have OpenG stuff installed. ClusterView 2011.zip

Not really. I mean when you run your host VI on your PC you would need to compile the RT VI for the target, and optionally any FPGA compiling that needs to take place, then deploy it. I think it might be possible but probably isn't what you want. A better solution might be to just write your code for the myRIO, and then have it run on startup. Then your myRIO is always running, and always looking for a request to do something. Sorry I don't have any specifics I don't have a myRIO to test with, or any available RT hardware.

Is what I said: Is what I meant. I can see how I wasn't being clear.

That's what I was trying to say. I like that I can do that with an NI VI. Just hit run and start interacting with the front panel for debugging. But this version looks like you have to perform a separate compile operation, which makes the bit file, and then you have to write host code to talk to it.

I partially know what you mean. I know I am more than just where I work (it's Samsung by the way). But I appreciate knowing when a user works at NI. It's a badge, or a hat, or some other flair that other can appreciate. In either case I don't have control over it.

I'm sure there is. And looking at the Hand-RIO videos I'd say it too does some similar tricks with the Xilinx compiler.

I've absolutely done the list box approach. Similar UI as you where the listbox is on the left and populated at run time, then the subpanel can be loaded in the main UI. Each of these subpanels VIs can be poped out and pinned too, but that's only done during debugging so you can look at two manual panels at the same time and see how changing one effects another. Another good example of this type of UI is the configuration dialog, which is seen in the Tools >> Options dialog in LabVIEW. All of these are more modular approaches than a static tab control, but I don't think this answers the original question.

A text file can be opened in Excel if columns are separated by commas "," and then the file is named with a .csv file extension. This is by far the easiest solution, but the most simple. For more control over the look and format you can use the Report Generation Toolkit (included with 2014 and newer I think, and a paid add on before that). This uses the ActiveX API to read and write data so Excel must be installed on the machine. There are a few free wrappers for this API as well. There is also XLR8, a 3rd party company that makes a toolkit which creates the file using the documented format, not ActiveX so then you don't need Excel installed on the machine. And starting in 2014 the Write Measurement File has a .xlsx option. But don't expect a lot of control, it works similar to the XLR8 toolkit. Oh and you can make a TDMS file and then use the free NI add-on to open it in Excel. This all really depends on what type of data you have, how you want it to look, and the amount of time and money you want to invest.

Very interesting. Certainly parts of the work flow are different from the NI implementation, like being able to just run the FPGA from the front panel, instead of having to compile it, then create a host to control it. Also the change to using your own custom (XNodes I assume) for the interfacing. Also is it me or does the transfer of the bit file seem slow? I mean you show a very basic program but it seems to take a while to download. Beyond that I'm not aware of any precedence being set by NI on these clone hardware. Plenty of DAQ devices have been made by 3rd party vendors, most with a simple interface via a DLL wrapper, or VISA calls to the hardware. LabJack is one that comes to mind. Then there is the more advanced clones like the mentioned Hand-RIO. I've not heard of a time when NI has come down and not allowed a company to make a product, but then again some of these advanced ones that clearly use the NI tool chain in ways that NI didn't intend, are out of countries that NI is not headquartered in. I'm not a lawyer, but I would not make a business out of these types of products, due to concerns that NI would sue the pants off of me.

Why do you want it removed? Do you not work for NI? I don't think changing the email will change your status. That is a thing manually set on the profile by an administrator. It doesn't look like I have access to change that part of a users profile so I'll contact Michael and see if he can change it.

It probably would be possible. But as mentioned earlier a limitation of the API at the moment is all users share the same front panel displays. So having multiple users connected wouldn't work well, unless you can modify it to serve different pages to each user connected to the host.