djolivet

I've had similar thoughts. It seems to me the LabVIEW user base isn't big enough to justify the investment to get that type of thing up and running. However, I'd like to be proven wrong. When I entered the LabVIEW world >20 years ago one of its selling points was its ability to create desktop-based test and measurement applications faster and with less effort than the available alternatives. I felt confident that was true based on my (limited) perception of the alternatives, and because the user base seemed considerable. I'd attend user groups that would number 50+ attendees, NI reps were aplenty, and jobs seemed bountiful. I’m not sure both those things are true anymore. I’ve been fortunate enough to find gainful employment with my LabVIEW skills that will probably (fingers crossed) take me to retirement, but the engineer in me is itching to pickup the next best tool as I’m no longer quite so certain LabVIEW is still the king of the hill. Who knows, maybe Emerson will surprise us all?

Maybe you should try to land some freelance LabVIEW work? Back in the day you could locate this type of work through your local NI rep, or attending various NI events and networking. It seems like NI is much less active these days so I'm not sure if that is still feasible. I once picked up a years long freelance gig off a freelance programing website (the site has long since disappeared)

Thanks for the reply. That sounds like a fun little project. I'd love to try this out as well but don't have the time. I guess I'll roll the dice on something and see how it works out...

Does anyone have a recommendation for a USB stack light? There's plenty available on the internet but before I start going through documentation I thought I'd ask here... They'll be deployed in a manufacturing environment, the facility is climate controlled, they will be in a fixed location with little chance of being struck or coming into contact with anything. They'll be mounted to extruded aluminum framing Ideally they are controlled via a command set and don't work on a custom DLL. I'd like them to have a watch dog included so if a command isn't received it will switch over to RED Thanks .

Apply at: http://corporate.ford.com/ShowJob/Id/1269646/LabVIEW-programmer-analyst/ Job DescriptionPosition Overview:We are looking for an entry level LabVIEW Programmer Analyst to be part of our Powertrain Fuel Systems Test Site Management team. In this role, you will be responsible for development, maintenance and support of LabVIEW programs utilized for real time testing at the Powertrain Fuel Systems Lab. You will collaborate with Product Development Test Engineers to ensure ongoing quality and sustainability. Additionally, you will develop and support test programs that run the test cells in alignment with the Test Engineers and changing test requirements and upgrades. Members of Powertrain and Emissions Test Site Management team are located in the greater Detroit area (Livonia, Allen Park, Dearborn). We are a team working efficiently and effectively to respect our diversity, listen to others, help others, and appreciate others while completing our day-to-day activities.Responsibilities: Provide onsite support/development and integration of the test cell solutions related to LabVIEW programs. Test Cell Automation Tools. Data management middleware tools New development to support regulatory requirements. Maintain miscellaneous sustainability tasks Maintain team documentation Be an advocate for customer requirements Job Requirements:Basic Qualifications: Bachelor’s Degree 1+ years of experience developing LabVIEW programs 1+ years of experience utilizing other programming languages (.NET, C, etc.) Preferred Qualifications: Experience with Linux Experience with CalTool or Autotest Data Acquisition and Control understanding Previous experience in the area of IT day to day operations and customer support Experience using the Microsoft Office suite of applications Excellent process discipline skills Good communication skills, both written and verbal Desire to build functional and technical excellence Experience with incident and problem resolution Understanding of Network infrastructure. The distance between imagination and … creation. It can be measured in years of innovation, or in moments of brilliance. When you join the Ford team, you discover all the benefits, rewards and development opportunities you’d expect from a diverse global leader. You’ll become part of a team that is already leading the way, with ingenious solutions and attainable products – and it is always ready to go further.Candidates for positions with Ford Motor Company must be legally authorized to work in the United States on a permanent basis. Verification of employment eligibility will be required at the time of hire. Visa sponsorship is not available for this position.Ford Motor Company is an equal opportunity employer committed to a culturally diverse workforce. All qualified applicants will receive consideration for employment without regard to race, religion, color, age, sex, national origin, sexual orientation, gender identity, disability status or protected veteran status.

