Jump to content

JKSH

Members
  • Posts

    494
  • Joined

  • Last visited

  • Days Won

    36

Posts posted by JKSH

  1. 15 minutes ago, Benoit said:

    I am trying to send email in LabVIEW with Asian character.

    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/ ).

  2. 16 hours ago, Michael Aivaliotis said:

    Is OpenG a dead library?

    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.

     

    2 hours ago, smithd said:

    Also, and I realize this is kind of petty...but why green? Why on earth...snowy mint?

    Probably similar to why websites from 20 years ago used garish clashing colours with cartoony animations :) ('Cos it was stylish at the time?)

  3. On 27/10/2018 at 10:46 PM, Michael Aivaliotis said:

    MediaWiki is super powerful, but not intuitive for new editors.

    Recent versions have a WYSIWYG editor.

    On 27/10/2018 at 10:46 PM, Michael Aivaliotis said:

    The problem was that we got struck with a rash of spammers. More like bots. They would go through and create hundreds of pages overnight. In that environment, you need moderators and editors to delete the pages and watch for edits. I was the only moderator and admin. So my plate was full. I ended up locking it down and forced it so that you had to have a login account to edit pages. On top of that, the login's had to be manually approved by me to prevent bot accounts.

    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.

    • Like 1
  4. 20 hours ago, patufet_99 said:

    Thank you for your comments. This seems to be as you mention and due to DNS timeouts as explained in the 2.2 of the upper link.

    JKSH: This is on the RT side, not the PC: if a non valid DNS server is defined in the PC there is no problem.

    Here is my updated guess: ;)

    1. The sbRIO first tries to contact the DNS server at the defined address.
    2. 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.
    3. 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

  5. On 9/16/2018 at 9:40 PM, patufet_99 said:

    As the Shared Variables are deployed locally on the sbRIO, why the DNS server (if there is none) should have any effect on the deployment? Any hints?

    Here is my guess:

    1. Your PC tries to contact the DNS server at the defined address.
    2. 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.
    3. 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.

  6. 1 hour ago, shoneill said:

    If I wait long enough, it does eventually recover, but at that point it's hard to differentiate between this and "normal" LV crashes where it just sits there and does nothing and will never recover.  I say "normal" because it happens quite a lot. :o

    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.

  7. 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.

    8 hours ago, AInvisibleNinja said:

    do you have any good resources for writing DLL wrappers? Maybe books or something? I haven't been able to find anything, but I would like to read up on the issue in case we ever encounter it again.

    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".

  8. 9 hours ago, AInvisibleNinja said:

    virtual void AddToPosition(double adjAmount) = 0;

    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.

     

    9 hours ago, AInvisibleNinja said:

    I'm thinking the issue is from it being a C++ DLL inside of a C DLL. Do you have any tips or suggestions for getting a C++ DLL to work with Labview?

    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.

  9. 1 hour ago, AInvisibleNinja said:

    Does anyone have any idea what's going on or what I can do to fix it?

    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?

     

    1 hour ago, AInvisibleNinja said:

    It also seems like it's importing the names of the functions incorrectly as well.

    What should the correct names be?

  10. 3 hours ago, dhahmed said:

    PLEASE I need your help !

    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.

    • Like 1
  11. 14 hours ago, rolfk said:

    On Windows 32-bit, (and Pharlap ETS)  LabVIEW indeed assumes byte packing (historical reasons, memory was scarce in 1990 and that is when the 32-bit architecture of LabVIEW was built) and you have to add the dummy element fillers to make the LabVIEW cluster match a default C aligned structure. On Windows 64-bit they changed the alignment of LabvIEW structures to be compatible to the default alignment of 8-byte most C compilers assume nowdays.

    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?

  12. 7 hours ago, patufet_99 said:

    When defining a LabVIEW cluster to match the DLL structure, will LabVIEW do the same? If in my cluster there is a U8 variable and then a U32, will anyway the U8 take 4 bytes?

    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.

  13. 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.

  14. 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.

  15. 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)
    On ‎12‎/‎04‎/‎2018 at 9:46 PM, torekp said:

    I'm not trying to use a DLL in Labview.  I'm trying to use a DLL (that Labview created) in C++.

    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);
    
    	// ...
    }

     

    • Like 1
  16. On ‎11‎/‎04‎/‎2018 at 10:53 PM, torekp said:

    So I created a DLL from a Labview VI that has a 2D array input (and some scalar inputs) and some 2D array outputs.  Labview creates a .h file with these lines

    DoubleArray.PNG

    And then it defines the 2D array arguments to my function as being of this type: "void __cdecl Linear_discrim_4dll(DoubleArray *dataObsFeat, int32_t grpAsz," etc etc.  Trouble is, I have no idea how to fill out this structure so that the DLL can use it.  Say for simplicity I had a 2 by 3 input called dataObsFeat with elements {1,2,3; 11,12,13}; how would I create the object with these values in C or C++ and pass it to the function?  I am a total C++ noob, in case it isn't obvious.

    See the memory layout of Arrays at http://zone.ni.com/reference/en-XX/help/371361P-01/lvconcepts/how_labview_stores_data_in_memory/

     

    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.
     

     

×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.