ShaunR

They didn't restrict it. It was a condition in the licencing.

This thread discusses a couple of techniques

He also has a website dedicated to this at http://blog.evexiallc.com/?p=37#comment-54. Might be worth asking the question there also.

I gave up with automatic merging a long time ago with any system. The fact that LabVIEW (especially 2009) re-compiles at the drop-of-a-hat makes most conventional source control systems impotent (and don't get me started on the LV Merge tool). I now only use them for micro-versioning. I rely on comments to identify and track changes and, although it requires an anal approach to commenting, works pretty well-at least for my workflow. You probably saw (simpler versions of) my comments in the code (added, modified etc). Just search for <SR>.

Yup. It used to be 50 about 15 years ago (we moaned like buggery!). There is no restriction now, however.

Yes. In fact, it can be and array of anything including other objects and/or arrays so even this is valid: "myarray":[[123,223,{value1:MyVal1}], value2:"wally"] This is why, for LabVIEW, it is much better for us to rely on the programmer to decide how to get the info out since with the polymorphic VIs we limit his options to valid LabVIEW types with a fall-back of the raw string. On a similar note: You don't have to have quotes around a string value value either (it's only required for labels). I have no position on this. I took the decision in the SQLite API to encode NaN as a string rather than NULL but that was so that extra detection wasn't needed when converting back to LabVIEW types (Search and Replace NULL for NAN). It was an issue of performance that we may not be so fastidious about here. Other languages may not have a representation for NaN, but LabVIEW doesn't have a concept of NULL either except perhaps "empty string" which converts to zero for numeric types. Off:Topic: Way to go to get the last word in (comment then get the mods to remove it all...lol)

