ShaunR

You're thinking like a linux user

You don't really need to have an add_file program. When you double-click on the file you can pass the file path directly to the viewer as a command-line argument which can be read by LabViEW.

I think some "JSON" implementations have (perhaps wrongly) allowed these

values, so it is probably a good idea to accept things like "Inf", "Infinity", "NaN" when parsing in JSON.

The Json spec (Section 2.4) specifically forbids it for numbers.

Numeric values that cannot be represented as sequences of digits (such as Infinity and NaN) are not permitted.

However. It doesn't say anything about strings We can already cope with recovery of +inf, -inf and Nan (although we will have to add "Infinity") so it's really a decision for encoding (I would suggest string encoding and lose the type but a switch might be more appropriate as you suggest).

PHP will throw an error if the type is a numeric, but will be quite happy if it is a string and, as PHP is untyped once parsed it really makes no difference.:

json_encode(): double INF does not conform to the JSON spec, encoded as 0 in /var/www/html/search.php on line 167

Some Javascript engines allow it since it is valid Javascript but not valid Json however there is no concensus.

• cmj-JSON4Lua: raw tostring() output (invalid JSON).
  
• dkjson: 'null' (like in the original JSON-implementation).
  
• Fleece: NaN is 0.0000, freezes on +/-Inf.
  
• jf-JSON: NaN is 'null', Inf is 1e+9999 (the encode_pretty function still outputs raw tostring()).
  
• Lua-Yajl: NaN is -0, Inf is 1e+666.
  
• mp-CJSON: raises invalid JSON error by default, but runtime configurable ('null' or Nan/Inf).
  
• nm-luajsonlib: 'null' (like in the original JSON-implementation).
  
• sb-Json: raw tostring() output (invalid JSON).
  
• th-LuaJSON: JavaScript? constants: NaN is 'NaN', Inf is 'Infinity' (this is valid JavaScript?, but invalid JSON).
  

(NB. Twitter allows it,but I have no idea what library they use. Lots of people complaining that they get errors from parsers when recovering feeds and the general mood is that parsers should just cope with it).

See this confuses me a bit. I haven't been using LabVIEW for 15 years so I don't know how it worked back then, but how could they restrict that? Wasn't 15 years ago version 5.x or so? Didn't 5.x EXE's build in the RTE into the EXE so no installer was needed on Windows machines, you just run the EXE on any PC?

I started using LabVIEW around version 6 and early 7 and I don't ever remember having to buy any RTE licenses. So for as long as I can remember LabVIEW has always had a free way to run EXEs.

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

Hi there!

So I tried this Websocket on a cRio.

The only thing that needs to be changed is the EOF,

I used the \r\n constant instead of CR\LF.

But theres one more problem that I am currently facing,

I cant access the svg file via web publish in the cRio. The svg file looks fine if I access to it via ftp.

But if I put it in the www folder and access via http, it comes out as text instead of graphics.

I tried a lot of method including creating a html file that calls the svg.

So far, none of them worked.

Currently using LabVIEW 2011 and Chrome ver 22.

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.

For instance ShaunR added support for escape quotes in the product. Now I have to go to his code, detect the changes (which is hard since LabVIEW is binary and he backsaved to 2009), merge these into my Mercurial repo(Done).

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>.

Yeah, that makes sense. But I seem to remember a very long time ago getting a quote from NI for a pack of 50

RTE's. I guess only old timers like me can remember such antiquated practices.

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

On topic:

The testcase include the followin JSON:

{"T1":456.789 , "T2":"test2", "Nest":{"ZZ":123,"NestArray":[1,2,"Hi"] }}

Is that even valid JSON?

Is it allowed in JSON to have different objects types inside an array? (NestArray consist of two numerics and a string)

JSONLint says its valid, but I feel oppposed to that (maybe just limited by LabVIEW)

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).

What should we do with NaN, -Inf, and +Inf? JSON does not support them. NaN could be null but the others I don't know.

Official JSON sets those three values to 'null' however I lean to this idea. For numerics we should use 1e5000 though.

Ton

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)

I was attempting to engage the community on the JSON project, and have been for months, and I find it more than a bit frustrating that rather than help build something that can be extended to the whole LabVIEW community, you built your own and put it in your own flavor of walled garden. But that's the rule of licensing software. And it is yet another reason that licensing needs to be seriously rethought globally. I hope in the future for projects like this that you'll keep these arguments in mind and consider posting on NI.com, which makes the VIs just as available to the community and let's NI employees work on the project too in a way that maximizes everyone's return on investment.

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.

When we're talking about a library as fundamental as this one,

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.

That would just be giving NI a free gift. But for the core, this is just shooting yourself and the wider community in the foot. You already pay for LV. Might as well get more for your money.

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

For the handling of Variants, you might want to take a look at my library... I've done some work there to handle the full recursion of variants with variant attributes.

