JKSH

I'm guessing that the library's functions are not thread-safe. Without forcing the CLFN to use the UI thread, it could use different threads to call the library functions... thus causing a crash.

@Aristos Queue You're welcome. Glad I could help. How about storing the elements from "TextIcons.Ignore" in a Set instead of an Array?

I do have an implementation of "Split English CamelCase" that handles acronyms: https://github.com/JKSH/LQ-CodeGen/blob/labview-api/src/LabVIEW/Icons and Wires/Name to Icon Lines.vi -- It's based on a shorter regex and currently doesn't handle digits, underscores, or plurals-of-acronyms. I won't be trying to update the icon generator or VI Analyzer within the next 2 months, but someone who wants to try is welcome to use my VI as a starting point.

There are some examples and discussions on the NI forum: https://forums.ni.com/t5/Machine-Vision/Using-OpenCV-library-in-LabVIEW/td-p/648429?profile.language=en https://forums.ni.com/t5/LabVIEW/Creating-a-dll-in-Visual-Studio-2015-to-pass-an-image-through/m-p/3334086?profile.language=en

The "Flatten to JSON" and "Unflatten from JSON" nodes in NXG WebVIs are essentially the same as the ones built into classic LabVIEW. Both are incapable of processing enums or timestamps. As a workaround, you can create a "bridging" typedef (GType) which replaces enums and timestamps with strings. Use that with the NXG JSON parser, and then convert it to your "real" GType.

Which edition of LabVIEW did you install? The Application Builder comes with LabVIEW Professional. It is not included with LabVIEW Base or LabVIEW Full.

I believe the Python Nodes only work on Windows targets: https://forums.ni.com/t5/LabVIEW-Real-Time-Idea-Exchange/Python-Node-support-on-LabVIEW-Realtime-systems/idi-p/3904897?profile.language=en

It's not related to latest vs. older. The patches don't require a login to download (even 2009 SP1 Patch). The full versions require logging in with an account with an active SSP. How does NI, the software's author, see it? Talk to them. If they give you the go-ahead, then go for it.

I haven't tried WINE, but there is a Linux installer for non-community versions of LabVIEW: https://www.ni.com/en-us/support/downloads/software-products/download.labview.html#344886 (It uses RPM packages)

Shorter alternative A, involving a console: > git branch -f <real_branch> > git checkout <real_branch> The first line forces real_branch's pointer to move from its old spot to your current spot. The second command moves your HEAD from your anonymous branch to your named branch. Shorter alternative B, involving a strong stomach: Delete <real_branch> (yes, you read that right). Create a branch called <real_branch> on the detached head commit. (If the original <real_branch> tracked a remote branch) In SourceTree's "Branches" nav pane, right-click <real_branch> and click "Track remote branch". If it helps, think of it as merging the commit histories of the 2 branches, rather than merging code. Its formal name is a "fast-forward merge".

You might need to try different models of keyboards. See my previous message: Some keyboards work, some don't. Also, after you plug the keyboard into your laptop, you must insert the keyboard into the VM (in VirtualBox, click Devices > USB > [Name of USB Keyboard]).

