Hi John
What follows is longwinded, and may only make sense to (ex-)hardware technauts like myself. But you asked!
I don't think I gave enough data to fully comprehend the problem. Requirements restatement:
- simplicity
- robustness
- reliability
- self-diagnosis (less of an issue, but desirable)
- in all detected failure modes, device passes input to output unmodified (essential)
- input signals A and B and output signal X must all be 4-20 ma loop signals
Consider
Y = F(B)
X = A + Y
The root issue here is simplicity. For example, the simplest proposed solution (to date) is the following:
- convert A and B to 0 to 5 volt signals
- Digitize B
- Use the 16 bit quantity B to lookup Y in a table
- Convert Y to an analog signal, - 5 to 5 volts
- Sum A and Y in analog circuit; summing parameters such that the change in A is limited to the range min to max.
- convert X to ma
Obviously, if F(B) were linear, we lose the A/D and D/A transforms. Failure modes are critical in this application. We can limit the adjustment signal Y in hardware (beyond the DAC output) in the summing node to ensure that Y cannot change A by more than some limiting value. We can use a power-fail relay to route input-to-output to ensure that power-fail modes result in A->X unmodified (worst case). I can even see using mirror-imaged ROM's to implement a rudimentary checksum arrangement to self-fail on ROM mismatch, if we really need this much failsafe (if the failure modes of the self check outweigh the failure modes of the ROMs, this may self-defeat). Additional checks in hardware could be done by computing the difference between A and X and comparing this value to a pair of setpoints; if for some reason one of the setpoints is exceeded, the unit could self-fail.
All these things are possible.
Done. No processor required, just use a 16-bit A/D with parallel outputs and feed a ROM's address lines to get an appropriate value to convert to analog; do a little analog circuitry to add Y to A. Yes, some form of logic clocking may be required, but this isn't astrophysics. Yes, the lookup table needs to be generated offline and burned into ROM, but this is no big deal.
So why not do it in software? Well, simplicity. Period. KISS. Why do it in software?
Error checking, perhaps.
Ability to add integrity checks, perhaps.
Reputed simplicity of modification? Overrated, IMHO, and the required transform is not that mutable, as it's based on real physical hardware objects that don't change.
Need to employ software or hardware engineers with a few years left to retirement, NO (yours truly included).
If the self-diagnosis routines get too complex, the amount of hardware skyrockets, the cost climbs, and the software world gets more enticing. But maybe some form of processor could be piggybacked on the circuit for diagnosis, without allowing it to impact the direct signal path. Hmm - dubious, at best.
So give me a !valid! reason to involve software that outweighs the costs of a development program, in-house engineering, down-the-road support, succession planning, etc. etc. etc.
One internally-proposed solution so far has a PC, DAQ card, Windows, interface chassis, user interface, etc. etc. etc. Where the heck is the simplicity in that? Failure Rates? Reliability? Sure as heck not .99999, but right now I can't tell you what the reliability requirement is, just that a Windows-based solution would be laughed out of the room.
And that's why I flagged this message as severely OT - I don't see a whole lot of LabVIEW applicability, but there are a lot of sharp minds on this list, very few of which have blinders to a software-centric world. We may be underrating the complexity of the all-hardware solution, but so far I haven't heard the definitive "silver bullet" needed to kill it - I need to know if there is one.
Blair
