ShaunR

Alpha and beta testing (for me) is internal only. Alpha testing will be feature complete and given to other programmers/engineers to break it on an informal basis. For beta testing, it will be given to test engineers and quality engineers for qualification (RFQ). Sometimes it will also be given to field engineers for demos or troubleshooting clients equipment. Clients will never see the product until it is versioned and released.

Well. I deal with automation machines and if it doesn't work there are penalty clauses. The clients are only interested in what day it will go into production and plan infrastructure, production schedules and throughput based on them being 100% operational on day 1. Deficient software is something desktop users have gotten used to and have been trained to expect. Software is the only discipline where it is expected to be crap when new. Imagine if an architect said "here's your new skyscraper, There's bound to be structural defects, but live in it for a year with a hard-hat and we'll fix anything you find".

How so? They can only put it through use cases if it works. Otherwise they are just trying to find workarounds to get it to work. Alpha = Doesn't work. Beta = Still doesn't work.

....... and here's my offering using queues for command and events for response. (not QSE I know, but we have talked about it-or maybe that was another thread )

It'd end up full of classes then-no thanks...lol. I only release stuff that works and looks clean. I also don't believe in alpha or beta testing (it's just an excuse lazy people/companies use for free resource so they don't have to test it themselves!). I had the intention of doing something with it (I've been using it for over a year now), It was a weekends "playing" that did the job at the time.However, now I'm engrossed with with the SQLite API (only one platform left.....woohooo!). Too many homers what with that, websockets and dispatcher. They are all far more mature than this and consume a considerable amount of my spare time. I probably won't get much time to look at it this side of Xmas (but you never know). But come on Daklu. You could knock up something very similar in a day or two yourself with JCarmodys code if you really wanted it that badly All you need to do is to add a snazzy UI and a database (incidentally, it's not a total coincidence it happens to look very much like a database browser that you may have seen before ). If you want something now, then JCarmodys is your best bet. Why not tinker with that and help him productionize it? With you and JCarmody on the case; I'm sure it will knock the socks off anything I can produce. Otherwise we'll just have to see what Santa brings. Meanwhile. Back at the ranch............

Well. I'm not sure that is such a good idea (I'm gonna call a hector a QSE from now on. People will think I've just mistyped it so it may permeate ). But it is suited to a parser so I could quite easily see a good use for it as an emulator.

Indeed. It is a Queue [based] Sequence Engine. Although I am also guilty of calling it a QSM.

The user cannot change anything at all after the vi is started so it will always execute as expected and the dwell times will always be as they are in the array.. So. You slap my 3 vis into cases. What do you do about getting them to execute in the right order with the right parameters? You mean turn a graphical language into a scripting language? Maybe Luaview is of interest:) You may laugh. But that is exactly what you will find is some of the examples using the JKI QSM on this very board. The answer I was looking for is you cannot stop it (without pressing the Labview stop button) once it has started. But that is the only problem. The point I was trying to make is why break up ordered and sequential things that can be defined by the language so that you have to write a load of code to do the same thing and make it difficult to understand and (as Daklu has pointed out) introduce race bugs?. Admittedly it was a contrived example, but it was to make the point. Daklu an I disagree on many things, but we agree on form over function where the choice is arbitrary. Have you seen the event structure state machine?

The point (I think) that Daklu is trying to make is that some operation ARE atomic and, additionally, sequential - which is implied by the relegation of multiple functions to a single sub-vi. Let's consider a very simple example of an environmental chamber where you want to step it through a temperature profile. You have to set the temperature you want, wait for the chamber to get to a obtain that temperature, wait for it to settle, then save the actual temperature to a file.And you continue like this until you have covered your profile. So we have atomic and sequential operations. Here is the code. Now do this with the QSM thingy without just copying my VIs into cases (don't forget to have cases for open, write and close file as well - after all. It is more "flexible" ) What is the problem with my code that the QSM thingy solves?

Why may I ask? Outside of dynamically loaded VI's, I've never had to consider this. Surely this is a deployment aspect rather than a design consideration.

