JKSH

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.

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/

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.

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.

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

Perfectly doable in LabVIEW too!

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

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

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.

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.

If I'm not mistaken, the Upgrade Code is simply a GUID: https://stackoverflow.com/questions/4313422/generate-guid-in-windows-with-batch-file

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/

Can you say, "Here is the STOP button! The big red 'X' in the top-right corner of the window"? 😁

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?

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.

How about wiring the string into a case structure selector? Case "": Do your special output Case Default: Wire the string into the JSON VIM

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.

@Rolf Kalbermatter has the answer, as usual: The parameter type is a pointer-to-InstanceDataPtr (i.e. a pointer-to-a-pointer, or a Handle in LabVIEW terms). LabVIEW owns the handle, you own the data pointer: You allocate the data in Reserve and you can access that same data in Unreserve/Abort. LabVIEW can't free your pointer since it doesn't know the type/size of your data. // C++ example #include <ctime> MgErr reserveCallback(InstanceDataPtr* instanceState) { if (*instanceState == nullptr) { time_t* start = new time_t; *start = time(nullptr); *instanceState = start; } else { // We should never reach this point, unless the InstanceDataPtr was not cleared after the last run } return 0; } MgErr unreserveCallback(InstanceDataPtr* instanceState) { time_t end = time(nullptr); time_t* start = static_cast<time_t*>(*instanceState); // Calculate how much time has passed between reserving and unreserving double elapsedSecs = difftime(end, *start); // Note: The handle must be explicitly cleared, otherwise the LabVIEW IDE will pass the old pointer // to reserveCallback() when the VI is re-run delete start; *instanceState = nullptr; return 0; }

It's a pretty common spam technique, designed to sneak spam links into innocent-sounding posts. A moderator should clean out the spam.

That means it is using OpenSSL 1.0.x or earlier. In OpenSSL 1.1.0, "libeay32" was renamed to "libcrypto"

Or even better: Replace "Write To Text file"/"Read From Text File" with "Write To Binary File"/"Read From Binary File". The output of "Flatten to String" is not text. (String != Text)

If it's a new-ish installation, the uninstall utility is replaced by NIPM. But that does also provide a comprehensive list of installed NI software.

I don't have one for sale, but our customers would like to purchase cRIO 904x too. Unfortunately, current lead times from NI are around 12 weeks.

Ouch. Can you please wave this in NI's face? https://forums.ni.com/t5/LabVIEW-2021-Public-Beta/bd-p/labview-2021-beta

For those who don't want to watch the video, the list of improvements is also published in the Public Beta: https://forums.ni.com/t5/LabVIEW-2021-Public-Beta/LabVIEW-2021-Beta-Now-Available/td-p/4144143 I don't think that's a bad thing. NI can't exist as a silo and still hope to be relevant to the rest of the world. Better interoperability makes it easier to justify using LabVIEW in a multi-technology environment (which is often the case in large organizations), and makes it easier for scientists and engineers to start using LabVIEW. Yeah, those are a bit vague. The second half of the list sounds like the porting over of features from NXG, which seems like a sensible direction (consolidate existing features before coming up with new ones)