Mads

NI Week is just around the corner so I was wondering when the LabVIEW 2017 installers would be published...and found out they are already out Here are two of the downloaders: ftp://anonymous@ftp.ni.com/evaluation/labview/ekit/other/downloader/2017LV-WinEng_downloader.exe ftp://anonymous@ftp.ni.com/evaluation/labview/ekit/other/downloader/2017RealTime-Eng_downloader.exe

We use Profibus to Ethernet gateways for this....Makes it possible to use it across the network from a variety of hosts. Here is the one we have used, but there are others: https://www.kunbus.com/fnl-gateway-profibus.html or

We use NI's OPC UA server-functionality (currently part of NI RT and DSC) and it works fine with other OPC clients. I would have been extremely surprised if it did not, after all much of the point of using industry standard protocols is to be able to exchange data between parties from different vendors.... Prior to the OPC UA API in LabVIEW we used Kepware when we needed to be an OPC DA server, and Datasocket when we could operate as a client. As people have mentioned here before using Datasocket has its weaknesses, but we avoid some of them by implementing it as a service (no GUI to interrupt the UI thread...). So the datasocket OPC-bit is in a service, which then has a proprietary TCP/IP based server-protocol to be used by a client application (running in the system tray) that acts as its GUI.

You *can* use DETT on built applications, just enable VI server access and debugging in the build. Here is a description of it: http://digital.ni.com/public.nsf/allkb/A50A8BBFD737679186257D7700688757

Absolutely. The devil is in the details when answering such a question. An answer like the one you describe could sound sincere and OK if expressed in the right way, but most often it would come out as fake - which in turn tells the interviewers plenty. That is why this is such a good question. It is a multi-layered test. Even if I believed that answer, there are in fact consequences to it that are not just positive. Superficially people might think it is the "perfect" answer, but I might for example think that you will not be able to compromise when needed, which can be quite often in real life. So, never answer questions the way you think is expected of you, you have to be honest. You should be a bit tactical of course, but I would say a good interviewer (one from a company you would really want to work for, an interview goes both ways too!) will prefer that you are more honest than tactical...

An interview is done to discriminate Kidding aside: If the person comes from a different culture where limp hand shakes are the norm, then two things will come into play: First off I will probably have read up on his cultural background (if I am not familiar with it already) up front and/or take my lack of familiarity into account. Secondly I will still expect the person to have done his research too, and know to have a firm hand shake. The hand shake is never a deal braker, do not get me wrong here, it is just one of the many social details that I think you should expect interviewers to be noticing.

I've hired all the engineers in my department personally and for me once you get to the interview, it is 80% about your personality. Sure, on the surface I'll ask quite a few questions about your programming experience and philosophy, and if it is obvious that you do not know what you are talking about (especially if you do not seem aware of that fact either), you will not be hired. The real clincher is about the person's attitude and general behaviour though. If you seem bored(!) or out of focus and energy during the interview, have a limp hand shake (the fact that you do not know that it is a negative signal is the most serious offence), or are unable to present previous projects with enthusiasm and clarity, it is difficult to trust you, even if you can demonstrate brilliant coding. Preparing for standard interview questions like "what is your greatest weakness" is a must (do not say that you have none for example, that just demonstrates lack of self awareness(!)). I'm sure there are lots of cultural differences though. In Norway, where I am located, we probably pay less attention to formal training than many other places, and have a tendency to expect people to be humble for example.

That's true, if you have drivers that do not give you access to work with the generated messages, but requires you to allow them direct access to the shared resource, your solution makes sure you can still easily control the medium access. In our channel handlers we also implement a device and/or channel reservation mode - which could solve the same challenge. The device wrapper would then request a channel reservation, prior to allowing the third party driver to access the channel in it smore direct manner...(We use the device reservation function when we need to ensure that no other entity is interfering with a complex operation towards one device on the channel).

The Plasmionique library is very nice, I am advocating it internally as an example of good design :-) When it comes to sharing of a communication channel (serial port, TCP-link etc) I've always attacked it by having channel handlers. For each channel I instantiate a channel handler of the correct type, and every need to access the channel (different device instances for example, or communication routed into the system from an external source) do so by communicating with the appropriate channel handler (normally using a SEQ). One upside to this centralized approach is that it is easy to see the whole picture of what is going on on a channel. The handlers normally run in the background, but they have their own user interface with communication stats etc available for debugging purposes, and/or they are DQMH-modules and all their actions are subscribable user events... :-) )

Thanks so much for the videos, you are doing everyone a huge favor.

I assume you are thinking about the static access here (where you always will be requesting the same value so that you can skip the lookup after the first call)? With no lookup you get into a different league of course. For random access there is no break-down; it will perform faster or comparable to the alternatives I guess you are thinking of. Personally I see more value in dictionaries in the random access scenario, so that's probably why I do not have the same focus on that bit as you.

