ShaunR

Something else.

It's an excellent point. For example. Trying to log 200 double precision (8 byte) datapoints at 200Hz on a sbRIO to a class 4 flash memory card is probably asking a bit much. The same on a modern PC with an SSD should be a breeze if money is no object. However. We are all constrained by budgets so a 4TB mechanical drive is a better fiscal choice for long term logging just because of the sheer size. The toolkit comes with a benchmark, so you can test it on the hardware. On my laptop SSD it could just about manage to log 500, 8 byte (DBL) datapoints in 5ms (a channel per column, 1 record per write). If that is sustainable on a non-real time platform is debatable and would probably require buffering. 200 datapoints worked out to about 2ms and 100 was under 1ms so it could be a near linear relationship between number of columns (or channels, if you like) and write times. The numbers could be improved by writing more than one record at a time but a single record is the easiest. I have performance graphs of numbers of records verses insert and retrieve times. I think I'll do the same for numbers of columns as I think the max is a couple of thousand.

So can we not prepend an index to the name in the variant attribute list to enforce a sort order and strip it off when we retrieve? (I really should download it and take a proper look, but having to find and install all the OpenG stuff first is putting me off...lol)

<Dumb question> The request is for values not to be sorted alphabetically.. Is the solution just not to sort? Do we, indeed, sort them? Is it part of the prettyfier rather than the encoding. Where exactly is this sorting taking place?

A relational database (RDB) is far more useful than a flat-file database, generally, as you can do arbitrary queries. Here, we are using the query capability to decimate without having to retrieve all the data and try and decimate in memory (which may not be possible). We can ask the DB to just give us every nth data-point between a start and a finish. To do this with TDMS requires a lot of jumping through hoops to find and load portions of the TDMS file if the total data cannot be loaded completely into memory. That aspect is a part of the RDB already coded for us. It is, of course, achievable in TDMS but far more complicated, more coding and requires fine-grained memory management. With the RDB it is a one-line query and it's job done. Additionally, there is an example written that demonstrates exactly what to do, so what's not to like? If the OP finds that he cannot achieve his 200Hz aquisition via the RDB, then he will have no other choice but to use TDMS. It is, however, not the preferred option in this case (or in most cases IMHO).

Yes. I see. SQLite is actually the reason here. They removed localisation from the API some time ago so that it will only accept decimal points So the solution, as you say, is to use "%.;" in the query string to enforce it. And yes, you may run into another issue in that the SELECT for double precision uses the Labview primitive "Fract/Exp String To Number Function". This will cause integer truncation on reads of floating point numbers from the DB on localised machines. I've created a ticket to modify it, You can get updates as to the progress from there. In the meantime your suggestion to use the string version of SELECT and use the ""Fract/Exp String To Number Function" yourself with the "use system decimal point" is correct. You can also set to false or to modify the SQLite_Select Dbl.vi yourself like this. Those are the only two issues and thanks for finding them. Both the changes will be added for the next release of the API which, now I finally have an issue to work on as an excuse, will be in the next couple of days

That's awesome. I'm still trying to figure out how you moved the pieces' images from boolean to boolean without looking at the code and that's before I get to the AI

Congrats. Here's your promotion

Can't your PC box do it? You are plugging it in via USB, so making it available over TCPIP should be straight forward since it has Gigabit LAN and WiFi. Another alternative is Raspberry PI, but now we don't need your box or LabVIEW!

A poor excuse. That is the kind of thing I would expect from a 10 yr old "script kiddie" over at the NI forums You are not, I suspect. (if you are, then we have lots of time to train you better )

I think you are after an analogue frame grabber rather than a trans-coder.. Something more akin to the boxed version of the VRmagic AVC-2 (I've never used it, but give it as an example)

Ssssshhh, Don't tell Rolf. But there is a superb library that no-one is supposed to use.

Can you post the error? Row and column count return integers and should not have anything to do with decimal points. Yes. You can have parallel reads (but only a single write without getting busy errors) The syntax is standard SQLite SQL which is 99% compatible with M$ and MySQL. If you work with DBs, you have to learn SQL.

There is the "Data Logging" example which demonstrates this exactly in the SQLite API for LabVIEW. The issue would be whether you could log continuously at >200Hz - maybe with the right hardware and a bit of buffering.

I sit firmly on the other side of the fence with things like this. When it's a choice between form over function; function wins - especially if the spec can be interpreted ambiguously via tortured semantics. Adhering to specs by observing a strict negative of a positive statement (it doesn't say they cannot be ordered, rather, I expect it was stated thus so it didn't restrict) is why the native 2013 JSON is inferior (IMHO) to this library - speed aside. This library works when the native one throws errors because the native one adheres even more strictly, word for word, to the spec. inf and NAN are examples of where some libraries have implemented function over form. In that case, it was in spite of the spec which specifically disallowed it. There is precedence here if there is enough benefit. Would it really hurt that much to make the output look exactly like the input which is what we all kind of expect and know to be right? Relying on a specs throw away description about an unordered list seems a bit of a cop out to me and it would probably make testing much easier and simpler as you could do a straight input/output compare. It wouldn't break existing code, either. So I'm not sure what the resistance is apart from the effort required which has already been done.

Oh, I don't know. I think we appreciate it here but condemn most of these things because NI will do something about it now they know for sure it's been compromised

Hmmm. I just sat down and attempted to give Rex websocket capabilities since it is already event driven, follows the Open. Write/Read and Close structure and *should* have slotted straight in with a simple wrapper (I'm updating the Websocket API to use HTTPS and thought this would be a great use case). The only issue I found was that there is no background "service", so to speak, that could monitor the TCPIP to generate the events since VI Server methods evoke directly remotely (via the ACBR). Did you add a background VI service, or did you go through the web service interface to get to the users webservice VIs?

Once the buffer has every point written to, continue writing at buffer[usersize+1] wrapping back around to buffer[0] after buffer[usersize+usersize] is written Nearly.. After i=usersize, you wrap around to buffer[0] all the while writing to buffer and buffer[i+usersize]. Then, if you read at index i for a length usersize, you will get what you need.

It doesn't prevent wrap-around from happening. It means that you can read a contiguous array of data at any point in the buffer without having to chop and concatenate.

Not so trivial in native labview since to read contiguous bytes using the array subset, you need to split and wrap the array by making copies and sewing them together again. You'll be lucky of it doesn't get a lot slower than a rotate. There is one that uses direct calls to the LV memory manager though, but a rotate is much easier.

No and you can't (nor should you want to) LabVIEW Threading Model. For a detailed technical description see section 9.7 of this document

I would suggest you look into SQLite.There are a couple of LabVIEW libraries for it and you will be able to query the remote database and update your local (on-disk) one and pretty much run the same queries on it as you would do remotely. Really, though. It is an infrastructure problem, not a programming one. Your IT department should be offering you solutions rather than passing the buck.

I think event refnums are fairly well documented and there was a good presentation by Jack that demonstrated the issues. What is not clear and unintuitive is what happens if you place two event structures and connect them to the same FP control. This is THE rookie mistake, after all, I just wanna add another function to operate in parallel when I press that button, right?

Now you know how to make all your string controls/indicators URL aware without faffing around with xControls or cluttering up yer main diagram

I'm rather fond of applying behaviours en masse via callbacks. Ctrl CB.zip