Why all the whinging about a mere 10ms or so to get the output under control? No doubt you're all hardware engineers who don't understand the extreme complexity and difficulties the firmware system has to deal with!
A 10ms spike is enough to kill your circuit which is why decent power supplies don't show this behaviour! It doesn't matter how difficult it is to get right, it simply must be right. You have to be able to rely on a power supply to do what you want and not push random voltages/currents into your circuit.
Apologies I should have made it clear that I was trying to be satirical. You're absolutely right - this behaviour is not acceptable at this price point.
I thought that post was sarcasm. 
Also don't be so hasty, that PSU could make a pretty ok car battery charger 
Integrating a unique new, state of the art, high-reliabilty RTOS, engineered for optimised PSU functionality, developed using a cutting-edge customised Agile based methodology helps manage the complexity of the large software development to minimise the distractions of constant inter-team interactive incompatibility disagreements, such as memory and CPU resource allocations, which plague traditional homogenous software developments.
WOW.... I am shocked by this management speak. Did not expect this here.
Oh god did that seem remotely plausible? I hate such buzz-word marketing w**kery word soup! "Output Fusion"? Beam us out of here Scottie please!
I was musing on a possible scenario on what went wrong with this design whereby there was too much design at too high a level - design by committee perhaps - rather than having an experienced PSU engineer having tight control of the critical performance and behaviour aspects of the design who would dictate and micro-mange the implementation (if necessary) of the control algorithms whether in hardware or software and would specify the detailed test process to verify the design. The fact that Dave uncovered this failure so readily (after, what only 3 tests?) shows that this didn't happen properly.
Perhaps the seperation of the HW and FW/SW teams was too complete, possibly even done at different sites or even in different countries. Big problems can arise if there is no clear engineering expert lead in overall charge of both groups, but only a product manager, possibly more concerned with the marketing issues trying to co-ordinate the two groups who may have differing aims and drivers.
For example, a new SW lead is hired because of their expertise in the latest SW development fad of the day which has seduced senior management as being the siver bullet they're hoping for. The old dinosaur engineers in the team who cut their teeth in assembler language who have hard real-time in their DNA get overuled by brash young programmers who don't have a clue what a PSU actually is but do know all the latest buzz words and want the flavour of the month programming languages, SW architectures and paradigms to populate their CVs - regardless of how well suited it is to the current project.
The project complexity rapidly spirals upwards until nobody can be absolutely certain of the low level hard real time behaviour - especially when layer upon layers of third party binary libraries are included whose memory and timing behaviour are poorly understood - hence the bizarre sight of a 550MHz processor with 256MB of Flash and 128MB DRAM being used to control a two channel PSU! Yes I know those parts aren't expensive and it's likely about having a core processing solution for a wide range of products, but if they'd only had a 64KB STM32 with 32K of RAM, the SW architecture would likely have been simple enough that it's critical pathways could be easily understood to guarantee they meet the specs, unlike the Java based garbage-collecting monstrosity (or whatever) they actually produced because, well because they could!
And yes I also fully understand that underspecifying the processor/memory can also lead to failure due to excessive complexities due to the resulting extreme optimizations needed. And that some engineers get called dinosaurs because they pretty much are.
-------
I'm not saying any of the above is remotely connected to this PSU's problem. I think Kleinstein could well be right that the main control loops are analog , although the processor is plenty fast enough and fast ADCs and DACs are fairly cheap now. What bandwidth would the control loop need for a typical PSU of this class need? 2 or 3MHz?
However the output enable overcurrent behaviour is so bizarre and slow that it has to be SW issue surely? Which means it's probably fixable. I'm guessing this overcurrent problem is related only to the rather odd output enable behaviour. I'm assuming 'EasyRamp' was disabled and that someone decided that a default slow ramp up was desirable despite the fact that traditionally the enable switch provides instant on. As such the over current control behaviour likely relates only to this transitory mode after which a properly functioning overcurrent control is enabled. We won't know until someone does some dynamic load testing. The spikes in CC mode when changing voltage may be something different again.
The interesting question is how did this problem survive into delivered product when Dave found it so easily and as several have stated here that they consider it such a serious defect that they would not consider buying it. We'll probably never know of course, but here are a few thoughts:
1) The CC mode behaviour at output enable time was not tested because CC mode testing was comprehensively done by dynamic load testing after startup and nobody involved in that testing were aware that the control strategy was different for a short period after the output is enabled. Perhaps being experts in the analog domain it simply didn't occur to them that the SW team would choose to override the normal O/C control when enabling the output and didn't think to check.
2) Much worse, they knew about this but didn't consider it important for some reason - which could arise where the subject domain experts don't have sufficient clout with non-technical management (much like various governments' responses to 'expert recommendation' in the covid crisis).
3) They discovered it late in the development but decided to release anyway gambling that most users would never find out or even care, which might be true for customers using them in industrial test situations who only the remote control interfaces.
4) Farming out the development to a team or subsidary without specific PSU design expertise, providing PSU expertise in a consultancy role, but not being in full control of the project. This could arise from mangement considering that SW is becoming an increasingly dominant part of the total development budgets and thus the focus is changed to being a primarily SW based company with specialized HW/domain support for each product class. The SW teams then call the shots and the HW/subject experts don't get sufficient access to find the problems early enough.
Or many more possible reasons.
Why all the whinging about a mere 10ms or so to get the output under control? No doubt you're all hardware engineers who don't understand the extreme complexity and difficulties the firmware system has to deal with!
Honestly, I agree. With all PSUs I'm always considerate of where I set my CV setting is, and some PSUs are not suitable for powering sensitive circuits. BUT:
Here's a quote from your website: "Confidently power sensitive circuits" "Supplying extremely stable output voltage and current is crucial when powering sensitive components."
At this point you're putting your foot in your mouth somewhat fierce.
Integrating a unique new, state of the art, high-reliabilty RTOS, engineered for optimised PSU functionality, developed using a cutting-edge customised Agile based methodology helps manage the complexity of the large software development to minimise the distractions of constant inter-team interactive incompatibility disagreements, such as memory and CPU resource allocations, which plague traditional homogenous software developments.
For example, this allowed the Wuppertal team to develop the overcurrent detection module, largely decoupled from the Stuttgart team developing the event management and distribution module, the Taipei team responsible for output current control functionality (with 1uV resolution), the event logging object oriented distributed database team etc, and the somewhat undervalued 'Output Fusion' team. (Oddly, nobody seems to be able to recall where they are based).
Problem in search of a solution. In any case, this is an implementation detail.
With round-robin 1ms scheduling, 10ms response is actually world class leading especially given the need for triple checking the over current event is not a false noise abberation. And whilst the 550MHz processor might appear to be overkill, consider that as the PSU could be used in safety crtical situations it needs to be fully MISRA compliant - appreciate how long it takes to do a full memory test of the hardware (including 256MB of Flash and 128MB DRAM) to be certain the overcurrent event wasn't due to a mains glitch or similar.
I don't think anybody is complaining about the hardware. But again, implementation detail. You're advertising a PSU for sensitive circuits. Do better.
Once again my sincere apologies for not making it clear in my original post that it was a mixture of satire and sarcasm. The fact that someone appears to have mistook my post for an official R&S company communication shocked me and shows how low our expectations have sunk that we can't easily differentiate between company marketing speak and the total drivel, buzz word soup I posted - believing it was obviously so. Lesson humbly learned.
Home
Help
Search
Login
Register