One thing I am sorry about -- and I should have mentioned this earlier -- is that you chose to put this in the LAVA CR instead of posting it to ni.com. The license agreement that governs LAVA CR is one that precludes me from making these VIs a part of LabVIEW in the future. I have asked and begged for LAVA and NI to work on this, but so far no dice, so I'm largely going to have to recreate your work in the parser I've been building. Mine is both more and less complete than yours at this point, and I was hoping to supplement the parts I haven't built yet by calling into your library. I cannot do that now. (Reposting on NI.com doesn't fix the problem, I don't think, because the CR is where they were originally posted).

I hate software licensing rules. Really hate them.

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.

Thought I'd poll the consensus here. Has anyone had issues using the Cursor Property on picture controls while in the run-time environment? Help says it's a scripting feature, but that it is available in the RTE, which seems weird to me. Does this actually work reliably in the RTE?

My searches aren't turning up much beyond the numerous discussions relating to the CAR where the last used cursor from the icon editor persists across all picture controls while in the IDE.

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

Yeah, that's how I roll. Tru dat, boy howdy. Word.

Middle Class Rapper

Actually it's not! You are right that the shared library will refuse to work if your clock is set after June 2010 or so, by simply posting a dialog at runtime. But the reason of the original refnum problem is that this library makes use of so called user refnums. These are defined by resource files that get installed by the package and in order for those refnums to be valid the according resource files have to get loaded by LabVIEW, which it only does at startup (at least I'm not aware of any VI server method to do that at runtime too, like the refresh Palette method the VIPM uses after installation of a new package).

I'l be having a look at the library soon and see if I can do anything to resurrect it, but feedback has been very limited, so I was simply assuming that nobody was using it.

Please note that the SSL support of that library is really minimal. It allows to get an https: connection up and running but lacks any and all support to mo0dify properties and access methods of the SSL context to change its behavior of for instance add private certificates to it.

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?

Any further improvements?

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.

I would guess that deal created over a half million in sales for NI. It was more a trial than anything but for that amount, I don't expect to have to beg for real support. We had an FAE at the time and he was given every opportunity to help us locate someone. If this would have been the case of a one off prototype, my expectations would have been different. All water under the bridge now, we learned our lesson the hard way.

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 mean utility VIs for the User of the API, rather, I mean “utility” for writing the package internally. Conversion to/from valid JSON string format will be required in multiple places. I tend to call subVIs, needed by the class methods, but not themselves using those classes in any way, “Utility” subVIs.

There’s a good 30+ VIs in dependancies. Copying all that to support my variant-to-JSON stuff is excessive. Compare it with just changing the one “remove whitespace” subVI to make the rest of the package independent. But as I said, it should be easy to make the variant stuff an optional add-on, for those who don’t mind adding a couple of OpenG packages.

I don't think there are that many. Guess I'll have to install them again and find out

Is it OK to put unfinished stuff in the CR, even uncertified? I’m afraid I’m about to go on two weeks vacation, but I could put what we have to this point in the CR and commit some free time finishing it when I get back. Don’t whip up a thousand and one pretty polymorphic instances until we get the core stuff finished.

I would. There are a lot less "working" things in there already Alternatively. Start a new thread.

At some point I switched from not using OpenG if possible, to considering it “standard LabVIEW”. VIPM making it so easy probably contributed to this shift.

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.

The package needs a pair of utility VIs that convert strings to/from the JSON valid form (in quotes, backslash control characters, possible unicode encoding).

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.

The variant-to-JSON stuff could be kept separate as an optional feature that requires OpenG (a lot of work to rewrite that without OpenG). Otherwise, I think I just used the faster version of “Trim Whitespace”, easily replaced.

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!

I have heaps of reuse installed so that I can draw on it naturally. If I need to, I just do a project analysis afterwards to audit what was used. If anyone's going to, I would expect you to use a totally different paradigm.

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

Though I think you didn’t need “To String”, as “Flatten” does the exact same thing. I never thought of using the JSON string form internally to make the outer polymorphic API easier. Great idea.

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.

Not sure how many are still reading.

Put it in the CR and see how many downloads .

Don’t like the OpenG stuff? I love the Variant DataTools.

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.

Breaks parser:

Backslash quotes \” in strings (eg. "And so I said, \"Hello.\””)

Sort of breaks:

U64 and Extended precision numbers, since you convert numbers to DBL internally. Note that in both my and Shaun’s prototypes, we keep the numbers in string form until the User specifies the format required.

Possible issue?:

NaN, Inf and -Inf: valid numeric values that aren’t in the JSON standard. Might be an idea to add them as possible JSON values. Or otherwise decide what to do with them when you write code to turn LabVIEW numerics into JSON (eg. NaN would be “Null”).

— James

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.

One is a hardware device where the people at NI actually sat down and wrote a specific driver for it by people who have some serious device driver development experience, the other is usually a minimalized copy of the reference design from the chip manufacturer with often a completely unaltered device driver from the same chip manufacturer.

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