ShaunR

....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.

Unwired, yes. Unwritten? Citation needed. Seems odd behaviour since you wouldn't expect a FP display to show zero in the same circumstance. you would just expect it just not update. Additionally. If you probe the wire in the case statement. It will retain the value, so why not the indicator? This seems like an overzealous optimiser issue.

Maybe there should be a whole section, or at least a dedicated thread, on Lavag for anecdotes like these. You usually get one guru that knows his stuff and is the only person that can make decisions. The rest of the dept are usually just a load of bums on seats armed with a PDF full of excuses which eventually just boil down to the fact that they fart unless the guru says so

Expect a call in few weeks when they close that loophole and the software grinds to a halt once again.

So what was the solution? Tell them that their IT department could only FTP into the system and disconnect it from their network? I've done that before This is why the attitude exhibited by the IT guy at CERN who gave that presentation was so refreshing. In IT, a solutions provider is as rare as rocking horse droppings. Empire building problem providers with aspirations of .tyranny are 10-a-penny.

There are quite a few ways to go about this. Take a look at the examples "ColorMatching Example (Express).vi" and "Threshold Example.vi" that are shipped with the Vision Toolkit. You'll be able to find them in the Example Finder (Help>>Find Examples) and using a keyword search for "vision"

Great. That's the hard bit sorted then. Designing the UI is no different from other visual languages-you have a form (front panel in LabVIEW parlance) and you place controls on it. You just need to learn how too use the editor (the LabVIEW IDE), Once you realise there is no separation between source code and front panel and the only difference between a user interface and a VI is visibility of the front panel (see the VI properties), you should find things really easy.

Rule #1 of arbitrary verbal tasks. Get a signature and a delivery date! First hing you must do before writing any code is get a signature as to what the software will actually do. You need definitive answers to questions such as will it support bank holidays in EU, Asia, USA or all of the above? Does the week start on Sunday or Monday (or is it configurable)? Does "only allowed to use LabVIEW" mean you cannot use a database?. So you need to create a requirements and a design document that details how the software will function then get your boss to sign them! The requirements doc will tell you if you have finished (does the software meet all the requirements). The design doc will tell you how to achieve the requirements (we'll use a MySQL database with these tables and these user interface dialogues). Sneak in a line that says you can use other languages other than LabVIEW to see if they actually read it If they don't then you have given yourself a get-out clause that they have signed that will allow you to fall back to a more comfortable language if time constraints bite or things are too difficult..Signed words trump hearsay, period! Politics- the anathema to engineering You will want to (if possible) use a database so SQL will be your main language, technically. Design this from the bottom-up. Start with your DB, figure out the schema and all the queries then choose your language to generate and display the results of those queries (in this case LabVIEW). Think of your UI as just a string generator for issuing commands and displaying responses. This is the easiest implementation to understand and code for. When you get good at LabVIEW you can be more adventurous but for now KISS! The Database Communication in LabVIEW tutorial is a good starting point to ease you into it. It finishes at just the point where the LabVIEW starts. Get the DB right then just bolt on a front end. You can even get it all working in Java or whatever then swap it for a LabVIEW front end to fulfill the "must use LabVIEW" requirement. This is a 1 day programming, 1 day documenting and 3 weeks learning LabVIEW type of task.

So they are not equivalent. When you disable the power supplies on the test system does the performance improve?

Starting to sound like the object cache. Do you have separated compiled from source? IIRC that was really flaky in 2011. I had no end of troubles with it especially with the 64 bit version. If you haven't already done so. Turn off the separate compiled code and then delete the object cache. Then try a full compile before building the exe.

Well bugger me!!!! Welcome back stranger .

You don't need to use VITs. A reentrant VI is perfectly fine. Just open it with 0x8 flag. Then you don;t need an external template file and it can be self contained in the executable. If you look at the Dispatcher Demo. It has a VI launcher that is used to launch a number of Publishers and Subscribers dynamically. It also does some extra stuff like position and show/hide the FP (useful for debugging).

There is a package (LVSpeak?) that was written by Norm Kirchner that used speech recognition to control LabVIEW. Might be a good place to start.