I can't explain the behavior you're seeing, but I do as shown below. This was the only option before 'Start Asynchronous Call' existed. The Ctrl Val.Set is obviously an example and you should modify it for your needs

Missing VI:

http://zone.ni.com/r...a_net_assembly/ Calling the .NET Interop Assembly from Another Program After you build a .NET interop assembly, you can call the assembly from other programs that support .NET. However, ensure that the computer on which the other program runs meets the following requirements and recommendations: The LabVIEW Run-Time Engine must be installed on any computer on which users run the .NET interop assembly. You can distribute the LabVIEW Run-Time Engine with the .NET interop assembly. (Windows) You also can include the LabVIEW Run-Time Engine in an installer. National Instruments recommends that the target computer for the .NET interop assembly have the same or later version of the .NET Framework installed as the version that LabVIEW used to build the application. To call the .NET interop assembly outside of the LabVIEW development environment, you must referenceNationalInstruments.LabVIEW.Interop.dll in the Microsoft Visual Studio project. The LabVIEW Run-Time Engine automatically installs this DLL to the National Instruments\Shared\LabVIEW Run-Time directory. ------------------------------------------------------------------------------------------------------------------------------------------------------ I built (interop assembly) a virtual keyboard in LV2011 64bit and a coworker is able to successfully call it from both C# and C++. I had the LabVIEW.exe.config set to <supportedRuntime version="v4.0.30319"/>. My coworker had to specifically target 64bit processor (instead of 'Any Processor') in C#. This seemed to have something to do with witch LV Runtime engine was called (32 vs 64) Good luck Denis

Hi All, On a system we're working on, we are allowing the operator to enter a python script. The script is executed with LabPython, which seems to work well. We implemented the script editing with ScintillaNET (http://scintillanet.codeplex.com/) We also implemented pre-execution script checking (I don’t know the right term for this) with pylint (http://pypi.python.org/pypi/pylint) Attached is an example of our implementation. I’m posting this in case anyone might find it useful. A couple of items that could be improved 1) This implementation used system exec to run pylint, could pylint be run via LabPython? How would you retrieve the output string? 2) Disabling the scintilla .NET control (via a property node) doesn’t fit visually with other LV controls. Could the right look be achieved by manipulating the control's colors 3) Auto indentation hasn’t been implemented. In order for this to work you'll need to install: Python 2.7.2 (This might work with newer version, I haven't tried) http://www.python.org/getit/releases/2.7.2/ logilab-astng-0.23.0 http://pypi.python.o...i/logilab-astng logilab-common-0.57.0 http://www.logilab.o...b-common/0.57.0 pylint-0.25.0 http://pypi.python.org/pypi/pylint SintillaNET 2.2 http://scintillanet.codeplex.com/ If anyone does make improvements to this, please post your updates. Thanks Denis Python Trial.llb

Have you seen this? My linkhttp://lavag.org/topic/7033-browse-for-folder/page__gopid__66623&

Repost BrowseforFolder (NET)(LV80).vi

What if you try formating the numbers on the Y-Axis numbers to Floating Point and uncheck the 'Hide trailing zeros' option?

QUOTE (crossrulz @ Apr 13 2009, 08:47 AM) Could you not build DLLs from the VIs and call those DLLs from TestStand?

You could try opening a strictly typed reference (not sure if this is the right terminology) to the VI and checking the error:

QUOTE (Cat @ Mar 20 2009, 10:06 AM) Yes QUOTE (Cat @ Mar 20 2009, 10:06 AM) After I've closed the front panel and exited the dynamic vi, I expect the vi to still be in memory because it's sitting in Big Top. I *don't* expect it to still be running, tho. Maybe I should be using "abort", but that seemed like overkill. Just because you close the panel of a VI doesn't mean it stops running (as you are seeing).