ShaunR

I didn't attend. But I watched the vid. The QMH was confusing to me. I don't see any difference personally between an actor "Do" and QMH as I don't think there is one and it seemed that you were not really convinced there was one either I do however see a huge difference between Actors,QMH and Queued State Machines (and you mentioned the JKI QSM as in reference to QMHs) and in that context I agree with many of the things you often espouse. The usual example I give for QSMs is reading a file, since it is a lot of code and a lot of messages all to do something that can be done in a single simple VI and there is little benefit in splitting out the states. That VI would then be put in a QMH or Actor. In terms of presentation skills. The only thought I had was something I was taught which is that it's not productive to read verbatim what is on the slides. The audience will do that. It only eats time and doesn't purvey any more information. ........later.... Nope. I do know the difference between a QMH and Actor and I don't think it's semantics. QMHs don't contain state and the state is driven by the producer. If they do maintain state, then they are QSMs (QSMs and Actors being subsets of QMHs). So an Actor can be the same as a QSM if it does not manage it's state (unusual) but a comparison between Actors and QSMs would have been clearer.

Pretty much my response when I found out it behaved like this. Indeed. Although I don't think the decision has anything to do with speed, That comes from the fact it is compiled rather than labview code. It's just an unnecessary literal interpretation of "string" that hobbles the API. You see this kind of thing quite often when designed purely from spec without use cases. There is no advantages to this behaviour apart from specmanship, but there are serious disadvantages IMHO The frustrating thing for me (as I think I said to AQ when he was talking about his serializer) is that it is probably the one feature in LV2013 that would make me consider switching from LV2009, They've fixed a few of other things I wasn't happy with 2010 onwards that made me completely resistive to upgrading and the JSON Vis were just the sort of feature upgrade I have been waiting for all these years. So as excited as I was to see these in the palettes, I think I will stay with 2009 and use the 3rd party libraries as it is a lot cleaner, more compact and vastly safer.

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