You're almost there. The NI Linux Real-Time Recovery system is incompatible with the VM's keyboard^. When you reach the prompt, "Do you want to continue? [y/N]", make sure you have a physical USB keyboard connected to your PC. "Insert" it into your VM (on English VirtualBox, it's Devices > USB > [Name of USB Keyboard]), then use the USB keyboard to enter "y". You might need to try different keyboards; I found that: Microsoft Wired Keyboard 600 did not work Logitech K235 worked ^Earlier, you were able to select "Verbose mode" with the VM keyboard because you were still in the GRUB bootloader, not in the NI Linux Real-Time Recovery system yet. GRUB is compatible with the VM's keyboard.

I presume you mean the 3D Cartesian Coordinate Rotation VIs. The NI documentation has a decent description of what they do: https://zone.ni.com/reference/en-XX/help/371361R-01/gmath/3d_cartesian_coordinate_rotation_euler/ These are polymorphic VIs. By default, they take an array of coordinates. If you just want to rotate a single point, select the "Scalar" version of the VI (Put the subVI on your block diagram, then Right-click > Visible Items > Polymorphic VI Selector) The 3x3 matrix is the transformation matrix, which is a concept described in linear algebra. There are different types of transformations: Translation, rotation, shearing, scaling, etc. In a nutshell: Think of your 3D point-coordinates as a 3x1 matrix (also called a column vector). If you multiply a column vector by a 3x3 matrix, you will get a new column vector. That new vector will contain your "transformed" point-coordinates.

Unicode has the ability to store text from multiple languages at the same time. For example, a Unicode file (or Unicode string) can contain French, Russian, Arabic, and Chinese texts simultaneously. However, when you "convert to ASCII"*, you lose that ability. The converter can only output text that matches your Windows locale. So, if your computer is set to a French locale, you cannot convert Russian text. You need a Russian VM to successfully convert Russian text. (*ASCII is not the correct name here, but I digress) Anyway, what version of LabVIEW are you using? If you have LabVIEW 2017 or newer, then your license also gives you access to LabVIEW NXG. NXG has proper, built-in support for Unicode so you don't need to force, interpret, or convert anything.

Does a reboot fix things? If not, try clearing your font cache: https://winaero.com/blog/rebuild-font-cache-windows-10/

As a workaround, you can transfer files into a USB stick from your host, and then attach the stick to your VM.

Ah, you're right. Thanks for correcting me. That explains the why @Xin Li found that "some queries are not executed": If 2 web service VIs try to execute a write query at the same time, one of them will fail.with an SQLITE_BUSY error and the data is lost.

Write extra code inside your web service VIs. The code should take all the query details (query type and parameters) and take all the SQL VI outputs (results, error clusters) and log them to a text file on disk. However, multiple VIs won't be able to open the log file simultaneously, so you should create a dedicated "consumer loop" in your application. Your web service VIs can pass the log data to the consumer loop via a queue. Although text files don't support concurrent writes, SQLite does. However, it is not bulletproof and it's possible for it to fail: https://www.sqlite.org/lockingv3.html That's why we recommend that you add logging code so that you can see what's going on. [EDIT: SQLite does not support concurrent writes] How do you "see" the error? You can't easily use Probes in reentrant VIs. That's why a log file is recommended.

Let your application log all queries to a file. Be sure to log the execution results and errors too. Are any queries missing? Do you see any errors?

No problem. It's not clear to me: Does your lab already use a LIMS? Or does your supervisor want to introduce a new LIMS? The LIMS documentation will tell how how to integrate your test data into the LIMS. Read it to find out.

Can you explain in more detail what you mean by "LIMS compatibility"? Which part(s) of a LIMS should the software talk to? What does your software do? Ask your supervisor for the LIMS technical manual or user manual. That should give you the technical details of the brand of LIMS that they're using. This webpage describes a LIMS in general: https://thirdwaveanalytics.com/blog/what-does-a-lims-do/

Voted ages ago. Thanks for posting detailed instructions, @hooovahh: https://forums.ni.com/t5/NI-Linux-Real-Time-Discussions/NI-Linux-Real-Time-PXI-x86-VM/m-p/3561064/highlight/true?profile.language=en#M2107 That's what helped me get started in the first place!

Yes, that can do the job. It will take some time to write the script, however. (I'd set aside a few days if you've never done VI scripting before) Could you simply modify LibA instead of replacing it with a different library with the same interface?

Unfortunately, there is no straightforward way to do this in LabVIEW. I can think of one trick which takes advantage of the LabVIEW Project Explorer: When a library gets renamed or moved, the Project Explorer automatically updates the links in all of the project's VIs. So, Close LabVIEW. Temporarily delete or move LibB away to a completely different folder where it can't be found by LabVIEW. Open your project's .lvproj file. Use the LabVIEW Project Explorer to rename LibA.lvlib to LibB.lvlib, saving it in the folder where the real LibB used to be. This will update all your project VIs' links. Click "Save All" on your project to make the update permanent. Close your project. Delete the fake LibB and all the old LibA VIs. Restore the real LibB. Open your project. It should now pick up LibB instead of LibA. (It might complain that the LibB VIs were not in the expected folder. If it does, just "Save All" again and it will be happy after that) Make sure you back up everything before attempting this; rinse and repeat will all your projects. Caveat: If your project uses LibA in more than 1 Application Instance, LabVIEW will lock the library when you open your project, which blocks you from doing step #4.

Are those front panels part of your intended Embedded UI, or only for debugging? When I run VIs on the cRIO "from source", both (1) and (2) work correctly for me on the cRIO's screen but not on the PC's screen (including preallocated re-entrant VIs). Tested with LV 2017 SP1 + cRIO-903x image in a VM. It is always worth having the cRIO screen visible during embedded UI development because what you see on the PC is not what you get on the cRIO: https://knowledge.ni.com/KnowledgeArticleDetails?id=kA00Z0000019LZ9SAM