ShaunR

I think it does,

I never said that I was using a pattern of any kind. All I am doing is using common denominator implementation for a very specific part of the problem. Frames and steps are both lists and either can contain any object type; it is just a semantic difference. I know what you are getting at, though. This is a good example of the tradesmans viewpoint dilemma or if you go back a few years the very similar Bottom Up Vs Top down design argument. I have stated on previous occasions that I use both in every project (diamond design) I suggest we get into that on a new thread if you want to explore it further as it could go on quite a bit.

I do. Particularly for string manipulation (regex, scan from string etc) where an error is too disruptive. One of my pet peeves, though, is the read from file VIs They give an error 4 when you request more bytes than are left in the file.This has prompted a few of us to create a "filter" vi to reset error 4 which should be a warning at most, IMO.

If you tell me what the troubles are (support thread), I will probably be able to figure it out for you

Manually add the .lvproj file to the project (i.e. itself) then it will appear in the build source distribution.

I say liken [sic] you say litchen [sic] lets call the whole thing moss.

Increase your 100 ms timeouts (and your 10ms listen) to 1 sec. Also. Try the Transport examples and see if you get the same problem.

Uhuh. Like the List object I described earlier Uhuh. One list with an execution pointer and one without Or, as you have decided, A single list with a switch (purists won't like that) Uhuh. A list. All sounds very familiar to me. No pitfalls on the surface that I can see (the devil is in the detail). Just that your "Frame" can also be considered a List/collection of one.

Here is a conversation I've had on more than a few occasions. A: I have a random TCP problem Me: What are the symptoms? A: Message delays. Me: 250ms?. A: No. [iNSERT SECONDS HERE] seconds. Do you think it is the NAGLE algo? Me: No. It's more than 250 ms. A read is timing out. <Time passes> A: Turns out I screwed up, I was retrying/ignoring after a read error.

Well. They have screwed that up in later versions. Here's the old 2009 version .old example.zip You will see it adds "Bed cargo capacity" to "Vehicle" through composition for the "Truck" object. I think the Graphics example also uses composition unless they changed that too.

Lots of contending terminology here. So I will adopt Test Stand terminology since this is what we are trying to emulate. Sequences, Steps and Actions. One way forward is to consider Sequences and Steps as an ordered list (I posted an example on here somewhere). The "List Object" has add, remove, delete insert etc. You may consider an Action as a single element list or you might wish to break it out into a discrete item. It doesn't matter. If you derive Sequence and Step from a List object. That gives you all the management items. Through composition (see the vehicle example shipped with LabVIEW) you can, add an index as a current execution pointer and a string name so we can display a label for our Sequence/Step. That's the easy bit. It gives you management functions and a currently executing marker with a display name that you can show the user. It also gives you a list of items to iterate over. The hard part is how much do we put in the list objects and how much do we put in the contained items within the list object...... So this is great. We steam ahead and add skip, move up and move down for our lists and pretty soon we have the whole UI mapped out and working where the user can add, remove and modify sequences and steps. Then we get to actions. This is the point when I abandon POOP so the others will have to jump in here.

Oh well. Codetyphon it is then

LabVIEW FPs have been needing a revamp for years (silver controls were a placebo). Anecdotally, and exaggerating only slightly, an application will require 2 days to code the hard parts and 2 weeks for the UI with a vast majority of bugs being usability issues. I have exclusively moved away from LabVIEW front panels and now use a browser for all commercial LabVIEW applications. Until such times as they fix and enable completely customisable controls for look, feel and behaviour; I don't see that changing any time soon.

....and bluetooth. They plan to expose the GPIOs too Linux would be OK. Windows[10]? Not so sure. LabVIEW isn't all that hungry. The minimum requirement is 256 MB for the run-time

1Ghz, 512 MB onboard RAM, 4GB onboard storage. End of Rasberry Pi? <thinks>Probably can get LabVIEW to run on it </thinks> Sign me up!

Yes it does. Extra info: Real-time targets have no front panels so UI events don't work.

Well. the answer from the local AE "no support for linux at our office, please try posting on the general forum" isn't really an answer. Sounds like they are hoping a NI Linux dev happens to spot it on a forum and decides to pick it up. The AE should really first communicate with someone that does have Linux (usually in Austin) who will either confirm or deny the problem and then they will raise the CAR if/when confirmed. Reopen the support request with your local AE and tell them you have done as requested and it is confirmed by 3rd parties and request they pass on the information to an AE that is versed in Linux.

Yes. LabVIEW (2012) dies on OpenSuse (13.2) too. No SIGSEGV dialogue even.

It is a real job and you can apply, so why not? I can't apply for that particular position because if I were dressed Kogal and glomping everyone in the morning, it would be frightening and not the sort of encouragement I think they are after

Programmer Encouragement Specialist Please consider me for the position "code monkey"

I'm really unsure who this is aimed at. Who is the target customer? Who are these people that don't use LabVIEW for work or school that will pay to use an IDE rather than use a free one?

Oh dear. Now I'm conflicted.. I'd like to see something similar to that for designing new LabVIEW controls and would put up with an online solution to get that feature (although the compiled control would have to be downloadable to the local drive).

I agree absolutely. In fact. I see it as a parasitic business model. The problem is there are very few arguable reasons why you should not uses these services and even less for why businesses should not adopt them. The one clear winner against is privacy and security but there seems to be a general malaise towards that. It is getting a huge boost from the games industries who are perfecting the technologies and normalising expectations. There is little "skin in the game" in that sector for customers and although some are moaning about not being able to play during outages and not "owning" software; there is general acceptance due to demand for multilayer online games which require internet connections anyway. To a lesser extent, Bitcoin is leading the way too even in the face of huge security failures which can be squarely aimed at online services in isolation and not Bitcoin itself. People seem willing to give away their money to faceless wallet websites when they could just as easily have it far more securely on their own computers and phones. The saving grace for NI, i suppose, is that LabVIEW programmers tend to work in industries where software can amputate limbs so no service business wants responsibility for that and no customer wants such machines connected to the internet.

Not really. It's a service. This is the direction of all applications. The current trend is for your Computer, Gamebox, whatever to merely be a terminal - a bit like in the old Unix days - with minimal software in the form of a client. That way they have a cross platform solution that does not expose their valuable intellectual property at all (closed source with no distribution-monopolize the technology), can completely control access (control over copyright), ensures reliance on their services (control over downstream developers and services) and hoover up all your information to sell.

Its a REST API.