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]

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

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)

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

QUOTE(Tomi Maila @ Feb 7 2008, 10:11 AM)

Hi,

I need help from someone who happens to be using LabVIEW on a mac. What is the LabVIEW folder structure for OS X i.e. which folders are there under the LabVIEW installation folder. Especially is there a folder named readme like in Windows with readme files, or is this replaced with a folder named unix like on Linux?

Regards,

Tomi

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

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

Why is this an issue? Are you concerned with possible slowdows or memory usage?

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)

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)

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)

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

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

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)

I added a sequence structure around the listbox terminal and forced the dataflow, and that seems to have forced the Listbox terminal to read late enough that I get the "after" value every time. I tested it maybe 10 times.

http://forums.lavag.org/index.php?act=attach&type=post&id=6774''>http://forums.lavag.org/index.php?act=attach&type=post&id=6774'>http://forums.lavag.org/index.php?act=attach&type=post&id=6774

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)

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

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)

8.5? What happened to 8.3 and 8.4?

You didn't get them? They were great!