Totally not LabVIEW Related, but still crazy interesting

[Neil Pate]

https://meh.com/forum/topics/building-the-plane-on-the-way-up

tl;dr the ground based decoder for some of the comms on Voyager was built *after* the craft was launched, and it still to this day reliably receives data. Wow!

[bjustice]

The Voyager probes are truly amazing.

The "Pale Blue Dot", captured by Voyager 1, is perhaps the coolest picture ever taken.  Some cool facts on this from NASA:

https://solarsystem.nasa.gov/news/1175/10-things-you-might-not-know-about-voyagers-famous-pale-blue-dot-photo/

[ShaunR]

I wouldn't put 99.999% of any code written today on a satellite-and that includes my own.

Go back 20 years and I would swear by any code that was written would have zero bugs otherwise it would not have been published.

The reliance today on "updates" and "beta" versions  is a detriment to all software. It's like psychologists creating models of human behaviour  and expecting it to model real life...with updates.

Call me cynical but I think software robustness is a far-cry from what it used to be. But that's progress, right? 

[crossrulz]

11 hours ago, ShaunR said:

I wouldn't put 99.999% of any code written today on a satellite-and that includes my own.

Go back 20 years and I would swear by any code that was written would have zero bugs otherwise it would not have been published.

The reliance today on "updates" and "beta" versions  is a detriment to all software. It's like psychologists creating models of human behaviour  and expecting it to model real life...with updates.

Call me cynical but I think software robustness is a far-cry from what it used to be. But that's progress, right? 

Code is also orders of magnitude more complicated now than back then due to more computational power being available and therefore more features are possible.  More code just increases the probability of bugs.

 

About 15 years ago, I was peripherally involved on testing code for a $50k FPGA in a satellite.  The amount of testing that code went through was absolutely insane, including days of just Reed-Solomon test cases.

[Bryan]

I was never involved with it, where I used to work I supported a software group that wrote code for an automated military application.  I can't speak for other DoD contracting companies, but I know that they went through iteration after iteration of software testing, regression testing and debugging over the course of several months to a couple of years with testing "events" that would go around the clock for a couple of days at a time. 

My role was not with programming for that application, but I was responsible for maintenance and troubleshooting of the simulation testbed that they used to develop their software.  If they found undesirable behavior from their code, I worked with them to determine whether it was actually a bug or something wrong with the testbed. 

[mcduff]

On 7/12/2021 at 4:53 AM, crossrulz said:

Code is also orders of magnitude more complicated now than back then due to more computational power being available and therefore more features are possible.  More code just increases the probability of bugs.

 

About 15 years ago, I was peripherally involved on testing code for a $50k FPGA in a satellite.  The amount of testing that code went through was absolutely insane, including days of just Reed-Solomon test cases.

Don't disagree at all with the increase of computational power, but JPL has rules for code. I think having a set of rules helps to reduce possible errors.

[Wire Warrior]

Twenty years ago, I was lucky enough to write some servo code for an antenna pointing system on a satellite.  I spent years designing, testing, debugging that code.  It was burned into ROM just prior to shipment.  Those chips cost more than my salary for a year back then.  I had to get it perfect.  With all the time I spent with that code, I can still see the lines of assembly language in my sleep.  LOL

Code robustness on first release has dropped in a lot of fields because you can patch and update.  Nothing wrong with that necessarily as long as its not safety critical but I do believe programmers can benefit from being part of a project that has to be right the day it leaves their hands.

[EricLarsen]

On 7/15/2021 at 9:57 PM, mcduff said:

Don't disagree at all with the increase of computational power, but JPL has rules for code. I think having a set of rules helps to reduce possible errors.

It would be interesting if anyone has a similar document specific to Labview code.  NI has a style guide hanging around, it is useful but definitely not the same thing.

[HorseBattery_StapleGuy]

That's funny actually. I used to think this stuff didn't matter anymore until I was put in projects where that stuff is suddenly relevant. A lot of the stuff we make has to be right once they leave my hands. Otherwise its GG M8 try better next time.

For example in C I've had to pay attention to things I never paid attention to way back then, like sticking to memory with hard limits / avoiding dynamic memory. Not using recursion to not abuse the stack, etc. (Really low powered/cheap weak embedded chips) Upper bounds in execution, etc.

Or use different kinds of standards/guidelines for reference, like MISRA. Its actually surprisingly fun despite the limitations. But also tedious.

1 hour ago, EricLarsen said:

It would be interesting if anyone has a similar document specific to LabVIEW code.  NI has a style guide hanging around, it is useful but definitely not the same thing.

How would something like that look for LabVIEW though? I mean its compiled code but there's probably a big amount of heap usage / memory shenanigans going on under the hood that you probably can't avoid. (At least when programming for desktop)

 

Edited July 23, 2021 by HorseBattery_StapleGuy