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

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.

Here's my Array Size.

This all reminds me of some code a hardware vendor supplied us many years ago. I've reproduced the style below. Creative(?!) use of the N terminal.

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.

OK, we just did some more testing. On my machine, it seems to always work as expected all the time. On my co-workers machine (where we first saw this problem) we are seeing that it sometimes works, sometimes not. Damn.

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.

http://arstechnica.com/articles/paedia/cpu...64-core-CPU.ars I'd like to see one of these in a cRIO controller. 64 cores, 4 DDR2 RAM controllers, 2 10Gbit Ethernet, 2 Gbit Ethernet and 2 4x PCIe interfaces. After all the multicore hoopla at NIWeek it would be great to see NI quickly demonstrate what LabVIEW can do on 64 cores.

QUOTE(Val Brown @ Aug 14 2007, 06:04 PM) 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

I think an Advanced Topics Day on Friday would be great. Plus it is an excuse to stay for Friday night on 6th street . 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

QUOTE(Gary Rubin @ Aug 3 2007, 08:44 AM) You didn't get them? They were great!