ShaunR

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.

Don't forget to also show your appreciation by clicking "Like This"

Had a chance to look more closely now. You can save yourself having to load "special" VIs that take a custom event via controls or detecting mouse over/move events on the child FP (checking mouse coordinates in region etc in the main VI) by attaching a callback to the VI when you load it. The callback can be attached to any VI to piggy-back the child VIs events and inject your own user event that you can access in your main VI. You can attach these call backs to not only the VI server events (close, mousemove, resize et. al.), but controls/indicators as well. I think it would greatly simplify you main VI.

That was the best presentation I have seen for a number of years on any subject

If you use the OS tab control via activex or .NET. you can add/remove pages dynamically.

I wouldn't say "many", probably just two - the "string" anality and you can't wire an object to it. The former is trivial to resolve and based on a whim. If it did not behave in this fashion, it would be great for 99% of cases. The latter? (1%) I expect extremely difficult and was probably flagged as "too much hassle", but it would have had far reaching positive implications for networked transfers and possibly dynamic instantiation of objects.

Naah. It's just splitting the frames into separate VIs. There is no real practical difference between a class and an AE apart from code bloat In fact, many people put classes into polymorphic VIs so they can get back to a single VI (ala an AE ) once they've split out all the functions. If it's warranted, I usually just cut out the middle-man and create the polymorphic VI with a LV2global which solves the many conpane connection problem and gives adapt-to-type as well as a nice selector instead of an enum (and avoiding some of the nasty side effects of adding items to enums). Slightly off-topic. But I've noticed a preference of combo-boxes as selectors instead of enums in LV2013.

Just looked now. There are only two frames. Exit and "No Event", Default. Well. I'm going to shift/clarify my position, just slightly, although I maintain all I have said is correct. The QSM is as described and the other example is a QMH, but the QMH example doesn't define a QMH, but it a more common one. As I said on another thread. A QMH just means it's a buffered message handler (buffered by a queue, shift register, lemons). How it is handled or how it is buffered is irrelevant. It is a genericism that has buffered messages and are handled by some code. So the QSM is a QMH with specific characteristics that make it behave as a state machine and I have tried to define what those differences are in comparison to a non state machine QMH.

Indeed. In the sense of an ordered list of messages and "how" it is realised (queue primitive or while loop with shift register) is, IMO, irrelevant (thanks for spelling out MHL->Message Handling Loop. Maybe I can make up the acronym OLOM Lets see if it catches on ) A message handler, handles messages. Period. A queued message handler buffers the messages before it handles them. That's really all there is to it.

OK. Here's how I see it, for my sins (it's rather similar to FGV and AE). A queued message handler is a collection of frames that are basically an API of discrete functions driven by an ordered list of incoming messages. There are no inter dependencies between the frames and they can be called in any order at any time. You are sort of right in your thinking out loud, in that they generally do not have shift registers but that isn't a defining feature since it may have shift registers to maintain the state of that individual function/frame (lets say a counter). But that state is not used by any other frames and is not propagated. The module, as a whole, does not have any state. Any frame, at any time can be executed without regard to previous calls or calls to other frames. An example of this definition would be something like a Drive controller. It has moveTo, Stop, Reset, getPosition etc. The "state" of the drive would be maintained by an external module (usually a sequence engine) which would call the methods in the right order and at the right times. The drive state is maintained external to the module - it is just a collection of functions. There are very good reasons for doing this, most notably, that the sequence engine knows of other dependent states of the system so you don't do something like drive a ream into the bed when no part is present. Externalising the state in this case helps you decrease application specific functionality of the module and reduce module interdependence. A QSM is also a collection of frames driven by an ordered list, but they are interdependent and must be called in various orders depending of the internal state of the module. Additioanlly, the frames may add messages that were not on the original list. As said before. I use the reading of file as a trivial example as I've seen it many times and think "what a lot of code to achieve very little" There, you may have open, read, write and close frames, but the API interface is ReadFile/WriteFile. When actioned, each frame is called in the correct order dictated by the internal decisions about the state of the file. It is no longer just a collection of functions, it has interdependent frames and maintains internal state (of the file whilst executing).

Well. There is no real difference between FGV and AE from your definition apart from an arbitrary break point to try and make a differentiation.. They both have methods. They both enforce interaction to the internal memory only via those methods and they both only operate on the data supplied externally to their terminals. It's a bit like saying there is a special name for a class that only has methods and no properties-it's still a class. What about a self incrementing counter that gives you the next value when it is called? That only has a Get method-what is that under your definition? If you really wanted to make a differentiation so as to define a FGV as something different from an AE,, Then you could argue that a FGV does not contain state (only functions and its output is predictable and constant given the inputs), whereas an action engine does contain state and it's output is dependent on the internal state. Under this definition, the Get/Set would be a FGV and the self incrementing counter would be an AE. But I think the number of methods is a bit weak

Agreed. I don't think there is a difference apart from terminology. The get/set FGV is just a problematic corner case AE. I equate AEs with singleton classes rather than global variables and that a LV2Global is the protected storage of an AE just as the private cluster is in a class.

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.