ShaunR

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?

The API distinguishes between user errors and native LabVIEW errors. Since the implementation does not allow you to input user error numbers, the code number for user errors or warnings is moot and defaults to zero.This way it does not interfere with native LabVIEW errors and warnings. If you want to force an error with a specific error number then there is already a primitive to do so (Error Cluster From Error Code.vi) and the API will log it when you pass it in. But don't get hung up on specifics. It's a an example of using a SQLite database for error logging so it isn't meant to be the ultimate silver bullet to error logging (although I don't think it is far off-it's a case of it works for me in everything so far ). If you have some good ideas (like your suggestion of more levels/priorities) then maybe we can improve the example. But at the very least it is a good starting point. Lets see how it fails your use-case and what we can do about it, eh?

I think you misunderstand. An API doesn't decide the meaning of a priority as such. It's just another field that you can use to group errors. The developer still decides if it's fatal, recoverable or just nice to know but he can decide to limit the granularity of written data or filter and sort it (e.g.fatal only). Think of it as categories of errors. Most APIs have a few built-in "categories" for the developer to use.

Or as Linus Tovalds says: "Never break user space" and "if you change the ABI, I will crush you!" . (Shame they don't listen to him )

Umm. No. The numbers in the user source string is just so you can see which message belongs to which error otherwise you'd just have a load of starts and finishes and unable to check which write generated it. The "priority", or "level" as it is called is the Typedef (Error, Warning, User etc). I've used 4 because that was always enough for me, although I think I will change it from a U8 field to a U64 to give 61 User level/priorities in total rather than 5. That should be enough, right?

Have a look at the SQLite API for LabVIEW. It has an errors API and an example. I use it in messaging systems with a service that listens to error messages.

This is what LavaG is here for. No-one has even seen this new structure yet and we are already trying to figure out how we can abuse it

Sweet. OK. So the default behaviour is no error (accept everything), each case is then tested at design-time in order to make sure it compiles (using normal primitives and preserving coercion and polymorphism) and there is a little bit of manual fnuggery with two new primitives to force a type error so we can implement our own logic. An awesome, outside-of-the-box solution to controlling permissive types. If we have a "To variant (Type Only)" does that mean we can wire it directly to this new structure and use it like an ENUM wired to a case statement but for different types? (I'm thinking outside of macros and at run-time here )