ShaunR

Most of these I think could be alleviated just by turning on the alignment grid and "snap to".

Too many hours on Linux Double-click will highlight the entire wire and show all kinks, even if behind a primitive Wouldn't be any worse than using classes They've already put in optimisations to increase compile times and code base by 500% for them

Try running the Static Code Analyzer. Any code is crap according to that but it is good for finding wire bends or wires backed up/bent under controls and icons.

ไม่หึง.ไม่รัก

I wouldn't. I'd just take rate of change (dy/dx) of the Vrms and if it went outside a value, count the event (assuming it's a bit noisy and not zero when unchanging).

Use the AC & DC Estimator VI to measure Vrms and just note when Vrms changes.

Came across a nasty little issue today. It seems that the Mouse Events are not backwards compatible between 2009 and subsequent versions. Following is a link to a zip file that contains two VIs. One is saved in LV2009, the other in 2011. If you open the LV2009 version in any later version you get a broken wire. The 2011 version, however is OK when opened in 2012/13. If you back-save (Save For Previous Version) from a later version to 2009, you also get a broken registration reference wire when loading back up in 2009 . http://www.labview-tools.com/download_file/119/309/ .

That's disappointing. I've nearly finished my MDI API

Well. My list doesn't just include stability. It also includes performance (both exe and IDE). There have been only 2 that have been exemplary (too long ago to remember exactly before 7.0, but started at around 2.x and have no bad impressions). Only labview before 8.x was bullet proof IMHO and even as far back as 2.x it was rare to get an Insane Object (the equivalent of a GPF in the more modern versions) which I experienced 2 or 3 times a year.. So. Outstanding editions: 7.x 2009 There have been some real dogs too 8.x (yes all of them!) 2010 That leaves high project risk but maybe worth it for the features or if specific fixes address business critical problems you have experienced (they didn't for me).. 2011 ("Performance and stability release" was a joke, and I said so at the time) 2012 So on to 2013. My experience so far is that it is excellent and, if it didn't have the JSON issue or it had a a few more new events, I would have upgraded from 2009 when SP1 comes out. The issue for me is that when installing the latest DAQ it states that it will bork 2009 DAQ functions and I'm not prepared to do that. So whilst I might have upgraded to LV2013, I am now and will be forever stuck at the current version of DAQ until I abandon 2009..

Have you tried updating from the 2013 device driver DVD? A nasty little gotcha!

You can still keep your state machines. Just contain them in modules with defined responsibilities and interfaces so that they are encapsulated..

That's why I like my title of "Archetype". Old and experienced; one of the original blueprints familiar with the arcane arts of LabVIEW

I don't use quickdrop but I've always wanted a palette that shows (say 10 of) the "most used" VIs similar to how chrome shows the most visited web pages. I've also wanted dockable palettes so that the "favourites" could be docked to the top of the screen. I think it's very limited use of the screen space to have the floating windows (urrgghhh. The probe window!). The same could be applied to "quickdrop". Just dock it to the top of the screen and have a single text entry like the chrome address bar that drops down when you type stuff into it and goes away when it loses focus.

Well. It wasn't particularly hard or time-consuming to code a proper solution. The caveat however is that you either needed to have done it before and already know the equation (there are lots of these kinds of things in Javascript- including this one) or you needed to very quickly realise the trig and the primitives to use (usually from experience). Just the x axis doesn't cut it for me. That's why I think it is a fantastic task. Easy and quick solution if you know it (Yeah. Yours is super creepy. A fascinating window into your psyche )

