Jump to content

Totally not LabVIEW Related, but still crazy interesting


Recommended Posts

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? 

Link to comment
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.

Link to comment

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. 

Link to comment
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.

Link to comment

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.

Link to comment
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.

Link to comment

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 by HorseBattery_StapleGuy
Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...

Important Information

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