Rolf Kalbermatter

Why would you want to do that? Compiling a Linux image for embedded hardware is not a trivial feat. Yes NI does provide the scripts that are necessary to do that but you also need to have the perfectly setup development system with the right version of gcc toolchain to even hope to get that working seemlessly. Even slight version differences can mean that you might have to edit scripts and all and such edits are really not for the faint at heart. You need a very deep knowledge into Linux in general and especially embedded kernel compiling of Linux in order to hope that your edits will cause anything else than more errors. Googling with errors is in these cases usually also not a solution because you mostly find only answers from other noobs who have no idea what they are doing and just post random recommendations.

While it’s understandable that you feel frustrated about the failure, part of multiple choice tests is to play with the wording to test if people actually read the question or just might remember answers from similar worded questions from other tests. This is fairly common among every single multiple choice test I have done so far! Is it tricky? Yes definitely! Unfair? Not really. My failures were in XControls and in the Architect terminologies, since I never did a single XControl and despite reading the Advanced Course Manual about XControl development once, just didn’t remember all the different ability methods and their catches in what order they are fired, and the Architect terminologies is basically taken from some book that used a specific number of words that might or might not be the holy grail of software development. I could most likely have certified by points if I had kept a record of the events I attended and the occasional presentation. But alas I didn’t. Is it to much asked to ask for those points yourself compared to expecting NI to hire a staff of a several secretaries who painstakingly go through every attendance list and try to match those entries to active members of the CLD, CLA and other certification lists? I don’t think so!

