ShaunR

Very pleased to see the New JSON Encode and Decode in the palettes of LabVIEW 2013. I've looked at using them instead of the various libraries out there and I'm in two minds whether I will convert my current apps or use them in the future instead of those 3rd party libraries now I have had a chance to play.. Let's start off by saying they work great They are orders of magnitude faster than 3rd party ones and they adhere vehemently to the JSON standard. It's the last bit I'm in two minds about. JSON is subset of Javascript (EMACS). Javascript is dynamically typed, which means that any variable can hold any type and although a string may have quotes around it, it does not preclude inserting it into, or operating on as a numeric type. Whilst the JSON spec does specify that string types be encased in quotes, Javascript (and PHP, for that matter) programmers don't really care and it doesn't break their code if they are present or not. Therefore it is very common to see quotes around numerics and even quotes left off of strings and most parsers will cope with this. LabVIEW is strictly typed and when the JSON Decode encounters quotes, it will error if you have defined the field as, say, a double. and then will not process any further fields. This is a right, royal pain! It also misses a trick that would make our lives so much easier and our code much simpler. Take, for example, the following real JSON stream from MTGox. { "channel":"dbf1dee9-4f2e-4a08-8cb7-748919a71b21", "channel_name":"trade.BTC", "op":"private", "origin":"broadcast", "private":"trade", "trade":{ "type":"trade", "date":1376196221, "amount":0.3333, "price":102.95507, "tid":"1376196221462784" ,"amount_int":"33330000", "price_int":"10295507", "item":"BTC", "price_currency":"USD", "trade_type":"ask", "primary":"Y", "properties":"limit" }} The "price_int"," amount_int" are encased in quotes when quite clearly they are integers and, more importantly, we need to manipulate them as integers. This forces the use of cluster elements that are strings and then to convert those fields to the appropriate type. It is compounded further since the structure is nested which means we have to unbundle all of the elements and then re-bundle to our desired types as we cannot use a single cluster definition. Additionally, the "date" is a numeric of the correct type, but that is not very useful in this scenario since it will need to be converted to a string. So defining that field in the decoding cluster as a string would have been a bonus. . This is the conversion using the native JSON decode.vi. This is using the JSON API available in the CR. The JSON API in the CR is much more forgiving in that the cluster, alone, decides on the type. So type conversion can be done transparently by defining the cluster regardless if a value is quoted or not. This yields a much simple, easier to maintain VI and, should the server generating the JSON decide to strictly adhere to removing quotes from integers; it will not break our code as it would with the native VIs. The native JSON decode has a "strict validation" boolean that states It would be useful if this boolean also disabled type checking of quoted strings. It would also be useful if it didn't stop at the first field it couldn't interpret and tried harder to continue. I could live without the latter, but not sure I can without the former - hence my ambivalence. Did I mention how fast the native VIs are?

