lavezza

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.

%^<%j/ %H:%M:%S>T[/CODE] [CODE]%^<%j:%H:%M:%S>T[/CODE] 287/ 23:15:42 287:23:15:42 Day of year, 24hr UTC. It is how things are scheduled on the International Space Station, TDRSS satellites, etc. I think files usually use the second format, displays use the first.

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

Here are the VIs we use for Windows authentication and domain groups. Validate Username and Password.vi takes the username and password and returns a TRUE if it validates against the domain controller. User in Group.vi takes a username (or current user if left blank) and a Domain Group name and returns TRUE if the user is a member. User Groups.vi takes a username (or current user if left blank) and returns an array of Domain Groups to which the user belongs. We only use these on our internal network, so I can't guarantee they work in every situation. Still, they may give you a starting point if you need something similar. Pat P.S. LabVIEW 2010sp1 User Groups.vi User in Group.vi Validate Username and Password.vi

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

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)

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.

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?

Is the Property App.MenuLaunchVI available in the new scripting toolkit? I didn't see it. Is the functionality available with another call? Thanks, Pat

QUOTE (JFM @ Sep 25 2008, 11:26 AM) 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

QUOTE(Tomi Maila @ Feb 7 2008, 10:11 AM) Neither. The readme's litter the parent folder and they are html. http://lavag.org/old_files/monthly_02_2008/post-192-1202424621.png' target="_blank">

QUOTE(gmart @ Nov 26 2007, 08:36 AM) 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

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.

QUOTE(hviewlabs @ Nov 21 2007, 12:19 PM) 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

QUOTE(hviewlabs @ Nov 21 2007, 12:19 PM) 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