ShaunR

Ah yes. Forget everything I said because I obviously opened the wrong VI to be able to see the diagram. Thanks for pulling me up on it.

You don't need the queue-it is just adding complication for no benefit. You are taking the event (which is automatically named by the control label) then grabbing the control name and sending it via a queue to a case structure that has the same names as the events. Your code will be lot simpler and easier to read if you just use the event structure with a frame for each control.

Like I said, the only thing preventing me is the *hardware* to test on. Software is not really a barrier for me or the platform "type" because I'm not particularly clever, but I am persistent I pretty much have a one click (well, 3 click) process for producing the binaries for all the platforms (except VxWorks) now so the overhead of creating them has been solved. No-one is asking for these platforms so it is really my own satisfaction in striving for completeness. Virtual machines would be better if, and only if, there isn't a cost associated and they accurately reflect the hardware target. Because the API is free, there isn't a lot of incentive go out and spend real money on expensive NI hardware on the offchance that someone *might* use it. The only realistic way new platforms will be added (if no VMs are available) is through sponsorship or someone donates a device. I did go out and buy a VxWorks (6.3) RIO - quite a while ago now - because that only left the PXI racks (Pharlap ETS) at the time but obviously more platforms have been released since then. My own self satisfaction isn't enough for me to spend more of my own money on hardware just for testing once or twice a year when the burden of maintaining the binaries is not trivial and no-one really wants them. Just to be clear, though. This is a mainly a support issue. The API probably does work on those platforms with the standard SQLite binaries but even then I cannot support those platforms without test targets.

There sort if is. Generally you would set up a watchdog so that if your software hangs or crashes, things get reset back to a known state.

Thanks for this post. Unexpectedly. It sent me down a rabbit hole where I'm now furious about MQTTs lack of authentication and have another little project started.

Python is cross platform so of course it will run on windows and Mac. But the reason why all your "kids" are Python fanatics is because they are Linux fanatics. If they were Windows fanatics they would be C# fanatics instead. The interesting debate would be how your company protects its intellectual property in the face of a predominately Linux open-source mindset (not to mention some of the awkward licences for businesses that python relies on). I look forward to pulling your code from Github

Ask your "kids" what's their favourite OS. I can guarantee it is Linux. Python is the go-too tool for RPC GUIs to Linux programs and services. You've just got a lot of Linux "kids" where you work

Isn't the issue that the OP is referring to, that when large data amounts are sent to the graph (regardless of how they were acquired or organised) that the indicator is slow at rendering them? Yes. Ring buffers are great for recording data at high rates but you are still left with the rendering problem, are you not? I think the OPs issue becomes a little clearer if you make your 500 plots 8192 data points in length instead of 128

Hey. What about us old baldies? There is little correlation between LabVIEW and Python (unlike PHP) The boom in "software as a service" is the main driver behind this uptake. Outside of this domain, Python is a poor choice and is nothing without its C/C++ bindings.

If you right-click on the icon for setting the volume and select "Select Type>>Array"; you can enter more than one value.

You speak for me too. Generally there are only two things that prevent me supporting all LabVIEW platforms for my products: Hardware to test on NI Third Party Licensing Toolkit. For the SQLite API for LabVIEW the second one is moot so it is only a test platform that prevents me supporting Linux RT, PXI and x86 cRIO.

A new feature called the "Session Extension" has just been rolled into the trunk of latest release of SQLite (3.13.0). From the authors: In a nutshell you can "diff" a database and produce a patchfile of the changes (and the reverse). Now. Most are probably thinking source code control at this point which isn't very interesting in terms of LabVIEW. However. There is another use case - synchronizing remote acquisition databases. Previously we could have a SQLite database to store acquired data in, say, a cRIO or PXI chassis. Periodically we would want to back up or synchronize another database either for back up, offline exploitation or the file was becoming too large to store.. This meant making a backup copy locally and then sending the entire database file to the recipient. That could take a long time, was fraught with problems of disconnection and there may have not been enough space to create a copy. With this new feature we should be able to overcome or at least alleviate these issues and effectively implement "restore points" and "staged updates" for remote databases as well as bandwidth reduction while synchronising and configuring. For example. We may store configuration information, amongst other things, in the database and only want to update that section. We may only want the last 24 hours of data sent back for exploitation. We may only want error or waveform meta information....and so on. I'm looking forward to playing with this feature over the next few weeks. so if you have suggestions for another use-case, then I would like to hear it.

The usual issue is finding out the processor you chose based on cost, isn't enough to run ethercat and your application at the same time (half way through your project ). If you are not using the FPGA then I highly recommend spending the extra effort and using that instead.

The speed maybe more to do with the for loop to create the array than the plot itself. You could use the picture plot functions to draw each trace without erasing the previous ones. Then you wouldn't have to manipulate the 2D array. That would probably get you the plot image you want but you will need to think hard about measurements since you won't be able to just read the plot data back later.

Can you clarify? There are a couple that work with the standard error cluster so what is meant by "really work"?.

Three points jump out at me from an implementation point of view.. The user is expected to propagate the error list. This is fraught with foot shooting possibilities (forgetting to wire a case through, for example, will clear all the errors). Try and encapsulate the errors into your API so that storage is handled and managed by the API itself. Creating and passing arrays around as you have will become a performance and memory concern as the array grows and is not deterministic. This will make it a no-go for real-time systems. Instead of just a string for your labels. Consider using a typdef'd string combo box. Then you can give the user a drop down list to choose from to avoid spelling mistakes but still allow them to enter their own custom labels.

How long does it take you to create a scheme for all controls/indicators? Have you automated any of it?

I will echo this. 99% of the time you will find that charts are deficient in one way or another. They always start out great as a quick way to visualise data but as soon as the data is not contiguous across multiple plots or you need a data/time axis you always end up switching to the XY graph.I go straight for XY graphs every time.

Browsers.

Soooo. Shouldn't we remove the site search then if that's not the recommended way of searching or (shock horror) fix it so it works?

+1 with Hooovahh. Checkboxes and LEDs. FWIW. I no longer use LabVIEW front panels at at all for commercial user interfaces..

Sour. The one use-case where VIMs finally solved a [decade old] problem and was getting me so excited that I wrote a whole demo on it - VIM HAL Demo). Is only going to solve half the problem, I'm getting the JSON blues feeling

That's nice (you tease ). But the big question is "do my 'named events' work properly now?"

Do #1 should be a don't. The site search is useless and we all use Google Do: 8. Use emoticons liberally. Subtle meanings or intentions may be lost or misconstrued when writing text so use them to reinforce your intended meaning.

Elaborate?