ShaunR

Boss: There's no "i" in team. ShaunR: There's no "u" either but there is "me".

I've written quite a few a test sequencers. They all worked roughly the same way which was a little bit like CSS in being able to include other files. Basically scripting. I have always been lucky though. I got to specify the hardware and using SCPI means you can just script the commands directly from the files with a simple TCPIP or Serial squirter and not bother with drivers. But simple wrappers around drivers can also be used for difficult stuff. I just extended the SCPI syntax to include the hardware route. So you end up with "recipe's" and add some custom stuff for delays/waits, a dialogue invoker and reporting and you were pretty much there. The UI was basically file listings and being able to order, add and delete them. The only other things were start, pause and stop. On one occasion I expanded the concept into a fully featured scripting language. After the first 3 times I could create a Test Sequencer in a day from scratch when moving to a new company. A couple of hours if i could reuse some stuff. Probably couldn't do that now though. I've forgotten too much and have had to make room for other stuff I did something very similar when using Test Stand too. I'd write a TCPIP connector and a LabVIEW VI would run in the background routing commands. All TS sequences just became sending strings to the connector and returning string results. Much simpler. Basically reducing TS to a Script Manager and reporting tool without all the usual complexity. You only have to train production people how add, remove and disable sequences and, if you have a techie production person, the format of the string commands.

Python has taken over the areas where LabVIEW traditionally dominated in test and measurement There are a couple of reasons for this not least that it's multi-platform and opens up more cost effective hardware options such as Raspberry PI's.

This also goes for any other non-LabVIEW UI used to control LabVIEW. I came across this issue with the Websocket API (as you probably know, I ditched LV UI's a long time ago in favour of HTML). Unlike other Websocket applications that send the HTML to be rendered, the implementation I chose was message based. So the VI would serve an image of the FP and the javascript would send back the click co-ordinates WRT the image. The Websocket API would then translate that into the LabVIEW FP co-ordinates and operate the control found there. It was a bit more involved than that but that was the basic principle. This also meant that you could script operations in JS for testing (or anything else for that matter-as long as it could do websockets, like Python) but that wasn't the original intent. One customer did write some Javascript (or maybe it was another language) that enabled them to record a series of operations and replay it back like the macro recording in Excel. I wasn't involved in that but thought it was neat.

This may help. There is also but I can't remember which dialogues it suppresses.

What a horrendous format TOML is. I won't be using this format unless forced to at knife-point.

Here's my tuppence. Get an indication from your IT dept when thy expect the issue to be resolved then get your project manager to bill the time against IT's budget. Add to your project plan the time they indicated and add a note that the project delivery date will be be delayed by at least that amount of time. Keep doing that if/when their indicated time expires until they resolve the issue. If you have weekly project meetings, make sure it is in the minutes and get an action on IT to resolve the issue and require status updates from IT so it never drops off the agenda. Ensure the IT issue is elevated to a high project risk category. Then. Download the VISA executable installer from "http://download.ni.com/evaluation/labview/ekit/other/downloader/" and tell your project manager you *may* have a temporary, sub-optimal solution which you are investigating for this particular package but that you fully expect continuing issues that may not have similar solutions even if you are successful this time, which is not guaranteed..

no cat for Cat? They are just text files (sort of). If you don't have a file called "state" in "/sys/power/" then i guess you don't have those features

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,