Where the dequeue loop stops before the message has been processed so that when it starts up again, it processes the stale message. Sometimes 3 (if it uses TCPIP) depending on what you call a "message receive" loop. There is only 1 "receive" loop (i.e. that dequeues messages and acts upon them), but there maybe an event handler (UIs tend to have these by default) and/or a TCPIP handler. Both of these "receive" incoming messages via their respective channels and place them on the receive queue proper. So there are 3 ways that a message may get to be processed in the most complicated case. 1. By placing a message directly on the receive queue (normally only the sequencer will do this). 2. By sending the message to the TCPIP handler (which then places it on the receive queue) 3. By sending the message as an event (which then places it on the receive queue). Although all modules can have all three. Usually No.3 is only used for monitoring purposes if there is no UI (since a UI is event driven-it's there already). It is much more common in non-ui subsystems to have no.s 1 and 2 except for, say, an error handler which (will be 1&3). Since the "receive loops" for TCPIP and events are little more than forwarders (the intention being for within the subsystem only), this means they can be dropped into pretty much any subsytem that doesn't have a UI (well. the TCPIP one can be dropped into anything).

Come up with a way to force LabVIEW to be able to override a class method with a VI that has a different connector pane

Perhaps he means an autosterogram

I'm not a fan of the JKI thingy either, but I would argue that classes are far more prone to this than events (or anything else for that matter). The topology I've now adopted for inter-process comms is a queue for the control, and events for response. This gives a Many-To-One for control (great for controlling via UI and TCPIP) and a One-to-Many for the response. A queue for the response has inherent problems with leftover messages and difficulties with permeating the messages to other processes. However, with Events you can easily add monitors to the response and dynamically register other subsytems to the messages (errors for example).

Because, whilst it is OK for me to use as I know how to get around its foibles, it needs quite a bit of work to make it "prime-time". But the main part (the scan engine) is not dissimilar to JCarmodys. To get something similar, you could just spend a day or so writing it yourself since JCarmody has done most of the work for you .

Don't build an array. Build a cluster.

Right click. Save As

Lol.

Is there any reason you cannot use the TARGET_BITNESS of a conditional disable structure?

You want one of these then

Yup. This is where I was talking about type checking which has to be done in the child.

Well. TTestItem would contain your test info (upper limit, lower limit, measurement etc). If you think about it. What you are asking for is, in fact, a TList of TTestItem. You could, for example, create a TTestItems (note the plural) which would inherit from TList and this could be fed into TTests (which would also inherit from TList). So you would end up with a List, of a List of Testitems. This is how it would work in any other language and it sort of works in LabVIEW The point is. TList doesn't care what is in the list. It just provides the methods to manipulate a "List". The purists would (as I am describing) do all the inheritance then override where necessary in each child class (like with GetItemByName). I'm lazy though (and don't want hundreds of VIs). I just create TLists instances and add objects to them just as if it was an array of variants.That is the point where I stop using LVPOOP and use classic LabVIEW since all I'm interested in is using it instead of an Action Engine.

I think you misunderstood. You don't pass an array of objects into the the List (although you could with a TList.Init). The List IS an array of objects and you add the item using the "AddItem" method. So it is already exactly as you describe.

This is where we blur the edge of LVPOOP and Classic LabVIEW since LVPOOP is kind of a kludge. What I think are trying to do (as I have done on occasions) is to implement you own TList. (This terminology is a throwback to my Delphi programming). TList is a class with an array of Objects in the private data. The sort of methods that TList has are things like AddItem, RemoveItem, InsertItem, GetItemByIndex, GetItemByName etc and properties such as Count. It's arguable whether it is required, but I also have a TListItem class which has ItemName and ItemRef as the sole private data in the cluster (mainly because it fits with the hierarchy that I'm used to, but sometimes I use it to abuse the hierarchy). This is the class that I inherit from so I would have TTestItem cLass and TUserItem class and I would manipulate them with the TList. We could actually argue that what I have created is, in fact, a TCollection since any object can be in the list. This is of course generic. I could for example inherit TListBox (or TTreeList, TTableList et al.) from TList and enforce strictly typed TListboxItem (the latter of which would inherit from TListItem). But hang on. Don't we already have a TListbox? (the ListBox control). Nope. Because it is "Classic LabVIEW". It's properties and methods are all about the control as an object, not the contents of the Listbox which, in classic LabVIEW, is just an array of strings. So thats a lot of VI's just to enter and extract an array of strings, but it does mean you can also implement things like Sort and Reverse and claim "encapsulation".

I never said anything about fixed sized blocks. I think we will just have to agree to disagree.