ShaunR

There is another method that I use. Read the entire file and return a single element (or maybe more) whenever access to an element is required. This relies on OS caching to maintain performance but yields real-time, on-the-fly changes to the ini file being reflected in the application.

The Linux Kernel does support them but of course they are not called that. The Kernel has to be compiled with the features and I don't know for that device. Check what is available (if at all) by issuing "cat /sys/power/state" in a command prompt. Check how it can be woken up by issuing "cat /proc/acpi/wakeup"

Are you using Shared Reentrant? Try using Preallocate.

Just be aware:

Are you referring to Docker? Does this ring any bells?

My tuppence ... choose one, LabVIEW or Python. You can create services which interact through TCPIP or REST API's but keep them separate. If you have 20 python devs and one or two LabVIEW developers then you are on a hiding to nothing. Python won the war a long time ago and it's time to learn Python. Not the answer you were probably looking for but you'll end up mostly doing IT and configuration trying to get your LabVIEW python stuff to work anywhere except your dev machine.

That's because it's hard-coded to return a simple Boolean when compiled. int PQisthreadsafe(void) { #ifdef ENABLE_THREAD_SAFETY return true; #else return false; #endif }

Another SVN user. Meh. The lesser of evils. Not forced. Use it through choice. Pro's: Straight forward workflow. Works from windows context menu's (Tortoise SVN). Use it as a versioned restorable backup with no major hassle. Cons: Same as any other SCC with LabVIEW - merging - but workflow can help (use Branches. Partition work packages to reduce merging. Trunk gate-keeper). Almost never but when it happens, it's always on the merge to trunk - Gatekeepers problem but can recover easily .

No idea. If you save files external to the DB then it mainly depends on the disk speed and the resolution/format you are saving it with. You've only given a rough resulting file size and a framerate. No indication of how many seconds worth that is in order to calculate the MB/frame/sec. Streaming to disk is orders of magnitude faster than to a DB though and the faster the disk, the faster you can stream. If you just want the convenience of a single file for offline post processing then you save them to a directory and zip it all up at the end along with the DB metadata. If you want to be fancy, then you can add them individually as they are created in the background while the next recording is acquired (assuming you have enough oomph in the processor)

Save the images as files and just index them in the database and any meta data you need. As a rule of thumb, you only save data that is searchable in databases. Images are not searchable data, only their names are. Doing it this way also enables you to process multiple images simultaneously, in parallel, and just update the meta data in the DB as you process them.

I think you've either wandered into the wrong forum or are advertising motherboards. Which is it?

Nice. IMO demodulation and using the sound VI's was harder than writing the interface VI's

OS and CPU are defined within a project. You've created a new VI outside of a project.

Do something you are actually interested in and will be able to use beyond the mere task of learning to program. If you have a hobby, then program something to solve an annoying aspect of the hobby, Perhaps it's that you have to keep printing out user manuals. Perhaps you have to keep calculating something over and over. Identify an issue and solve it programmatically in a way that will actually be useful to you. If you are a gamer, then maybe something to do with how the game operates. For example. Maybe damage output is dependent on a number of aspects such as weapons or various statistics. Write something that enables you to ascertain what combinations are best for your character or simulates gear changes for different scenarios. Maybe you are into Astrology or Numerology so you can write something that calculates the positions of constellations or the number significance of names. The point of programming is to solve problems. Find a problem that is close to what you know and love and the programming will come along with a solution you can use to make your life a little bit easier. Your current issue is that your problem scope is infinite. Narrow it down to something close to you. Maybe write a program to help ;)

I have a whole directory in my toolkit called "Windows Specific" which is for VI's that call the Win32API. But unarguably THE most useful for me is the Win Utils I originally wrote in LabVIEW 5 and still use today. Windows API Utils 8.6.zip

¯\_(ツ)_/¯

I don't have access LV2020 right now for sets but I maybe have a solution for the arrays which should be much faster and accommodate any number of dimensions,

Maybe make the DLL import wizard actually useful. Not sure why they are doing this though. .NET was supposed to be the next generation of Win32 API's. I guess they got fed up of migrating the functionality. I used to have a program for Windows WMI queries that did something similar. It wasn't one that I wrote but was a tool intended for Borland languages that meant you could query the WMI database live and create the queries in C++ and Delphi prototype snipits. This looks similar for Win32 API's.

Are you suggesting we should grab a sword for the next visit to the sales and marketing dept.? I can see some merit in the idea

Nah. That's just one of those vague marketing place-holders like "synergy" or "convergent" that is deliberately obtuse so that the customer interprets it in their own context.

It depends how it is compiled. There seems to be a function to determine whether the binary is thread safe, yielding 1 if it is and zero if it isn't. int PQisthreadsafe(); Source

I don't know how VI manager does it but here are the things I do know. A fresh install has no tcp settings in the LabVIEW.ini. If you change the VI Server settings then the following settings are added to the LabVIEW ini depending on what you change from the defaults - the prominent ones are: server.tcp.enabled= server.tcp.port= server.tcp.access= There are also property nodes that relate to those settings. Access via these nodes (externally) requires that the VI server is available (i.e enabled). You can turn it off, but not on. In 2020? a new variable was added to the ini which is server.tcp.acl= I don't know much about that one but it will probably bite me in the backside at some point since I know what an ACL is

I colour my VI's occasionally for 2 reasons. To tell the difference between 32 and 64 bit. Both for LabVIEW version and when using conditional disables for 32/64 and OS's-especially with CLFN's). To mark sections of VI's that have problems or need revisiting. To mark VI's that are incomplete that i must come back to.

Bearing in mind Antoine's comment with which I wholeheartedly agree with, I would suggest upgrading to 2020 now and plan for deliverables with SP1 or later as and when they arrive. You can have multiple versions installed side-by-side on a machine and you want time to find any upgrade issues with your current codebase and gradually migrate with fallback to your current version if things go wrong. Reasoning for 2020 is that that it supports HTTPS - which none of the previous versions do out-of-the-box and is essential nowadays. 2020 is, by now, a known entity in terms of issues and work-arounds whereas waiting for 2021 you will be at the cutting edge - where production systems never want to be unless it facilitates a show-stopping feature requirement.