I've run some preliminary testing of 2016 and the Variant attribute IPE for key value pair lookups now, and have compared it with 2016and 2015 without the IPE: Without the IPE, 2016 is equal in speed or negligibly slower than 2015 (so there is no instantly free lunch in just upgrading to 2016). With the IPE the speed of dictionary read and write operations are considerably faster, on my machine they were 1.7x faster than without/in LV2015. This was with only an array index in the attribute (value of key-value pair stored in separate array). I also did a quick test where I stored a DBL directly in the attribute, which turned out to be even faster (1.4x) for writes, and equal for reads. That's probably not the case for more complex data types, but the gap will definitely be smaller than before. The CVT for example then will in most cases be better off using attributes to store the actual values instead of keeping separate arrays for them. That would also allow it to be made more flexible when it comes to adding or removing tags.

The Current Value Table is one tool that used to have the actual values of its key-value pairs stored as attributes, but ended up only storing type specific array indexes in the attribute to (vastly) improve its performance. I wonder how much of that difference (if any) could be removed with the new IPE feature... Has anyone checked that already? I've been evaluating different dictionary solutions lately and this might change the picture slightly. I'll download 2016 and do some testing later this week.

Editing the file like that causes the file to be invalid as the cryptographic hash in the file is no longer correct (introduced in 3.0). So unless you know how to update the hash (stored in the file ID probably) correctly you will not be able to produce a valid update. The Pro version might allow you to open them anyhow just to have a look at it to see what has been going on, but I would think that it should still at least give the users a warning that the file has been tampered with(?).

What version of OpenG Zip library did you try to install (it has to be done using the Custom Software Install feature in NI MAX by the way...)? I'm using it on NI Linux RT targets (cRIO-9030 and sbRIO-9651) without any problems (thanks a million Rolf Kalbermatter). Here is a thread where my initial request for Linux RT support was discussed.

When you say that you want to add the first three rows and add the elements together I assume that the sum you are after is not the sum of all the elements in those rows (which would be just one number), but the sum of each subcolumn, or? If so, in your example above the first row in the output array will be: 10, 13, 13, 57, 21, 11 There are a lot of ways to do that, and the different ways have different speed and memory efficiency depending on how many columns there are, and how many rows you want to sum. Attached is one alternative (made in LV2015, back-converted to 2012) that seems to be an OK compromise between code simplicity and speed...I'm sure someone will take the challenge and improve it though ArrayNthRowSum.vi

Chrome is complaining about the security of lavag.org. It has an invalid certificate (encrypted with an outdated cipher)....

I normally use the window state to determine if the function is running already or not here. So i make sure the pop-up window will always close itself when completed, and the calling code will just check if the window is already open to determine if it should initialize and run the VI. I have attached an example here. Now, this does not work if you really want the Furnace control to continue running even if the window is closed, but in such cases I would separate the GUI (only runs when window is opened) from the Furnace control (runs continously in the background), and just send adjustments to the latter from the former when they occur. Init, run and open if not already running. Open only otherwise.zip

I think you will have to attack the problem by making the header(s) in a way that will allow you to place it at the end of the file (or at multiple locations..). You can see an example of this in the way the zip file format is structured. I recently developed a chunk based log file format myself where the data to be logged is placed in pre-allocated (on demand) sections which each have a header that allows the readers and writers to locate the other sections (chunk headers declare its chunk size and current write position. They can also have pointers to the previous and next chunk, making it easy and quick to traverse the file structure). Another example of a chunk based file format is PNG.

Thanks, I had not discovered the SFTP option. Now I found a little user guide on it too.

On Linux RT there is no FTP server in the standard installation, only WebDAV (which many of our customers have never heard of unfortunately, so we have some trouble getting some of them to switch to cRIO w LinuxRT). You have to do a custom install of "Legacy FTP server support" to have FTP. To make that option even worse it only supports anonymous logons (so you do not really have an equivalent to the "old" solution available).

My doctor ended up suggesting I should remove a tendon when he was unsuccessful treating my LabVIEW-induced tennis elbow with drugs and massage a few years back....I tried all kinds of mouse replacements only to make things even worse. The immediate solution it turned out was to stretch the hand upwards and downwards tens of times a day to get rid of the inflammation (thanks Google(!)). Since I switched to the Microsoft Arc mouse (which everyone else here hates) I'm not bothered with it much anymore though (if I feel anything I just do some stretching and I'm fine again).

I talk about writing code that can run *in* a web browser. NI's Web UI tool basically solved this by making us develop Silverlight applications in a variant of G, which most people with a web client would have and therefor be able to use. The decision to base it on Silverlight proved to be rather bad...but the concept would be the same. In scenario B the Web client (and/or server) is in many ways the target OS.There has been some talk lately about NI having plans to port the run-time-engine to javascript. That would constitute a move towards scenario B.

Who's talking about language? This is in a context of toolkits/general system design solutions available in or tightly supported by LabVIEW, the IDE and ecosystem. If I say it is an extreme you might need to evaluate it as such and see what light that sheds on the scenario I never talked about the NI web server, and in scenario B (the true extreme one) you would probably never care about it at all. You would write code that can run on any web server or client.