Jump to content


  • Posts

  • Joined

  • Last visited

  • Days Won


Everything posted by JKSH

  1. Only for LabVIEW Communications type applications (on PXI). FPGA through RIO (and RIO in general) is not yet supported. Note that Python support is Windows-only. I was hoping to use the Python Node on my LinuxRT cRIO, but no dice. Related: http://www.ni.com/pdf/products/us/labview-roadmap.pdf > Is it using a VI at all? Yes, but the file format is different. > Does it support scripting Not yet (see Roadmap link) > and OO? Mostly. But we can't have type definitions inside classes. > Could I use llb/lvlib/lvlibp/...? llb: Gone in NXG (which is a good thing; these are terrible for source control) lvlib: Yes lvlibp: Not sure > Is the FP resizable?  No. My company finds WebVIs pretty useful. We've started using it for some real projects (but only for the web client -- we still use LabVIEW Classic for other parts of the project, including the web server)
  2. You could save the data to file and then use the System Exec VI to run your choice of Linux chart generation tools like gnuplot (a command-line application) or Matplotlib (a Python library).
  3. Just got "The page you requested may have moved, been deleted, or is inaccessible. Search below for other content, or contact NI for assistance." on all 3 Fall 2018 links
  4. No problem. We are happy to help, but we'd appreciate it if you try to follow our instructions. Good luck with learning LabVIEW.
  5. Open LabVIEW and click Help > Find Examples... then search for "XML". @crossrulz gave you this advice earlier.
  6. Why do you refuse to use the code that @Benoit already wrote for you? Like I said before, your XML file is corrupted. The XML palette won't work on it.
  7. Where did you get this XML document from? It is corrupted (There are many stray "-" characters, so XML parsers will give you an error) Also, take the time to follow @crossrulz's advice:
  8. Yes, that sounds like a solid solution. Good thinking, and congrats!
  9. 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)
  10. 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/ ).
  11. Same symptoms and workaround for me, on Firefox 63.0.1 (Windows 8.1)
  12. 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
  13. 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.
  14. 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
  15. 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.
  16. @LogMAN What happens if you load the project in a different dev machine?
  17. 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.
  18. 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".
  19. 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.
  20. 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?
  21. 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.
  • Create New...

Important Information

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