Jump to content

lavezza

Members
  • Content Count

    57
  • Joined

  • Last visited

  • Days Won

    7

Posts posted by lavezza

  1. One thing you might consider is NOT using LabVIEW 64-bit. We run dozens of Windows Server 2012 R2 (64-Bit) servers with 32-bit LabVIEW applications. Unless your application needs LabVIEW 64-bit due to large memory requirements, there is no need at this point to build your apps in LabVIEW 64-bit.

     

    That said, if you do decide to use LabVIEW 64-bit all of mje's comments apply. 

  2. Job Posting

    We are looking for another LabVIEW developer to join our team near Los Angeles.

    Here's the short version:

    We build rockets and spacecraft. We deliver cargo to the International Space Station and we have a contract to demo manned launches. Our goal is people on Mars.

    Our group writes the software to control the launch pad and rocket before liftoff. We also write the software that commands and monitors our spacecraft in orbit.

    We use LabVIEW as a general programming language. Our PXI/DAQ components are a small, but mission critical part of the equation. Large application development, object-oriented design, 100+ computers networked across the globe. It's pretty damn cool.

    Some legalese:

    To conform to U.S. Government space technology export regulations, applicant must be a U.S. citizen, lawful permanent resident of the U.S., protected individual as defined by 8 U.S.C. 1324b(a)(3), or eligible to obtain the required authorizations from the U.S. Department of State

    post-192-0-63291400-1350931466_thumb.jpg

    post-192-0-33150600-1350931472_thumb.jpg

    post-192-0-89715800-1350932013_thumb.jpg

    post-192-0-06415900-1350932176.jpg

    • Like 1
  3. Our Launch Operations team keeps growing. Time for another LabVIEW developer. Specific questions: Email me

    Please use this link to apply. It will tag your application as coming from LAVA. (I've placed a similar post on the NI forums. That link will mark it as coming from NI. Our review process starts with LAVA, then NI, then SpaceX.com/careers, then generic job sites. Short version, use this link and not the one on NI to get higher in the queue)

    Important: To conform to U.S. Government space technology export regulations, SpaceX hires only U.S. citizens and U.S. Permanent Residents.

    Responsibilities

    • Help maintain and upgrade the PXI/LabVIEW systems that control launch pad equipment.
    • Help maintain and upgrade the LabVIEW-based vehicle control system used to command and monitor our Falcon 1 and Falcon 9 launch vehicles.
    • Assist with developing, maintaining and upgrading the LabVIEW-based Mission Operation system used to command and monitor our Dragon spacecraft.
    • Design, develop and support new LabVIEW-based applications and utilities as needed.
    • Maintenance of Mission Control Centers with the help of our IT department.
    • With the exception of the launch pad equipment program, most of our LabVIEW programs do not interact with DAQ hardware. While hardware experience is expected, advanced LabVIEW software skills are more important.
    Requirements
    • Bachelor’s degree in computer science, electrical engineering or related discipline.
    • Minimum of 3 years CLD level LabVIEW experience.
    • A good understanding of basic computer networking (TCP/IP, UDP, firewalls, VPN).
    • Ability to learn new skills/languages/applications quickly (C++, MATLAB, JavaScript, STK, etc.).
    • Must be enthusiastic about space systems.
    • Must be willing to travel. Common destinations include Houston (NASA Johnson Space Center), McGregor TX (test site), Cape Canaveral FL (launch site), Kwajalein Marshall Islands (launch site).

    Preferred skills

    • CLD certification

    post-192-0-68587400-1305053669_thumb.jpg

    post-192-0-02234400-1305053673_thumb.jpg

    • Like 2
  4. Description

    Our rapid growth has created opportunities for additional Mission Operations Engineers focused on Mission Control software development to support the launch, orbital operations and recovery of our Falcon 1 and Falcon 9 launch vehicles and our Dragon spacecraft.

    Responsibilities

    • Help maintain and upgrade the PXI/LabVIEW systems that control launch pad equipment
    • Help maintain and upgrade the LabVIEW-based vehicle control system used to command and monitor our Falcon 1 and Falcon 9 launch vehicles
    • Assist with developing, maintaining and upgrading the LabVIEW-based Mission Operation system used to command and monitor our Dragon spacecraft
    • Design, develop and support new LabVIEW-based applications and utilities as needed
    • Maintenance of Mission Control Centers with the help of our IT department

    With the exception of the launch pad equipment program, most of our LabVIEW programs do not interact with DAQ hardware. While hardware experience is expected, advanced LabVIEW software skills are more important.
    Requirements
    • CLD-level LabVIEW experience
    • BS degree
    • A good understanding of basic computer networking (TCP/IP, UDP, firewalls, VPN)
    • Ability to learn new skills/languages/applications quickly (C++, MATLAB, JavaScript, STK, etc.)
    • Must be enthusiastic about space systems
    • Must be willing to travel. Common destinations include Houston (NASA Johnson Space Center), McGregor TX (test site), Cape Canaveral FL (launch site), Kwajalein Marshall Islands (launch site)

    To conform to U.S. Government space technology export regulations, SpaceX hires only U.S. citizens and U.S. Permanent Residents.

    We are an EEO employer that offers competitive pay, comprehensive benefits and stock options.

    Apply at https://spacex.com/careers.php. Search for Keyword: LabVIEW. Position is listed as Mission Control Software Engineers (LabView)

  5. SpaceX is looking for engineers with LabVIEW programming experience for our Launch group. Our responsibilities include:

    • Controlling launch pad equipment via PXI/LabVIEW
    • Commanding and monitoring our Falcon 1 and Falcon 9 rockets via a LabVIEW-based Vehicle control system
    • Commanding and monitoring our Dragon capsules via a LabVIEW-based Mission Operation system
    • Ocean recovery of Falcon 1 and Falcon 9 stages after liftoff and Dragon capsules after splashdown
    • Cargo configuration of Dragon capsules going to resupply the International Space Station
    • Maintenance of Mission Control Centers with the help of our IT department

    With the exception of the launch pad equipment program, most of our LabVIEW programs do not interact with DAQ hardware (unusual, I know). The Vehicle control and Mission Operations software get their data via Ethernet from 'black boxes' that connect to NASA & Commercial RF ground stations. We also create several utility programs in LabVIEW that also don't interact with hardware. So, this is mostly a software gig, not a hardware/software gig.
    Ideal candidates will have the following qualities:
    • CLD-level LabVIEW experience
    • A good understanding of basic computer networking (TCP/IP, UPD, firewalls, VPN)
    • Must be enthusiastic about space (What year did we land on the moon? How many men walked on the moon? How many Space Shuttles do we currently have? etc.)
    • Must be willing to travel. Common destinations include Houston (NASA Johnson Space Center), McGregor TX (test site), Cape Canaveral FL (launch site), Kwajalein Marshall Islands (launch site)
    • Must be able to work without supervision. We have a very flat management structure, no one will be telling you what you need to do. If you don’t know, ask. If you do know, get it done.

    About the job:

    • Job is located in Hawthorne, CA in the Los Angeles area.
    • This is not a 9-5 job. There will be some late nights.
    • You won't be LabVIEW only. Everyone chips in as needed. Our group has done Javascript, C++, MATLAB, configuring of TELEX comm systems, cutting of metal with bandsaws, welding, Unigraphics CAD, etc. If we need it and you don't know it, grab a book and learn.
    • We are only hiring full time employees. Contractors need not apply.

    To conform to U.S. Government space technology export regulations, SpaceX hires only U.S. citizens and U.S. Permanent Residents.

    Apply at SpaceX.com. Click the Careers button and fill out the general application. Mention this posting in the cover letter field. Don’t reply to this forum. You need to go to SpaceX.com to get your information into our system.

  6. I'm curious to see how other people have dealt with this problem. (or would deal with it)

    Example: We have a system with 1000's of sensors, things like temps, pressures, switch status, etc. Some of these may be changing at 5Hz, some may only change a couple times a day. A third-party data system collects the readings at different rates. In addition, some of the sensors are smart and only send data when things change. So, we get packets over the network and we need to save them. Each packet will have a different number of sensors reporting and a timestamp. Obviously the packets contain both the data and the sensor names or else we won't know what we were looking at.

    What would be the best way to save this data that would allow quick access (users want to be able to call up a plot of old data quickly)?

    Conceptually, you can look at this as a big spreadsheet table with a timestamp column and a column for every sensor. Some of the sensor columns would be very sparsely populated.

    We looked into storing data in TDMS files, but while we can quickly pull out the data, it looses it's timestamp. In other words, if we saved 1000 packets, we would have 1000 timestamps and maybe 120 samples of sensor1. If I pull the 120 samples of sensor1 out, I don't see a way of getting the 120 timestamps that sync up with those readings.

    We could use a database, but I'm concerned about the speed. We'll have to do some testing.

    Has anyone faced this kind of problem? How have you handled it?

  7. QUOTE (JFM @ Sep 25 2008, 11:26 AM)

    One thing that convinced me to have separate repositories was that the revision graphs documentation states, that it will fetch all log messages from the repository root, to generate the graph. It also says that it will decrease in performance with higher count of revisions. Therefore separate repositories are much more likely to stay reasonable in size, and in turn be more responsive in terms of the revision graph output.

    You can find a similar problem in ClearCase when you let your VOBs grow, having to many label types within one VOB slows down the ApplyLabel operation badly.

    (I recently did a comparison between CC and SVN/TSVN for my company)

    /J

    JFM,

    Can you share your findings from your comparison. We are in a situation where our company is trying to get us to move to CC (our corp standard), but we'd rather move to SVN. We're using SourceSafe right now. I'd be interested in what you found out, especially any LabVIEW specific items that we should be aware of.

    Thanks,

    Pat

  8. QUOTE(gmart @ Nov 26 2007, 08:36 AM)

    You are correct that the mechanism is not documented but that doesn't mean that it's not extendable. The list of VIs in the "sccapi" directory should give you an idea as to what VIs need to be written for a new plugin (as a hint, "Find All Providers" is where the list of "installed" plugins is returned to the SCC config page).

    You're right. After my last post I took another look and realized it was easier than I thought. I'm not sure how I missed that the last time. I think it would be fairly easy to take the P4CMD folder and make an equivalent for SVN (or any other SCC that has a command line interface).

    Pat

  9. QUOTE(gmart @ Nov 21 2007, 04:36 PM)

    Both. I don't even think I have enough RAM to open all the VIs, let alone run them. Obviously a lot of our VIs are called dynamically. Besides, having 6000 open windows would be a little hard to handle.

    QUOTE(gmart @ Nov 21 2007, 04:36 PM)

    Having separate source and object code is a long standing request. Just because it hasn't happened doesn't mean it hasn't been considered.

    I can read that two ways: "It's been considered and rejected" OR "It's been considered and I'm not going to tell you more than that." :)

    QUOTE(gmart @ Nov 21 2007, 04:36 PM)

    If you are interested in this, I would contact your sales rep and work through the system to see if something can be arranged. It would be great if the LabVIEW community would develop custom SCC providers. If you wanted to work with the functionality that is currently there, let's just say that it wouldn't be too hard to look at the current provider implementations and deduce your way to a functioning SCC backend :-)

    I've looked at the Perforce specific VIs and came to the same conclusion. I didn't dig much deeper than that but I did see that there are other things that would need to be done for it to work. For example, the preferences for LabVIEW only display Perforce and providers that have MSSCC interfaces, but only if they are installed. And it looks like the code that determines which VIs to call is locked. There needs to be a way to tell LabVIEW 'Add Subversion to the list of SCC Providers and call the VIs in the \vi.lib\SourceControl\Providers\SVNCommandLine folder'. There may be a way to do this now, but it certainly isn't documented. Adding provider specific menu items to LabVIEW would be another (currently impossible?) task.

  10. QUOTE(hviewlabs @ Nov 21 2007, 12:19 PM)

    And the correct value is determined by what? Say, if we dereference the pointer to a location to which a dll function has written something and we have the definition of the data structure for that pointer in the .h file, how exactly do we choose the PackType? Does it depend on OS, language/compiler used to make the dll, some options set in the compiler?

    The compiler. I think MS defaults their compilers to '#pragma pack 8' for 8-byte alignment. Although I'm not sure that all their internal data structures are done that way. We had this issue not too long ago. I was too lazy to write a wrapper DLL for a DLL written by another group in our company. There was one call that returned a structure. Reading it as a byte array and casting to a cluster wasn't working. It worked after adding some 'dummy' U8's into the cluster. When changes were made to the DLL we got them to compile with '#pragma pack 1', which is basically no byte alignment, so we didn't need the dummy controls. Eventually they just added a second call that returned the same data as separate values instead of a structure. Of course this isn't usually an option unless you have some sway with the DLL owner.

    Pat

  11. QUOTE(hviewlabs @ Nov 21 2007, 12:19 PM)

    And the correct value is determined by what? Say, if we dereference the pointer to a location to which a dll function has written something and we have the definition of the data structure for that pointer in the .h file, how exactly do we choose the PackType? Does it depend on OS, language/compiler used to make the dll, some options set in the compiler?

    The compiler. I think MS defaults their compilers to '#pragma pack 8' for 8-byte alignment. Although I'm not sure that all their internal data structures are done that way. We had this issue not too long ago. I was too lazy to write a wrapper DLL for a DLL written by another group in our company. There was one call that returned a structure. Reading it as a byte array and casting to a cluster wasn't working. It worked after adding some 'dummy' U8's into the cluster. When changes were made to the DLL we got them to compile with '#pragma pack 1', which is basically no byte alignment, so we didn't need the dummy controls. Eventually they just added a second call that returned the same data as separate values instead of a structure. Of course this isn't usually an option unless you have some sway with the DLL owner.

    Pat

  12. My 2 cents.

    Our current project has 6554 *.vi or *.ctl files. Having an "All VIs" vi is not an option :)

    We are constantly being bitten by recompiles. On one hand you don't want a lot of checkins for VIs that weren't really changed. (Especially when your customer requires an explanation for changes in source files from one delivery to the next) On the other hand you don't want to leave the system in a state where 1000's of VIs are recompiled every time you run.

    Here is what I'd like (and I've passed this on to NI already):

    Right now we have source & object code in same file, run time menus in separate file.

    [sample.vi & sample.rtm]

    I would like the option of saving source and object code separately and the option of saving run time menus in the source.

    [sample.lvs & sample.lvo] = LabVIEW source with internal menu and object code files

    [sample.lvs & sample.lvo & common.rtm] = LabVIEW source, object code file and external run time menu (because sometimes multiple displays share a menu structure)

    [sample.vi] = Single file with source, object code and menu

    [sample.vi & sample.rtm] = Just like now

    So you would be able to configuration control the *.lvs & *.rtm files. The *.lvo files would be recompiled as needed and not be tracked by version control. Same as traditional languages. Basically, every SCC system assumes SOURCE is being controlled, not OBJECT files. LV needs to support this separation if we really want to take advantage of common SCC systems. Single files were fine when most LV projects were small programs developed by small teams. Not every LV program fits that description anymore.

    The other option would be for someone to alter a SCC program to compare *.vi files only by the source part of the file. This would require someone to know that internal structure of the current *.vi filetype. I'm guessing it would also be slower. Not something I want to tackle.

    As for the integration into the LV editor, it would be nice if the interface was opened up a little. Obviously there are limits to what can be done with MSSCC. Couldn't NI provide a way to let you develop your own VIs that are called when the SCC menu options are selected in LV. Right now the Perforce VIs call the Perforce command line. Someone could to the same thing for Subversion. If the SCC menus were configurable, someone could develop VIs that call the ClearCase command line (or use ActiveX?) for the advanced options that aren't supported by the MSSCC API. I think that NI could definitely update LV so that the SCC integration is more of an API. They could provide the basic MSSCC and Perforce VIs and let the community develop more advanced options.

  13. QUOTE(Justin Goeres @ Aug 27 2007, 12:51 PM)

    Well, it's nice to get it to work consistently. Unfortunately, it would be consistently wrong (at least based on the way we think it should work). We've already written a work around for this particular VI, but it would be nice if it worked the way we all think it should.

  14. We have discovered a problem and I would like some help from the community to see if this is widespread.

    I've attached a VI that I'd like everyone to run.

    The user changes a numeric control and then immediately clicks in a listbox. The Value Change event for the Numeric gets the value of the listbox and displays it in a dialog.

    On most of our machines, the listbox value changes after the Numeric Value Change event. On some it changes before.

    On the machines with the odd behavior, it shows up in 7.1.1 and 8.2.1.

    If you follow the instructions on the front panel, I think you should get zero. Some users get two. I'd be interested in seeing what other people get.

    VI saved in 7.1.1

    Thanks,

    Pat

    P.S. I did do a search on LAVA, NI Forums and NI KnowledgeBase. I didn't find an answer.

  15. QUOTE(Val Brown @ Aug 14 2007, 06:04 PM)

    Quick question on the Statechart Module -- is that included in 8.5 or is it a separate (purchased??) module/toolkit?

    NI.com lists it as $1499 in the US and CAD1800 for you Canadians.

    It it marketed as a Module (on the same level as Real-Time, FPGA, PDA, etc.) and not as a toolkit (like database, VI analyzer, etc.). Most other modules are available with a significant discount if purchased with the NI Developer Suite, but it doesn't look like the Statechart module has been added as a Developer Suite option yet.

    Pat Lavezza

  16. I think an Advanced Topics Day on Friday would be great. Plus it is an excuse to stay for Friday night on 6th street :P .

    First, there should still be advanced sessions during regular NI Week or else we'd all get bored.

    Second, I would like to see longer time slots. I'd like an hour long in-depth presentation followed by an hour long discussion with the developers. Four or Five of those sessions plus a short lunch. The interest may even be small enough to have it on the campus (since it is probably too late to get that Friday slot at the convention center next year).

    I can imagine sessions on LVOOP, Large Projects (project window, multiple developers, multiple targets, source control, etc.), Improving Performance, FPGA, Real-Time, XControls, VI Scripting (come on, release it to NI Labs!).

    Pat Lavezza

×
×
  • Create New...

Important Information

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