Indeed. I suspect that a separate "Job Manager" would simplify things immensely which is why we are talking about modularisation. Again. If you have a "Log" module, then it can do its thing whilst the UI gets on with just updating the UI. On the surface, the UI seems to be trying to do too much (it's an aesthetically pleasing one however - much better than I could mange) I am still maintaining that delegating much of the current UI functionality into separate modules will be beneficial in terms of maintenance, readability and robustness. I'll see what I can come up with. That'd be great. It's an interesting project and I'm keen to play so if you can get that done, so much the better (PM me log-in details if necessary). I'll take a detailed look at the code when you've set that up. What will be the end product of this software? Commercial? Open Source? Lavag? Do you have a deadline?

I agree - poor task indeed. It was supposed to be a "coding" challenge, not a "semantic interpretation" challenge. Christines was fantastic though and, to my mind, no-one got the solution.

Is it a case that it used to work on the RT platform and doesn't now. Or is it that it works in windows and now you want to use it on the RT platform?

Everything seems to be there. Sweet. I'll take a more detailed look later. QSMs are notoriously difficult to follow without state diagrams and there are a few in there (Did I mention how much I hate the JKI statemachine ) So. If the main VI organises and "makes sure that only one of the jobs (i.e. either downloading or Uploading) can use the connection at a time". This is what I mean about modularisation. The UI just handles the UI stuff only and a separate module has responsibility for managing the connections/jobs. As a first pass (very quick) glance, you seem to be sending a lot of messages and data to different loops which don't really do much apart from pass them to other loops or VIs (please correct me if I'm wrong). This is a code smell to me that you may be better off with events rather than queues as different parts of the program can register for the same messages and have their own message filters if necessary. This approach also allows better modularity as you can create self contained message handlers that deal with very specific usage aspects of the message data. A good example of this would be the status where you want different parts of the program to obtain info about the individual downloads from the connection manager and update log files, and the UI . So the sender broadcasts it's data for anyone interested to hear, rather than pushing the data to a number of specific queues.

Yeah. Well. You'd run into problems with me then, because I use 4*1*1*4 almost exclusively. With this layout the programmer has the choice to place key parameters or indicators (like AE typedefs or event refnums) above or below the VI depending where there is more space and/or less wire crossing. With the introduction of polymorphic VIs; there are only rare occasions where more than 6 inputs or outputs are required..

There are still a load of VI's missing (like the ones that actually upload and download. I would suggest you put all the files in the project (not just the top level one) then make a build specification for "Source Distribution" (don't forget to manually add the dynamically loaded VIs). However. You are opening all the TCP connections (the TCP connection pool) in the top level GUI and then passing the refs to both upload and download things that are missing (so I don't know whats in them). Unless the upload and download managers (the things) negotiate between each other, I can guess,that when you set the No to 30 they both think they have those 30 connections I would let each manager open it's own pool of connections or use a LV2 (not re-entrant) self initialising global that creates them on the first call only and place that in both (i.e not in the top level and not passing them). Not knowing what is down further, so you may already be doing it or it may not be pragmatic............ Generally with this sort of thing, I would let each download/upload subVI connect, login and download/upload and not open all connections at once, rather, limit how many spawned processes there are with the manager which would ensure that only X are running and queue additional requests until one or more has finished. This suits a messaging architecture, however, since the manager is always running and you just send it the data (as a message or series of messages) that you wish to action (upload or download). This approach completely modularises and separates the UI from the manager and the manager from the downoader/uploader code so they all can be run in isolation as stand-alone modules whilst developing and debugging

I would suggest modularisation. Create a VI that connects and does everything you want it to do for one connection, then just launch 30 clones (or however many) of them on demand asynchronously. You only need to send status data and the final file data to the main UI. (Some VIs are missing btw Pars Que States, Add State To Que etc) Take a look at the quick and dirty example in this post. Download.zip

Here you go. MH: Message Handler. Executes functions based on messages. QMH: Buffered MH that operates on an ordered list of messages. QSM: A flavour of QMH that operates as a state machine. MHL: a description of a Message Handler (MH) because it manifests itself in LabVIEW as a while loop.(redundant).

Have you checked the DLLs with the RT DLL Checker?

Everyone thinks that the CLAD exam is to test for understanding. It isn't. It is a test for Compulsive Labview Alignment Disorder. So all certified programmers have this pre-occupation.

It does run the VI, but the VI is attached, externally, (for want of a better explanation), so you do not need any code whatsoever in the child to get it's events and the top level VI doesn't co-opt the childs events (the child can behave as as a discrete module-handle its own events and broadcast them when actioned to the parent). I'm also not saying it is better. It's just a technique I have found that keeps responsibilities modularised and the parent clean of module specific event handling.