[AR] Re: LRE Test Stand Data Acquisition and Control Best Practices
- From: Henry Spencer <hspencer@xxxxxxxxxxxxx>
- To: Arocket List <arocket@xxxxxxxxxxxxx>
- Date: Thu, 12 Jan 2017 15:46:25 -0500 (EST)
On Thu, 12 Jan 2017, Graham Sortino wrote:
Regarding the suggestion of isolating DAQ and control circuits... while
I understand this in principle I have a bit of trouble understanding how
it works in practice. For example, say I have a thermocouple that
measures the engine external wall temperature. I'll want to use that
data for analytical purposes but also to shutoff the engine if it
detects the walls are above some threshold temperature. In order to do
this would I need 2 separate thermocouples (eg. one for DAQ and the
other for control)?
Ideally, yes. You might think your DAQ software is going to be simple and
can be written once and then left alone, but in practice DAQ is an area
you always seem to have to fix one more time to get a better look at
what's going on, and the result is that it changes a lot and breaks a lot.
Whereas you want controls to *really* be simple and written once and then
left alone. Which means you don't want to have the controls relying on
the constantly-changing often-broken DAQ software for essential data.
Firmly separating the two is an investment in lower blood pressure later.
Almost any design decision that makes iterating and testing and debugging
easier and quicker and more carefree is well worthwhile, because you will
have to do much more of it than you think. Rigorously separating things
that Must Work Right from less-critical things makes the less-critical
things much less risky to tinker with, and there are a lot more of them.
I am pretty much agnostic about hardware vs. software implementations of
the Must Work Right bits, except to note that simplicity and stability and
separation are harder to maintain in software, because changes and
complications are so much easier and more tempting!
Henry
Other related posts:
