drjdpowell

Mine are built in to Messenger Library, the framework I use. A video on them. But separate UI and PLC loops might be a better option for you.

You need some kind of parallel structure so your dialog can go on in parallel to your hardware handling. I actually use a special version of dialogs that are asynchronous and send their results back as a message, but the more common way is to have a separate loop of some sort.

You can colour it whatever you want. I just copy-pasted the green one a couple of times and changed the colour**. I just wanted to make sure people knew that, as most custom control sets available on the Tools Network are based on PNGs, which cannot be recoloured (and don’t resize well either). I’m trying for resizability and recolourability. I include the “Google style” checkbox, because it is nice and fits well with other Google Icons, but it is not resizable or recolourable, unless you manually swap out the icons with new ones from materialdesignicons.com. **Note: it’s slightly tricky to change the colour, as the checkmark’s invisible containing box blocks the colour tool from affecting the box underneath, unless you click near the edges. Unfortunately, the checkmark isn’t recolourable (it’s a vector graphic imported from LibreOffice).

There are multiple ways to do things; but pick one. Be wary of mixing different methods in such a way that the result is overly complex. So when you mention mixing CVT with an independent messaging system, that’s a worry. Note that smithd’s Projects don’t mix the two. Personally, I follow the messaging paradigm, rather than CVT-like tags (my tag-like functionality is a Register-Subscribe notification system build on messages), and I have a standard library and template for QMH “actors” (note: NOT Actor Framework) that can communicate locally or over TCP/IP (some videos).

Thanks. There is actually a couple more checkboxes that I've considered adding, but I have an excessive number of check boxes already. Possible Checkboxes.vi

I suspect the terminology is a holdover from the programmers of LabVIEW, who were loading into and unloading from the execution system, rather than memory.

Bad terminology then; it should be “Reserve and retain on first call” or similar.

For comparison, I have a 2GB test SQLite database with 660k spectra, each of about 140 wavenumber (WN) readings, a total of 91M rows of Time, WN, Value. These are stored in a "Without ROWID" table with primary key (Time,WN) I select regions of interest (ROI) in WN and Time, and I average spectra over time intervals (every 100 seconds, say), then take some statistic like a maximum of an average over each interval. With WN ROI of about 30 points, and a time range of a few percent of the data, update time is about one second. Doing the full time range takes 30 seconds. I don't understand why MySQL and Postgres are not able to get comparable results. But I would suggest trying (Time,id) as your primary key. Notes: -- the 2GB file is small enough to fit in the Windows File Cache, and so there is no disk access involved. -- SQLite is only using a single CPU for this, so it doesn't matter how many processors my computer has

Remind me. What Primary Key do you use? Is it (id,time) or (time,id)? Oh, and what hardware are you running on?

Thanks. Here's a more developed subVI that I've used successfully inside a Pre-build action. I use it to set a Build CC symbol to be equal to the Build Name, so different builds can enable different code. Set CC Symbol.vi

This example gathers references to all non-indicator controls on a Tab. Controls whose names end in "_IGNORE" are ignored. All Controls on a Tab Control.vi LabVIEW 2015

There’s a middle ground between those two extremes, where one operates on arrays of control references. You either create the array of references explicitly (lot less work that coding it), or you get it programmatically from either the pane reference or tab-control tab references. You can even do things like use prefixes in the control’s name to exclude some controls.

looks like they don’t have the feature you want. Re your original problem, I wonder if the issue is some very large data that you may be saving in the config file. How large are they?

You might see if the MGI Library has similar functionality.

I'll be interested in learning your results, as I'm considering Postgres for a data-recording application.

Note: 0x40 isn’t to open a ref to a re-entrant VI; it’s to open a common reference to a pool of shared clones. If you just want a single clone then don’t use 0x40.

If you’re using “Open when Called” then the FP will be loaded before anything else happens, so that can’t be the source of your problem. Be wary of using an invoke node on the VI block diagram, as the FP doesn’t exist until after that node executes.

Note, BTW, that I haven’t worked on INSERT speed yet (as my application doesn’t require it) and the example only inserts one row at a time. Better speed comes from multi-row INSERTs, and even faster is likely the COPY command, which I intend to support with the toolkit at some point. Also, from my reading, I wouldn’t expect MySQL to be slower than Postgres (except possibly for complex queries), so I think there must be something wrong with your MySQL benchmark.

Also, make sure your FP is loaded before your indicator is written. Your input Controls will show default values if the subVI was run before its FP was loaded, even though the proper values were passed.

How are you opening the Front Panels of your clones? If you’re trying to use those references opened with 0x40, you will be opening a different clone that the one you started (someone on NI.com had this problem once).

Here you go. Afraid I've not been able to work on it recently, as other priorities keep intruding. jdp_science_postgresql-0.1.1.8.vip

Reread my suggestion about the cluster. Don’t do what you just suggested.

Try an Object in a Cluster for your DVR, rather than an Object directly. There are special issues around Objects in DVRs that are possibly causing your problems.

Yes. With snapshot off, the image redraws from the buffer whenever it refreshes. Writing to a terminal triggers a refresh**, but you can also do it by the "Refresh Image" Method. ** Note: LabVIEW controls are running in the UI thread and are asynchronous to their terminal, so writing an Image ref to a terminal only schedules an update for possibly several milliseconds in the future, by which time the image may have been overwritten. I think this may also be a big source of confusion, as with by-value data the delay is never a problem, but with by reference data it is.

Well, to dequeue from a Queue, you have to provide the Queue reference every time. You can't call dequeue once and have it automatically keep happening. The confusing thing is that it is we write the Image Ref to a Control Terminal, rather than a VI. That's what fools us into thinking of passing images by-value.