JKSH

First, how do you input the Asian characters into your program?

What encoding do you use for those characters? LabVIEW's email VIs send emails assuming the UTF-8 encoding (http://zone.ni.com/reference/en-XX/help/371361P-01/lvcomm/smtp_client/ ); you might need to encode your Asian characters in UTF-8 first. I haven't tried this myself, but you could also try calling the Set Headers VI (http://zone.ni.com/reference/en-XX/help/371361P-01/lvcomm/smtp_set_headers/ ) and set the Content-Type header to match your non-UTF-8 encoding (https://www.emailonacid.com/blog/article/email-development/the_importance_of_content-type_character_encoding_in_html_emails/ ).

This falls under @hooovahh's earlier quote, "many OpenG functions have native equivalents, but usually lacking in some way or another when it comes to what it can do." NI's Create Folder node throws an error if the directory already exists.

Dead is a strong term. I'd say it's stagnated and left behind the times, but it still offers some benefits. My company still uses parts of it regularly (like Create Dir if Non-Existent and the VArray/VCluster VIs), even with LabVIEW 2017. Probably similar to why websites from 20 years ago used garish clashing colours with cartoony animations ('Cos it was stylish at the time?)

Same symptoms and workaround for me, on Firefox 63.0.1 (Windows 8.1)

First, what do your lecture notes say? Anyway, this tutorial covers the components you need: http://www.ni.com/getting-started/labview-basics/execution-structures.htm to get started

Recent versions have a WYSIWYG editor. Requiring an account makes sense, especially if you already have an SSO to integrate MediaWiki accounts with forum accounts. A project I'm in uses the Moderation extension for MediaWiki: https://www.mediawiki.org/wiki/Extension:Moderation. It's quite decent; it shows a list of pending edits to be approved/rejected, so the public won't ever see the vandalism and a moderator won't have to waste time reviewing an edit that has already been greenlit by another moderator. Moderators can also mass approve/reject edits by a single account. You can also whitelist certain users so their edits get auto-approved.

Here is my updated guess: The sbRIO first tries to contact the DNS server at the defined address. The sbRIO waits for a response from the DNS server. However, since the DNS server is not reachable, there is no response. So, the sbRIO waits 5-10 s until the timeout is reached. After the DNS server connection times out, the sbRIO proceeds to do its next task: Accept a shared variable deployment from the PC. In a nutshell, it looks like networking and the Shared Variable Engine are synchronous. While the sbRIO is waiting for a response from a remote device, it cannot process any other network requests related to Shared Variables. I've seen similar symptoms in another case: My CompactRIO was trying to read a Shared Variable hosted on a PC. However, my PC's firewall was not configured properly so the cRIO was not allowed to read the SV. As a result, all other Target-Relative variables hosted on the cRIO froze for long periods of time

Here is my guess: Your PC tries to contact the DNS server at the defined address. The PC waits for a response from the DNS server. However, since the DNS server is not reachable, there is no response. So, the PC waits 5-10 s until the timeout is reached. After the DNS server connection times out, the PC proceeds to do its next task: Deploy shared variables. When both devices are on the network, step #2 is very fast so you reach step #3 very quickly.

@LogMAN What happens if you load the project in a different dev machine?

This brings back memories!

One way to tell is to look at the Disk Activity under Resource Monitor in Windows. If LabVIEW is working on files, Resource Monitor will show you exactly which files are being touched. If LabVIEW has frozen, There will be no disk activity.

I had a quick look at the ClearPath-SC website. It seems like they have a .NET API. If your application is for Windows only, you could use the .NET API directly inside LabVIEW without a wrapper DLL. At its core, it's just learning how to use C++ to write a DLL that is compatible with C programs. Once you know how to write such a DLL, apply the restrictions that @smithd mentioned to make it LabVIEW-compatible. Here, "Wrapper" simply describes the use-case for the DLL. LabVIEW calls your own custom DLL which in turn calls the ClearPath-SC DLL. Your custom DLL is called the "wrapper".

Ah. The wizard only understands C functions. virtual and = 0 are C++ concepts that don't exist in C. Furthermore, this looks like a member function of a class, which also doesn't exist in C. You must create your own wrapper DLL. Your DLL must be written in C++, but the functions that you expose must be marked extern "C" -- see https://stackoverflow.com/questions/1041866/what-is-the-effect-of-extern-c-in-c If you have no prior C/C++ experience, I highly recommend you find someone in your company who does. Writing a wrapper DLL is not something that can be taught in one forum post.

The dialog tells you what's going on and what you can do to fix it: "The function is not declared in the header file.... Check the header file to make sure it contains declarations of the function.... Undefined symbols can prevent the wizard from recognizing functions." Which header file did you provide? Have a look inside. Does it look right? What should the correct names be?

Help us help you. Please provide details on what kind of help you want: Do you want us to: Give you some ideas on how to start? Or review code that you've already written? Or write the code for you? Also, please provide details on how much LabVIEW experience you have and how much general programming experience you have.

I didn't know that. Do you mean 64-bit Windows or 64-bit LabVIEW? How does 32-bit LabVIEW behave on 64-bit Windows?

No. LabVIEW assumes packed data types so a U8 followed by a U32 will take 5 bytes of space, not 8 bytes. If you control the .h file, you can use #pragma pack to pack your struct. If you don't control the .h file, you can insert dummy BYTEs into your cluster.

From a quick poke through the property nodes, I could only find a way to script label fonts (of FP controls, BD nodes, etc.). I couldn't find a way to set fonts at the VI level. This post suggests lots of font settings aren't available through scripting: https://forums.ni.com/t5/LabVIEW/VI-Scripting-in-LabVIEW-2012-change-font-size-of-tab-control/td-p/3011091 Expansion behaviour that depends on screen settings is something that I'd consider a bug. It will only become more prevalent as the screens become more varied in DPIs. Would you be willing to report this to NI? I doubt we'll see a change in current-gen LabVIEW, but hopefully NXG will be protected from this.

You need to install the Moxa drivers on your host PC (Windows only). Then, use the Moxa NPort Adminstrator application to configure your serial ports. After that, your PC will treat the Moxa ports just like an on-board serial port or a USB-to-serial converter. This means your VI should read/write the Moxa serial ports using VISA, not TCP/IP.

Hi @jmor, thanks for sharing your work. Are you planning to share the source code for the client and the server? If not, then a different license would be more suitable than the Non-Profit Open Software License 3.0 (Note: "Freeware" and "Open Software" are different things)

Cross-post: https://forums.ni.com/t5/LabVIEW/URGENT-Database-in-NXG-2-0-and-2-1/td-p/3783489 To answer your question, see the "Software Compatibility" tab at http://www.ni.com/en-au/shop/labview/compare-labview-nxg-and-labview.html

My apologies, I remembered wrongly and gave you wrong code. I've fixed my previous post now. The syntax is funny because: DoubleArrayBase is the struct itself. DoubleArray is a pointer to a pointer to a DoubleArray struct (yes, you read that right) Everything in the first half of my previous post (up to and including the first block of code) still applies to C++ code that reads array data from the DLL. C++ code that writes array data into LabVIEW is a bit more complex. Look in your LabVIEW-generated header file again: Do you see functions called AllocateDoubleArray() and DeAllocateDoubleArray()? // In the LabVIEW-generated header, mydll.h typedef struct { int32_t dimSizes[2]; double element[1]; } DoubleArrayBase; typedef DoubleArrayBase **DoubleArray; DoubleArray __cdecl AllocateDoubleArray (int32_t *dimSizeArr); MgErr __cdecl DeAllocateDoubleArray (DoubleArray *hdlPtr); // In your code #include "mydll.h" int main() { // Allocate and write the input array int32_t datasz[2] = {2, 3}; DoubleArray arrayIn = AllocateDoubleArray(datasz); (*arrayIn)->element[0] = 1; (*arrayIn)->element[1] = 2; (*arrayIn)->element[2] = 3; (*arrayIn)->element[3] = 11; (*arrayIn)->element[4] = 12; (*arrayIn)->element[5] = 13; // Call your function DoubleArray arrayOut; Linear_discrim_4dll(&arrayIn, &arrayOut, 2, 3); // Extract data from the output array, ASSUMING the output is 2x2 double cArray[2][2]; cArray[0][0] = (*arrayOut)->element[0]; cArray[0][1] = (*arrayOut)->element[1]; cArray[1][0] = (*arrayOut)->element[2]; cArray[1][1] = (*arrayOut)->element[3]; // Free the input array's memory DeAllocateDoubleArray(&arrayIn); // ... }

See the memory layout of Arrays at http://zone.ni.com/reference/en-XX/help/371361P-01/lvconcepts/how_labview_stores_data_in_memory/ dimSizes contains the sizes of 2 dimensions. element is the interleaved array. Even though the header suggests its size is 1, its real size is dimSizes[0] * dimsizes[1]. (This technique is called the "C Struct Hack": see https://tonywearme.wordpress.com/2011/07/26/c-struct-hack/ or https://aticleworld.com/struct-hack-in-c/) If you create the 2-by-3 array in LabVIEW and pass it to your DLL, you can read it in C/C++like this: void vi1(DoubleArray *array_fromLv) { double cArray[2][3]; cArray[0][0] = (*array_fromLv)->element[0]; cArray[0][1] = (*array_fromLv)->element[1]; cArray[0][2] = (*array_fromLv)->element[2]; cArray[1][0] = (*array_fromLv)->element[3]; cArray[1][1] = (*array_fromLv)->element[4]; cArray[1][2] = (*array_fromLv)->element[5]; // Do stuff... } To pass array data from the DLL to LabVIEW, the idea is to do the opposite: void vi2(DoubleArray *array_toLv) { double cArray[2][3]; // Do stuff... (*array_toLv)->element)[0] = cArray[0][0]; (*array_toLv)->element)[1] = cArray[0][1]; (*array_toLv)->element)[2] = cArray[0][2]; (*array_toLv)->element)[3] = cArray[1][0]; (*array_toLv)->element)[4] = cArray[1][1]; (*array_toLv)->element)[5] = cArray[1][2]; } VERY IMPORTANT: Before your DLL writes any data, you must properly allocate the memory. There are 2 ways to do this: Pre-allocate the array in LabVIEW, pass this array into the DLL, and let the DLL overwrite the array contents, OR Call LabVIEW Manager functions (http://zone.ni.com/reference/en-XX/help/371361P-01/lvexcodeconcepts/labview_manager_routines/ ) to allocate or resize the array before writing the data. These functions are poorly-documented, however.