Jump to content

JKSH

Members
  • Posts

    461
  • Joined

  • Last visited

  • Days Won

    30

Everything posted by JKSH

  1. I don't have an answer for your activation issue, but you're not alone: https://lavag.org/topic/22358-nis-new-software-subscription-model/ https://forums.ni.com/t5/LabVIEW/LabVIEW-subscription-model-for-2022/td-p/4204448
  2. That's rather worrying then, given that Farnell is now an "Authorized Distributor" for NI.
  3. Ain't this it? https://uk.farnell.com/ni/777849-35/labview-real-time-deployment-license/dp/3701592
  4. NI Linux RT is just another Linux distro. If you can install Linux on your device, you can probably install NI Linux RT which comes with the LabVIEW runtime. I'm not sure what the licensing implications are. You probably won't get NI hardware driver support, however. The Zynq FPGA is a completely different beast. The only other widespread dataflow language in industry (that I know of) is Simulink, so... The best language is one that you are experienced and competent in. The next best language is one that you have resources and drive to learn.
  5. Some hardware has a minimal sample rate. Double-check that the "SampClk.Rate" property does return exactly 250 Hz -- If it's actually higher, then you'll never empty your buffer and it just keeps growing. Use a producer-consumer architecture (example: https://forums.ni.com/t5/Example-Code/DAQmx-Encoder-Measurement-with-Producer-Consumer-Architecture/ta-p/3493445) Your DAQmx while-loops should be dedicated to calling DAQmx Read.vi only. The data should be sent to a different loop (via a queue or a Channel Wire) for writing. Beware: Since you are writing waveforms but you discard some data chunks, your file timestamps will be wrong. When you send your waveform to the data writing loop, send the relevant TDMS Group Name too.
  6. They do provide a built-in image uploader, which we're expected to use instead of off-site links: I had no problems like this: https://stackoverflow.com/questions/36852665/adding-delay-in-data-acquisition-in-labview/36857051#36857051
  7. I don't have experience with Beckhoff products, but a customer asked us to integrate a UEI Cube a few years ago. I remember thinking that their API was a bit more convoluted than DAQmx. This customer got non-rugged accessories so they struggled a bit to get good shielding, but I have seen MIL-STD compliant hardware in UEI's product line.
  8. That is... different from my experience. I had an old installation of LV2017 which has no expiry. When I added the LabVIEW Real-Time Module 2017 to it in April 2020, it was given an expiry date of August 2020. When August 2020 came, I had to re-activate LabVIEW Real-Time Module 2017 (but not LabVIEW 2017). And this repeated itself in August 2021. My employer had been using the old NI Developer Suite for over a decade and this still kicked in -- we never had expiry dates before.
  9. This is unrelated to the LabVIEW version, and unrelated to perpetual vs. subscription licenses. In recent years, NI's license servers have changed things such that all activations are only valid until the next August -- Even perpetual licenses must now be re-activated annually. So if you install and activate those same older versions on a different PC today, they too will expire in August 2022.
  10. I used the Web module with SystemLink, but not with Python. It is somewhat (not very) responsive; there is a lot of room for improvement. See the 2022 posts at Not personally, but NI does have official DAQmx Python API. It should work: https://nidaqmx-python.readthedocs.io/en/latest/
  11. I used the NXG 5.0 Web Module (direct precursor to the G Web Development module) for a large SystemLink-hosted project. The biggest issue for me is missing functionality. Despite SystemLink touting Tags + Messages + Files as the 3 pillars of data transfer, NI did not provide a Web Module API for downloading/uploading files from/to a SystemLink server. I thought... "That's OK, I'll just use the raw HTTP API instead". And then I found out that the HTTP API itself was unfinished. NI provides a WebVI for making a HTTP Multipart request (which is required for uploading files), but if you open up that VI it simply spits out an error constant that says, "feature not implemented". So I had to implement it in JavaScript in the end. The next headache is the rigid UI. It is near impossible to get the UI to even resize with the browser window; the result feels rather unprofessional next to non-NI web UIs. The Web Module is fine for making very basic, static dashboards. But if you want to do anything complex/interactive/dynamic, you'll need to delve into HTML + CSS + JavaScript.
  12. It's more than "bordering spam"; it's a common tactic used by spammers in forums across the Internet: One account posts a link and another extols its virtues while speaking as if they are a 3rd party.
  13. VMware 15.5.5 and newer can run alongside Hyper-V: https://blogs.vmware.com/workstation/2020/05/vmware-workstation-now-supports-hyper-v-mode.html
  14. Not the example you were thinking of, but this one was hilarious: https://forums.ni.com/t5/LabVIEW/Compiler-is-Too-Smart-for-My-Own-Good/td-p/4188524
  15. I'm pretty sure remote time syncing ("remote" as in "light-years from civilization") is a core use-case. Try asking at the Linux RT forums. Relevant NI engineers are quite active there: https://forums.ni.com/t5/NI-Linux-Real-Time-Discussions/bd-p/7111
  16. Does your institution have a school of computer science, software engineering, or similar? If you are allowed to, perhaps you could sit in on some of their introductory lectures.
  17. One thing to keep in mind: LabVIEW and Python are high-level languages, while C and C++ are low-level languages. High-level languages are easier to get started with, and they provide some protection against common errors. For example, if you use an invalid reference in LabVIEW, you get a helpful error messsage telling you where the issue is; if you use an invalid pointer in C/C++, you could get silent memory corruption. Low-level languages can be more powerful and efficient if you know how to use them properly. However, it does take a lot longer to learn them properly. Whichever path you choose, the guidance of an good experienced teacher can get you further and faster then online tutorials.
  18. If I'm not mistaken, the Upgrade Code is simply a GUID: https://stackoverflow.com/questions/4313422/generate-guid-in-windows-with-batch-file
  19. What's the context? Traditionally, I've treated good desktop app design as different from good industrial HMI design as different from good web app design, etc. But, contemporary designers are moving towards a unified approach. What are your thoughts on Google's Material Design, Microsoft's Fluent Design, or Apple's Human Interface Guidelines? https://material.io/design https://www.microsoft.com/design/fluent/ https://developer.apple.com/design/
  20. Can you say, "Here is the STOP button! The big red 'X' in the top-right corner of the window"? 😁
  21. Missing as in "field does not exist in the object", or missing as in "field exists but the value is an empty string"? The latter is not truly missing. It exists, and its value is an empty string. The former can be handled using the "Data Type and Default Value" inputs Sounds like you're using "Find Item.vim"? Make use of the "Found" output, OR switch to "Find Item (as LVtype).vim" to specify the default value. How do you envision providing the default value if you are able to filter out the proposed "Empty String" error?
  22. The current pink wire datatype needs to remain as a "byte string" plus "locally encoded text string" to maintain backwards compatibility. A new type of wire (Purple? Darker than pink, paler than DAQmx wires?) should be introduced as a "universal text string" datatype. Explicit conversion (with user-selectable encoding) should be done to change pink wires to purple wires and vice-versa. Binary nodes like "TCP Read"/"TCP Write" should only use pink wires. Purple wires not accepted. Text nodes like "Read from Text File"/"Write to Text File" should ideally only use purple wires, but they need to allow pink wires too for backwards compatibility. VI Analyzer should flag the use of pink wires with these nodes. Perhaps a project-wide setting could be introduced to disable the use of pink wires for text nodes.
  23. How about wiring the string into a case structure selector? Case "": Do your special output Case Default: Wire the string into the JSON VIM
  24. If you only need to read the basic standard messages defined in J1939, then you can can treat the frames like any regular CAN frame. You just need to map the frame IDs to J1939 PGNs (for example, CAN frame ID 0x0CF00401 is for "Electronic Engine Controller 1" and bytes 4-5 contain the "Engine Speed" value) However, if you need to do do complex things like read multi-frame data or send a command and read the response, then you need to write a lot more custom code. Fortunately, NI has provided an example that covers a big chunk of what you need with the NI-9853: https://forums.ni.com/t5/Example-Code/J1939-Transport-Protocol-Reference-Example/ta-p/3984291 (use the non-XNET code) On the bright side, since you're doing FPGA programming, it doesn't matter if the CAN module is on an Ethernet expansion chassis or if it's plugged directly to your controller -- your code would be the same either way AFAIK, that only provides mapping for the basic messages that fit within a single frame, and some basic standard hanshaking + diagnostics. NI-XNET has no built-in support for multi-packet data or complex comms. I used the XNET example from https://forums.ni.com/t5/Example-Code/J1939-Transport-Protocol-Reference-Example/ta-p/3984291 as a starting point, but still had to write a lot of custom code to encode/decode messages and handle command-response handshakes.
×
×
  • Create New...

Important Information

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