Took Toms version (love the "prettyfying" btw ) and added support for escaped quotes in strings (\"). Escaped quotes are maintained in the variant table and only converted when read out via the polymorphic VIs. (back-saved in 2009)

BSD is hardly a walled garden. I was looking forward to your Json implementation (in fact I looked several times before this and tried several things to make it work for my use case-without success). However, it was/is doomed if it can't do normal LabVIEW stuff. I'm sure for object serialisation it is the bees knees, but it's not whats needed for us proles. This, however, is exactly what we need, it didn't take us months and, although my initial thoughts were not in favour of a class solution for the obvious reasons, Drjdpowell has demonstrated a splendid solution for the parser (although I'm not sure what he will do about the cluster order ). Between Drjdpowell, myself and Ton, It is a great example of the labview community pooling their efforts through discussion and providing an open source solution. It should be celebrated, not bogged down in a licencing diatribe. I can understand your frustration due to the time and energy put into your API. But don't go throwing your toys out of the pram because it can save you effort or you wish to participate but the hindrance is your own companies policies. The licensing isn't an issue except if NI want to take ownership and I expect this is a similar stance to what you alluded to in terms of previous discussions between Lavag and NI. There are lots of projects on Lavag that never get the participation or feedback that the author expects ("If you build it they might come"). That's no a sleight on their software, or indeed, their skills. It just means it's not that big a deal for others or it doesn't fulfill their requirements. Don't feel put-out that people didn't pick software "A" over software "B". It just means "A" didn't fit their requirements as well as the other.

Hardly "fundamental" to LabVIEW (mountainous mole-hills?). It's an addon library. Nothing more. 1/2 of it uses OpenG variant stuff so (much to my chagrin) that would be a far better place for it. So NI should pay for it then if it's that great and would enhance their business The only thing stopping NI from using it is NI

You mean that NI cannot take full and unconditional ownership and commercially exploit them if they so choose. It's under a BSD licence which is where it belongs and I can easily see it being included in the OpenG stuff.

As far as I was aware. VI scripting isn't available in the run-time engine. It is (was?) development only.

Middle Class Rapper

I think its extremely useful and well worth maintaining. I noticed that in the readme you have a list of things TODO that I might be able to help with (would need the source and a bit of guidance though). The later versions of LabVIEW have SSL DLLs that might make things easier (from multi-platform point of view) although they seem very inflexible. What is the licencing?

Just has a cursory glance. But it looks like you are calculating the coefficients and passing the XY parms for the linear fit twice with the same data (it's only the weightings that change from the first "fit" to the second) . You could pre-calculate them in a separate loop and just pass them into the other loops. Also, you might benefit from passing through the x array (through the coefficient vi).

A lot of stuff you need for the network "architecture" is probably contained in the Dispatcher in the CR. It can do the "clustering" by simply placing the dispatcher in the right place and pointing the publishers and subscribers to it (can be on the same machine or centralised and you can have multiple dispatchers spread out accross many machines). What you send and what you do with it is then up to your implementation. I wouldn't suggest UDP for this, however, unless you are going to write a robust protocol on top-which is a lot of work and mitigates a lot of the advantages.

In my case it was one FPGA card (~$4K). However. That reminds me of the other trick. Ask for a loaner to test before you buy if you have never used the product before (they've always got a couple for demos and conferences kicking around). It concentrates a sales reps mind They tend to be focused on "potential" sales rather than "previous" sales, but they can pull the strings.

I don't think there are that many. Guess I'll have to install them again and find out I would. There are a lot less "working" things in there already Alternatively. Start a new thread. Indeed. I have to be very careful about dependencies. Some clients insist on "approved vendors" or "no 3rd Party/open source" and, for most of the stuff in OpenG that I would use; I have my own versions that I've built up over the years. It's just easier not to use it than get bogged down in lengthy approval processes.

Do they need to be utility VIs? We can detect control chars (they would break the lookup, I think, so need to be removed) and to escape the Flatten could just have a boolean. Not really sure what you have in mind though. If I remember correctly, as long as you keep the copywrite on the VI and. perhaps, the documentation, you can use, modify and do pretty much what you like with them (someone in the OpenG team could advise). It may be possible to rename (so they don't clash) just the variant stuff (there's only a couple) and include them in the package so it is then completely self contained with no dependancies Might I suggest you place it in the unconfirmed CR so that we can make a list of things that need to be done and to manage it?. We've been rather obnoxious in hijacking JZollers thread-my apologies JZoller! Yeah. There is a re-use library consisting of about 10 VIs for mundane stuff. That's about all I need from project to project . Everything else is self contained APIs

Nearly. Flatten adds things like quotes and brackets. For conversion, these need to be removed. Whilst I dare say you could make it work that way, I wanted to leave most of your stuff as-is and "add" rather than change if at all possible. Put it in the CR and see how many downloads . It's not a case of liking. There's some great stuff in there. It's a case that not everyone can use OpenG stuff. It's also not really appropriate to expect someone to install a shedload of 3rd party stuff that isn't required just to use a small API (I had to install OpenG especially just to look at your code and uninstall it afterwards)

Spam?

Well. Here's my experience......... I was working on an FPGA and we wanted to transfer huge amounts of data from a 3rd party FPGA aquisition board, accross the PXI backplane, to an NI board for crunching. We couldn't use the NI streaming VIs since the technology is proprietary and NI wouldn't liaise with the 3rd party so they could implement it in their FPGA (which is fair enough). However. NI said that they could DMA at about 700MB/Sec in each direction (1.5 GB/sec) across the back-plane which was "good enough for our team". The only problem was that all examples never addressed this sort of throughput apart from mentioning that, under the right conditions, it was possible. So long story short. The local NI rep hooked me up with the UK FPGA guru. I sent through an example of what we wanted to do (with which I was getting about 70MB/Sec) and he sent through a modified version with comments about where and what was important in my example for getting the throughput. It could do it at 735MB/Sec (each direction). He also sent me through an internal (not for distribution) benchmark document of all the NI PXI controllers. what their capabilities where, what measured throughput's could be obtained, with what back-planes and which board positions within the rack (which is important). Saying all that, It did take me two weeks to get through to him. I had to go through the "correct channels" first before the NI rep had a good excuse to "escalate" the issue through the system. The key is really building up a contacts list of direct dial numbers to the right people. If you know what you are talking about, they will be happy to take your call as they know it's not a silly problem. NIs problem is that there are too many inexperience people calling support for trivial things and, unfortunately for us, their system has been setup so that the engineers are well buffered from this.

Sweet. Only the boring parts to go then I made a slight change to your lookup by adding a "To String" in each of the classes to be overridden. This means that the polymorphic VIs become very simple (Not mention that I could just replace my lookup with yours, change terminals and, hey presto, all the polys I've already created, with icons, slot straight in ). I've added U8,U16, U32, U64, I8, I16, I32, I64, String, String Array, Double Array and Boolean. (I've back-saved it to 2009 so others can play although the Hi Res timer isn't available so the benchmark test wont work) Next on my list is to get rid of the OpenG stuff.

Don't forget the support! Support for NI devices is second-to-none. It is this you are truly paying for.

Not quite. The code knows nothing. It doesn't know what a glossary IS only that It is a field name it should look up for the programmer- it just gets what the programmer asks for. If the JSON structure changes, no changes to the API are needed. It doesn't care what the structure of the JSON object is, it's just an accessor to the fields within the JSON object - any JSON object. There is nothing stopping you doing this, but this isn't the responsibility of a parser. There is nothing to stop you creating an "object" output polymorphic case for your “experiment setup” (or indeed a whole bunch of them), you just need to tell it what fields it consists of and add the terminal. However. That polymorphic case will be fixed and specific to your application, and not reusable on other projects (as it is with direct conversion to variant clusters). What is more likely, however, is that your class accessors (Get) will just call one of the polymorphic VIs with the appropriate tag when you need to get the value out. I think you just need a better lookup and you'll be there! (with bells on) No need to go complicating it further by making the programmer write reams of application specific code just to get a value out for the sake of "objectness"

This is the "problem" as I was outlining it earlier. You have now hard-coded the retrieval of the value based on the structure of the entire stream. The former is is preferable from a genericism point of view. The latter, I think, is inflexible (I use my infamous "->" by the way). Yup. Getting it in is OK. Like I said. Getting it out again in a generic way so that you don't "hard-code" it in is the tricky bit. I'll also have to take a look at Tons thingy since he is flattening to display. I can then use JZollers parser .