This has nothing to do with a CIN whatsover. CINs were a legacy technology in LabVIEW 3 and 4 before LabVIEW learned to interface to shared libraries (*.dll on Windows and *.so on Unix). What you are doing is not a wrapper either in the sense as it is usually used by me and others who are regularly dealing with this. A wrapper is another shared library written in C/C++ that interfaces to a certain API and translates it into a more LabVIEW friendly shared library interface that can be more easily interfaced with the Call Library Node. You are trying to create a VI interface library to your shared library. And that is always a tricky business. For one the Call Library Node can't interface to every C feature out there. C++ object interfaces, callback pointers and also complex structures with embedded pointers are all things that can't be done with the Call Library Node (or in the case of complex structures with embedded pointers only with a lot of pain and by handcoding in LabVIEW what a C compiler would normally do mostly automatically). The import library wizard you are trying to use for this is an amazing piece of software but despite its name NOT a magician. And extracting all the necessary information from a header to safely interface LabVIEW to a C shared library would be a truely magical feat, since the C syntax does not cover all the necessary details about buffer management and such things. This is only documented (if you are lucky) in the prosa library documentation that comes with your shared library. If you are unlucky you have to figure it out by guessing from naming conventions of variable names and lots of trial and error (meaning: crashing, restarting, editing, saving, crashing, goto begin). This is true for using a shared library in C just as much as in any other language including LabVIEW. So even if the import library wizard can import all your functions you really have to go through each generated VI and manually check that the generated code is actually correct. Also the generated code is in an attempt to be rather safe than sorry often unneccessarily inefficiently programmed, which is another thing you should be changing. Of course this all requires that you know exactly how the shared library should be interfaced and if you really do that you end up very quickly with the constation that creating all those interface VIs from scratch by hand is not only about as fast as going through the import library wizard and then painstakingly check each of the VIs by hand, but also creates more efficient interface VIs with something more meaningful than the ugly standard light blue import library wizard icons and totally unpractical connector panes. The import library wizard for instance can't know that in a function like: int32_t MyAwesomeBufferReader(int32_t *buf, int32_t bufSize, int32_t *bufRead) the second parameter is the size of the passed in buffer and the third is the size of how many data was actually filled in the buffer. It doesn't even know that the first is not just a pointer to a single int value but rather a pointer to an array. The C syntax does not distinguish between a pointer to a scalar and a pointer to an array, except that it allows to usually write int32_t MyAwesomeBufferReader(int32_t buf[], int32_t bufSize, int32_t *bufRead) to show that the first parameter is actually an array, but this is not used by many programmers despite its increased readability (probably because some ancient C compilers didn't know about this syntax with an incomplete array size and some libraries are still written to compile even on computers that you can only see in musea anymore). The first variant will likely default to a VI with an int32 value "bufSize" as input and two int32 value "buf" and "bufRead" as output and if you select the option to treat return values as error it will enter the return value into the error cluster as an error if it is not 0. It will also corrupt memory (and likely crash at some point) whenever being called with a bufSize value greater than 1! The proper VI (just going from the somewhat arbitrary naming of the parameters) has however an int32 "number of samples to read" as input that says how much data should be read, and an int32 array output. Before calling the shared library function the interface VI should allocate an array of "number of samples to read" in length and on return of the function should use the "bufRead" value to resize the array to the actually returned data and then pass it back through the array output of the connector pane . The interface VI should hide all the buffer management details from any caller of the VI as otherwise you are going to expect every user of your VI to know not only about C programming details in general but about the actual programming interface of your shared library function. A totally unusable LabVIEW VI as such! No automatic wizard in the world could be thought this in any way, and even what I just wrote is usually only a reasonable guess based on the parameter naming, which in C has absolutely no meaning in any way. (The actual parameter names can be left away completely in the function prototype without any adverse effect when using the function, and the names in the function prototype can be also completely different to the names in the actual function declaration, if the programmer wants to do that to obfuscate his code even more.) The actual library documentation would hopefully explain in detail what each parameter is meant to mean but you can't point an automated tool at a PDF or HTML file and tell it to extract any exact programming information from the prosa text in there.

While you bring up valid points here, I think there is no standard whatsoever in the community about this so far. Everybody does as he or she feels at that particular time of the day and may do it different the next day. So if you want to bring this up, it may be a good idea to document it somewhere in the wiki. Basically start some sort of recommended style guide there. Obviously not everyone will read it and even if someone does he won't be shot if he does not follow it. 😀 About your last point I would personally prefer to have different sections on the same page for now. I also don't see deprecation of pages going to happen anytime soon and definitely not as a separate task that anyone would take upon himself. If something will be deprecated in the future it will be likely as part of editing a page for other purposes such as adding information about new features or similar. And it is anyhow at least 7 years in the future as NI committed at some time to a support timeframe of 10 years for LabVIEW CG after the first NXG version was released. 😁 With the current progress of LabVIEW NXG that might be about the time it reaches feature dominance over LabVIEW CG. 😆

Well in that case the remark about the DLLs having to be compiled for ARM was really off. That is for Windows IoT installations on targets like the RPi and similar boards which all have an ARM CPU (and accordingly can't run Windows IoT Enterprise either which is a pure x86/x64 install). It all depends on which C compiler they used to create those DLLs. Until Visual C 2015 or so each Visual C version come with it's own specific C runtime library that had to be installed on every target on which you wanted to run an executable or DLL created with it. While many parts of Windows are compiled with Visual C too and therefore cause the Windows installation to come with the needed C runtime support already installed this can and will vary depending on the Windows version and the amount of extra tools and utilities that you install. Also any extra custom application you install such as LabVIEW also comes of course with the necessary C runtime support that gets installed if not already present on the system, but depending on all this a particular C runtime version may or may not be present on any particular system. Basically you should never copy DLLs to a target system but install them with the proper installer for them which hopefully takes care about installing the correct C runtime support too.

Windows IoT is not a normal Windows installation at all, except the Windows IoT Enterprise version. The others are really just embededded kernels without any real Win32 subsystem. Accordingly many standard Windows DLLs like kernel32.dll, user32.dll and many more are not present there. It is basically a Windows installation with a much smaller embedded kernel that only supports Universal apps from the app store. Accordingly a normal LabVIEW build application that you created on your dev machine should NOT even be able to be started as they are build for x86 and not ARM and require a fully functioning Win32 subsystem. How do you target your IoT system?

There can't be as LabVIEW can't and never could load two VIs with the same name into the same application instance at the same time. So it will load the first VI, then attempt to load the second, seeing that it is already loaded, then compare the two. Obviously there isn't any difference between the two. While you could argue that the function could check the two VI names to be equal before attempting to do anything, you also have to consider that this function is not your average Joe toolkit. It is fairly advanced and there is something to say about not sanity checking every possible error on every VI boundary down several hiererachy levels. If the user of this function wants that check it's easily done before calling this function. If he forgets such trivialities he may not be the intended target audience for this function.

That's because you guys call it decimal point, but in Germany one says "Komma" when you mean to devide the fractional part from the decimal part of a number. So the language is consistent there. (German does also know the word "Dezimalpunkt" but generally the comma is used). The introduction of the decimal comma started in the 18th century in central Europe, most likely influenced from the French. The English speaking countries continued to use the decimal point. Switzerland is special as one generally talks about a comma but uses a point, but it is not fully standardised in Switzerland (most probably due to the German influence since about half of Switzerland is German speaking). However in nowadays computer settings the standard decimal character in all significant OSes is the decimal point for at least the Swiss German locale. So broadly speaking the decimal point is used in most English speaking countries and the decimal comma is used in most non-English speaking European countries. While kind of confusing I find that more easily understandable than the myriads of date and time formats used 😀. Not to forget that with date and time you end up with other "trivialities" such as time zones, different calenders and even leap seconds and years.

Michael, technically what you write is only true for an input array of exactly 5 elements. If you really always want to remove the last three elements the OP needs to use an Array Length node, subtract the number of elements he wants to remove from this length and wire that to the offset. In that case you can leave the size input unwired because it will default to the rest of the array.

Well looks like my case but I'm not aware that I have Java Script disabled anywhere. And with another page (different number at the end) I could suddenly download everything independent on if I was logged in or not.

Minimal extensions installed which should not affect this: Adobe Acrobat, Cisco Webex Extension, Google Analytics Opt-Out , Google Docs Offline, XML Viewer Chrome addons: Docs, Sheets, Slides Nothing else.

I get redirected to the nl-nl page anyhow no matter what I do. And on that I can't download any versions prior to the 2019 version no matter if I only select the runtime version or if I'm logged in or not. On the page that I get to when clicking on the LabVIEW icon on the earlier mentioned download portal I get to https://www.ni.com/nl-nl/support/downloads/software-products/download.labview.html# (without the number at the end) and while it seems I can download anything (the Download button is always enabled), nothing happens except a page refresh when pressing that button. On another link with a different number at the end that I found mentioned in a forum post I could download absolutely anything, including the Linux-Mac downloads!

They are revamping the download portal for their software. The idea seems to be that in the future you should be able to go through this page for all downloads and for previous versions it should only allow you to download versions for which you have a valid SSP. https://www.ni.com/nl-nl/support/downloads/software-products.html However that page is borked in many ways (as a lot on the NI webserver) and depending on from where you come it won't allow you to download anything (even simple runtime installations) even if you are logged in with an account that has an associated SSP license, or it will allow you to download absolutely everything even without valid user account login. 😭 Why am I not surprised!!

It's definitely possible. But depending on how well you implement it it will possibly not be a very realiatic simulation and mostly just allow you to execute the HMI without running into errors from calling non existent hardware. A good simulation is generally non-trivial to implement and having a good architecture helps in making it not a total disaster. Personally I tend to abstract away hardware by using LabVIEW OOP and defining a generic basic class that does nothing or implements a minimalistic simulation of the hardware and make the real hardware interface in a derived class from that basic class, possibly with different child classes for different types of hardware interfaces. Another approach that goes even one step further in abstraction would be to use a message based framework like the actor framework.

I did a recertification earlier this year and passed. Don't remember any question about dynamic project creation, but the X-Control questions where in there (about 3 I think) and the obligatory software development terminology stuff (which I find somewhat bogus as it often depends which software development book you have read in what the right keywords might be). They do now give a review of all the questions after you have submitted them for grading, so you can see where you did errors, and mine where indeed in X-Controls and the software development terms. Is it a bad test? Not really but some things could be arguable. I did go through the CLA recertification prep manual and also glanced through the Advanced LabVIEW Course Manual about X-Controls which helped me somewhat to pass this. Without doing that I would probably have failed.

That is because it is not a valid ZIP file. A ZIP file starts always with the two characters PK, sometimes with some (selfextractor) header in front. Your file does nowhere contain the PK identifier for a ZIP file. Also try to open the file in Windows Explorer and you get an error too, and when you open it in 7-ZIP it does recognize it as gzip format, which is a different format than ZIP. The correct fileending for this file should be .gz. The OpenG ZIP library specifically only can deal with proper ZIP files.

So when you run the VC++ example you get an error! Well that is hardly LabVIEW related isn't it? You must make sure that you pass the right VID (vendor ID) and PIC (product ID) as programmed in the chip. The chips should come with a default VID and PID from FTDI but it can be changed by a utility from FTDI. Check in the Windows device manager for your interface and in the driver settings you can see the VID and PID values, but they are in hexadecimal notation.

Check on stack overflow! These .Net functions can misbehave for certain paths as they do not properly escape all characters (specifically the % character) that should be escaped. But they might work for the OP's use case. https://stackoverflow.com/questions/1546419/convert-file-path-to-a-file-uri new Uri(@"C:\%51.txt").AbsoluteUri; This gives you "file:///C:/Q.txt" instead of "file:///C:/%2551.txt". Also you should probably close the .Net Refnum after use.

As I already mentioned in my first post (after an edit), this Windows API function does not convert to an URI but to UNC. And it does not work for a local path that you shared but only for a local path that was mapped from a network path. So assume you have a network share somewhere on your production server named PRODUCTION with a share TESTDATA then the UNC path to that is \\PRODUCTION\TESTDATA. If you map this path to a local drive P:\Production you can use above function to convert P:\Production\<some path> back into \\PRODUCTION\TESTDATA\<some path>. Nothing more and nothing less. These functions specifically do NOT deal with URI paths but only with UNC paths.

This should be a 32/64 bit safe implementation. Network Path Name 2016.vi

This implementation has a few limitations, one of them being that it will only work for 32 bit systems and also that it makes assumptions about how the buffer is allocated that may not necessarily true. Basically it assumes that the string the pointer in the first 4 bytes is pointing at are directly following the pointer itself in memory. While this is probably usually true there is no guarantee that this is the case as there might be certain memory allocation strategies used in the underlaying function that might place the actual string in some other location in the returned buffer. So beware when using this in your VI and make a notice that it will definitely not work as is for 64-bit LabVIEW. Also the title is indicating that this function is not the correct one to use. URI is the abbreviation for Universal Resource Identifier which usually follows the format (and that matches the example given by the OP) protocol://[gebruiker:wachtwoord@]host(naam)[:poort]/path The mentioned function will instead return the Windows UNC (Universal Naming Convention) path to a network shareable path if it exists, which has the format: //servername/share/path

I'm not really sure! That assumes that you would use key-values that are not representable in 7 bit ASCI. Definitely possible if they are defined by the operator through the UI rather than programmatically, but even then I'm not sure I can easily see the problem there. Things get wonky when you start to mix and match functionality between UTF and non-UTF aware systems but as long as they stay isolated from each other it shouldn't necessarily be a problem. That's why I never really bothered with the UTF-8 functionality in LabVIEW. It's not fully transparently implemented and given the legacy of various LabVIEW parts I'm very much convinced that there is NO possibility to implement it in a way that will not break backwards compatibility in several places quite badly. That's the main reason it never was released as a feature, since they could probably have thrown several dozen programmers at it and still not have a feature that would simply work without badly affecting the working of applications that are upgraded to the new version. The unoffical UTF-8 support in LabVIEW was a proof of concept project (most likely driven by one or two enthusiastic programmers in the LabVIEW team) and it showed that implementing it in a clean and unobstructive way is basically impossible, so there wasn't put anymore effort into it to make it a full feature that could be released. The problem starts at such basic issues like that many LabVIEW functions use exclusivley strings for data elements that are actually byte streams rather than text strings. The Flatten to String or Unflatten from String functions are the most notorious of them. They never ever should have been implemented using strings but byte arrays instead. It goes further with functions like the TCP Read and Write nodes. While the Write node does actually accept byte arrays for several versions now there is no way to change the TCP Read to return Byte arrays too. Same for File Read and Write and VISA Read and Write. Ultimately all those functions (except the Flatten and Unflatten) should probably have variants that allow to use either binary byte arrays and for backwards compatibiliy ASCI strings. Then there should be a also a new string datatype that carries an inherent encoding attribute with it and last but not least a library of nodes to convert various encodings from one to the other including into and from binary byte arrays. Extra bonus points for letting those nodes accept this new string type too and allow the configuration of an automatic conversion to a specific encoding when writing out or reading from. This would solve the problem of being able to write encoding aware code, it still leaves uncountable places in the LabVIEW UI and other internal places including things like the resource format of most of its files that would also need to be improved to allow for full UTF-8 support. And that part is an almost unmanagable construction site.

I'm afraid they aren't. The according palette isn't called "HTTP Client" for no reason. Implementing TLS on a listener (server) isn't that much different when using OpenSSL on C programming level but it does require a bit of a different setup than when implementing it on a client connection. And the glue to map it to a system similar to the standard LabVIEW network functions does get a little more complicated.

Many possibilities. 1) There might be a new and different INI file key that enables the dialog editor. 2) The dialog editor was completely removed in the released LabVIEW source code and only is present in NI internal builds of LabVIEW for testing and debugging. One or two strategically placed #if !RELEASE_BUILD ......... #endif pairs are enough for that. 3) There might be now a seperate NI internal tool (written in LabVIEW or compiled from the LabVIEW C++ source code) that you now have to use when wanting to edit those resource files. I would bet it is either 2) or 3).

