Jump to content


  • Posts

  • Joined

  • Last visited

Profile Information

  • Gender
  • Location

LabVIEW Information

  • Version
    LabVIEW 2016
  • Since

Recent Profile Visitors

2,026 profile views

djolivet's Achievements


Newbie (1/14)

  • First Post Rare
  • Collaborator Rare
  • Conversation Starter Rare
  • Week One Done Rare
  • One Month Later Rare

Recent Badges



  1. 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...
  2. 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 .
  3. 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.
  4. 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
  5. 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
  6. 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
  7. Have you seen this? My linkhttp://lavag.org/topic/7033-browse-for-folder/page__gopid__66623&
  8. Repost BrowseforFolder (NET)(LV80).vi
  9. What if you try formating the numbers on the Y-Axis numbers to Floating Point and uncheck the 'Hide trailing zeros' option?
  10. QUOTE (crossrulz @ Apr 13 2009, 08:47 AM) Could you not build DLLs from the VIs and call those DLLs from TestStand?
  11. You could try opening a strictly typed reference (not sure if this is the right terminology) to the VI and checking the error:
  12. 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).
  13. The rule is that a VI will be unloaded from memory when its front panel is not visible and no references to it are open. When you run your code WITHOUT the Big Top open and the VI that opened the dynamic VI closes its reference, there is no longer any references to the dynamic VI, so LabVIEW unloads the VI from memery (essentially aborting it) When you run your code WITH Big Top open and the VI that opened the dynamic VI closes its reference, there is still a reference to the dynamic VI on Big Top's block diagram, therefore the dynamic VI continues executing. What I usually do, is launch the dynamic VI, and provide a way to command the dynamic VI to stop (VI Server, Queues, etc). The dynamic VI can then perform any clean up and stop gracefully. This would allow you code to function properly regardless of Big Top Hope this helps
  14. So I got interested in this and put something together. Be warned, its quick and dirty, and my first use of XControls...
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.