Jump to content

djolivet

Members
  • Posts

    67
  • Joined

  • Last visited

Posts posted by djolivet

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

    .download.jpg.c9e6484ad568164a504db6d6a5825031.jpg

  2. Apply at:

    http://corporate.ford.com/ShowJob/Id/1269646/LabVIEW-programmer-analyst/

    Job Description
    Position 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.

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

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

  5. QUOTE (crossrulz @ Apr 13 2009, 08:47 AM)

    But my main peev with TestStand is that you cannot create an executable. All of your LabVIEW code (and LabVIEW itself) has to be there on the test station and any fool can come and change code on us.

    Could you not build DLLs from the VIs and call those DLLs from TestStand?

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

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

  8. QUOTE (MikaelH @ Feb 4 2009, 04:13 PM)

    Your are right, and it's sooo annoying.

    I've talk to a NI guy about this and he recommended to use the auto tool selection.

    But I haven't become of friend of that yet.

    This is especially bad when my front panel is covered by a tab control, then I can't find an "empty" front panel place to do my shift-right click combination.

    This is something that really bugs me. :headbang:

    Do anybody know if there is a tweak to fix this?

    Cheers,

    Mikael

    I haven't found a way to switch to the paint or dropper tool when using auto tool selection. Has anyone?

  9. Hi Eric,

    In regards to your question about right click monitoring. I would use the new context menu features (I think this was available for LV8.2). This way you would not have to intercept the right click, restoring normal behaviour on the cursor tree control. See attached.

    Hope this helps

    Denis

  10. Hi Dan,

    I don't have an answer for you, but you should look at:

    Why Are My TDMS Files So Large?

    I found that when dealling with files that are really large (GBs) TDMS format was not usable. It takes too long to degragment, HD space runs out (when defragging a second file is created to contain the output of the defrag, so you have the original file and the defrag output file while processing), opening the TDMS file takes alot of time when not defragmented.

    Denis

    QUOTE (ASTDan @ Aug 18 2008, 02:39 PM)

    Hello,

    I am trying to find a formula the aproximates the size of a .tdms file on disk.

    I am mulling over a few ways to set up my files and having a way to estimate file sizes would be helpfull.

    Does anyone know of a good method to do this?

    Thanks

    Dan

  11. QUOTE (Viswanath @ Jul 31 2008, 06:12 AM)

    Hi djolivet,

    Thanks for your valuable clue. I did generate two signals with low frequencies and i have attched the VI with this post. I can not generate two channel outputs with different frequencies, for example in channel-1, frequency was 10000Hz and in channel-2, frequency was 10Hz and i started VI execution but it shows error indicating that frequency must be less than or equal to half of sampling rate. Please help me, my extream oprational requeriments are 10Hz to 100kHz of frequency.

    Thanks very much to all

    Viswanath

    Hi Viswanath

    your problem is with the 'Basic Function Generator.vi". You've got it set to a generation rate of 1000 sample/second and trying to have it generate a 10KHz signal. Clearly this wont work. Make sure you understand the function and you should be able to figure out your problem.

    Denis

  12. You cannot start two analog output tasks on the same board. You need to start one task that includes both channels. You then need to write to the task with one signal for each channel. The attached image in a non-funtional example of this. Also, make sure you understand the 'reset input' for the generation VI.

    Good luck

×
×
  • Create New...

Important Information

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