Jump to content

JKSH

Members
  • Posts

    497
  • Joined

  • Last visited

  • Days Won

    36

Posts posted by JKSH

  1. 5 hours ago, Neil Pate said:

    Oh yes the other weird thing is that when you do get a Data Change event you get the data coming in as a variant, but unlike regular variants this one seems to know nothing about its own type. This actually caused a bit of drama for me but managed to find a work-around as the data change event does actually include the type, so I was able to shove it back into the variant.

    Yuck. Has NI been prodded about this?

  2. I just did a quick test. It looks like LabVIEW assumes that the email text is encoded in your PC's default 8-bit encoding. Then, LabVIEW automatically tries to convert the text to UTF-8.

    I think this means the only way to send Japanese emails through LabVIEW is to configure your whole PC to use Japanese 8-bit encoding and/or use the Japanese version of LabVIEW. :(

    (I'll have to leave for now, sorry. I'll try some more tests tonight to see if anything else works)

     

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

  4. 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?)

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

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

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

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

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

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

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

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

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

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

×
×
  • Create New...

Important Information

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