New - Event Inspector Window (you're gonna love this!) - Never had a need for this, but it may come in handy if you don't know what events you are firing . New - High Priority events - Don't have a use case at the moment. But I can see edge cases where it may be useful. New - Flush Event Queue Function - I've always considered flooding event queues as bad and lazy programming, so I think this will just let bad and lazy programmers off the hook. New - VI Scripting methods and properties for events - Good for tool-chain developers. But no real use case for me. Improvements to the Edit Events Dialog: - Didn't notice Will look again You forget the big one - MOUSE WHEEL . By far the most useful, just a shame it's the only one.

There's a setting in the labview options under environment that should sort that out (it puts cleanupVisa=True in the ini file).

Another method is just to create a windows task (equivalent of chron-job). Apart from just scheduling you can also launch on specific OS events.

I've often wondered why you can't program directly from the hierarchy window in LabVIEW. The hierarchy window is one of, if not the, most under-developed feature of LabVIEW IMO.

Seeing as your link button isn't working I didn't see the Pipes anywhere on there. But I did find a build of lvzip for x64 which everyone has been asking for Did you really create that a year ago?

I'll have a quart of what you are drinking

Don't know about LabPython but the intermediary DLL source for the openG zip and pipe libs definitely isn't distributed with the packages as I would have recompiled them for x64 by now ;P Are they elsewhere? Link perhaps?

As opposed to a dynamic library that you cannot use on other platforms, you mean (e.g.LV x64),. I don't mind this approach as long as people distribute the C source for the intermediary, which seems to never happen

ooooh.Gonna have to check these out. • Flatten To JSON • Unflatten From JSON

Let John find all the issues then switch when you start a new project (if it is after SP1). By all means "play" but as far as real projects are concerned; you are spot on with your current regime IMHO It's all very well "embracing change" but changing/upgrading tool chains is a huge project risk and there have to be specific, justifiable benefits. Unfortunately, I have not seen any practical benefits of note after LV 2009 for my projects. Lets see if that changes with LV 2013.

It's been a long time since I was at school (where we covered this sort of stuff) but I think you are asking about torque and angular momentum.

I'm more of a "If it's not broken; don't fix it" sort of person (Like waiting until LV 2013 SP1 is released ) I think the main difference in your approach is that it will be a push rather than the more common pull distribution. If this is the case. Then security may have to be a greater consideration depending on your environment and exposure.

I have an aversion to PPLs since they are non-reversible and some people have had issues with them (that's why I prefer zipped LLBs). I tend to use directory structures quite a lot for dynamic loading, so zip files are an easy way to mirror the structure as well as compressing and including significant numbers of VIs/LLBs. At the end of the day, it's not really important. The important bit is that you have a plug-in (or in my case, modular) architecture.

This is exactly what dispatcher achieves (all of the above). But your client (or subscriber in dispatcher) still needs the software bit to show your dialogue which is what your first thing and the following is about. Anyhoo. Zip it up (even an entire directory of VIs if you want-zipping maintains the directory structure). Send it across, unzip it and reload (LLBs are good for this). It's a standard plugin from that point on. Of course. If your current software is monolithic, then then you will need to re-factor it to be a plugin architecture. We are lucky in LabVIEW that LV doesn't lock source files so we can read/write/modify them whilst running.

So now you are talking about something completely different. These things are infrastructure topologies. (more like Dispatcher).and don't have a lot to do with showing prompts remotely et. al. It almost sounds (without a knowing exactly what you have at the moment) like you are trying to fit a square peg in a round hole. Distributed systems have to be designed as distributed systems and if your current software isn't (distributed) then just hacking at it will not be very fruitful IMHO.

Option 3. The server has everything labview and the client is a browser with javascript prompts and interfaces. You wouldn't even need a labview run-time on the clients.

Yup. I've seen this not only with dynamic formatting but also in normal usage. It doesn't seem to happen with the silver indicator (but does with the silver frame-less). Have you tried to defer the update?

Well. Some good news and some not so good news. But the "not so good news" is only a little bit not so good First the good news. I couldn't find MJEs interactive DOS thingy, but I found Rolfs pipes library (I don't think it ever got out of alpha, but it works). You can use this to run Plink.exe interactively instead of sending a command file (just remove the -m switch). I've just used it on my VPS and it was fine apart from some dodgy control characters that would need to be filtered, but I started an interactive session and was listing directories and sending commands and reading output.. Now for the not so good news: Rolf wrapped the windows pipes in a DLL that is 32 bit. So flash a bit of leg and maybe post some funny cat images and he might compile a 64 bit version for you If Rolf does give you a 64 bit DLL, then I'll post an usage example to help you on your way.

Write To Spreadsheet File.vi

This is not correct. SSH does encrypt the passwords etc, but it is still a much better idea to use public key authentication and turn off password access as it is impossible to brute force.

Nothing wrong with a guy in his basement offering software Difficult for defence companies however, that have preferred suppliers and require dedicated support channels. The way I usually get round this sort of thing is to offer a short term contract, that way it guarantees the contractor a wage for their work (some people ask for stuff then say naah, don't need it now) and it is an acceptable business interaction from the companies point of view. Yes. But it is even easier than that. Just set everything up as a profile in PuTTY (being a point a clicky person I find a GUI is much better) then, when you need it, just run putty.exe -load myprofile (with system exec). Well. Telnet is a protocol but it is also used to refer to the client. Windows 7 doesn't come with a telnet client installed as default any more (which is called "telnet" and has to be installed with add/remove programs) but the term is used interchangeably.I don't find it very useful to get into semantic arguments with IT people who tend to be very anal, no sense of humour and completely unreasonable when it comes the their network. Just because you re not running the windows telnet client and are using labview, it still means you are running a telnet client, if they want to be difficult. I would speak to the person that issued the diktat and ask if it's acceptable to use the telnet protocol over SSH as LabVIEW has no native support for the SSH protocol and no 3rd parties have an acceptable solution. If they are only referring to removing the telnet client, then this is fine and would work. Be careful though. If they also say you need to remove the telnet server from the nix box, you will be stuffed. So far. I think the best of the evils (if puTTY doesn't do it) is the python approach since jzoller knows of a python SSH library. If you have plenty of C coders that need to justify their existence you could get them to port OpenSSH to windows (and compile it for 64 bit labVIEW). LabVIEW sucks at anything that has encryption/compression in it.

Had to share some humour-had me in stitches all day DYAC My favourite is the CAPSLOCK

Yes. This isn't easy in LabVIEW as the only interface you have is the on-shot Shell Command. MJE did put together an interactive CMD session that could be used for this purpose (not sure where it is though). However. You do not necessarily need to need to keep the link open to be able to achieve a pseudo interactive session but there is probably a simpler way and it's what putty was really designed for. By far the easiest solution for you would be to tunnel your telnet through SSH (you can tunnel anything through SSH ). Create a local proxy" that your telnet client connects to on your local machine (127.0.0.1) and it will be completely transparent, to your telnet client, but secure. You wouldn't even have to write any code As a slight tangent. I also looked at that software package you mentioned earlier a while back. It looked great but relies on a DLL and is just a thin wrapper around that (not cross platform, so no good to me). You could get them to compile the DLL for 64 bit so that you could use it (or you could use LV 32 bit). The long and the short of it is that there is no native SSH library support on windows (in any language, that I know of-maybe Rolf has something) and the only people that really care about it are linux bods since it is only really of any use to connect to linux boxes. Most windows users avoid linux like the plague and get by, when they need it, by tunneling with PuTTy. Windows users use VNC or Remote desktop rather than SSH to talk to remote computers. I count myself in this category too and it annoys the hell out of linux bods when I say to them that all flavours of desktop Linux are themed windows 95 with an encrypted DOS Prompt If you want to really annoy them. When they rattle off a command line (because every Linux user has an Eidetic memory and therefore anyone that doesn't is an amoeba to be treated with scorn), just say to them "you lost me when you said 'type in' "

Flip (mirror) the image.