Well to be honest LLVM won't be able to process a header file that references other header files with declarations that are used in your header without access to them. It needs access to those referenced headers somehow too and I doubt it comes preinstalled with all Mac OS X, Windows SDK, etc. etc. headers so you end up installing them somehow to your disk too and pointing LLVM to them. The import library wizard has internally this informations too, but once you start going down the path of creating the wrappers with such advanced functionality through scripting you end up in hell. There is simply no way such a "Wizard" can really know how the different information in such structures may or may not interact with each other and with other things in the API so you end up with a overly complicated interface that is very difficult to understand and allows you to still do lots of illegal things. The purpose of a proper LabVIEW DLL wrapper is to simplify the API as much as possible for the user without saddling him with subtleties like if you want this function to return 1000 samples you have to set this numeric to 8000 AND also Initialize an array with 1000 double values in order for the call to not crash. Or to return a string from the function to require the user to even have to specify the size of the buffer as the function documentation specifies that the function requires a buffer of at least 256 characters to fill in. Even such a simple thing as an API where you pass in a buffer that the function should fill in with information and a second parameter that tells the function how big the buffer really is, is already a total nogo for even the most advanced wizard, since there is no way the C syntax can describe the specific dependency between these two parameters. So the wizard will create two controls on the front panel and the uninformed user will wire a 1000 to the buffer size but leave the string control that should now contain 1000 bytes at its default of an empty string and -> boom! We humans after quite some dealings with these kinds of APIs often can infer the correspondence between these two parameters because of a more or less useful naming correlation between the two but even that can often go wrong (is the number in bytes, characters or numeric elements of the array type?). The only real information comes from the documentation, which surprisingly often fails to document these things accurately too, and then the only thing that remains are hopefully sample source code that shows you how these parameters are supposed to be assigned.