Electronics > Projects, Designs, and Technical Stuff
Best way to design and control parallelable DC/DC stages
(1/1)
Miyuki:
Hi folks,
Want to ask if someone try to do something like this:
Isolated DC/DC stage 110V to Positive and Negative 400V rail
Simple parallelable units, just connect booth power sides and link them with some sync link and have possibility to run run just one or "infinite" on desired power output
Thinking about two possible ways:
1) "simple" old fashioned analog way, current mode control, with one module will be master with feedback loop, and will feed error signal to other units as just voltage level. And all units will just run its cycle by cycle current mode from this signal.
Possible problems I see at induced noise and big question is about synchronization - switching all units at one, free running clocks or some way of inducing phase shift between them
2) complete digital control, with all units connected with CAN bus (or something like it) - this can bring lot of features, stand by modes, better regulation
But software solution can be tricky to make stable and robust, communication glitches and software bugs can be hidden
T3sl4co1l:
You can do whatever you want, but #1 must be the primary underlying architecture. To do otherwise is foolhardy. (Consider FMEA.) But since that accomplishes the purpose of #2, there's not really much point in implementing more, is there? :-//
CAN would be an excellent choice for distributing ancillary data -- temperatures, voltage and current readings, general health status sorts of things. Tweaking of calibration data, perhaps; but never something that can be set outside of a safe range. For example, a gain factor might be used as 1 + (GAIN_REGISTER / 655360), for a 16 bit signed register value.
None of these are to be depended upon for operation, of course: each module needs its own internal temperature and current and voltage monitoring and all that.
This airs heavily on the side of safety. The root of my concern is that all software is wrong.* While software can be made very carefully, and can even be made provably correct, it is the exception rather than the rule. It's not apparent what level of care might apply here, so I'm assuming the worst.
(*Properly attributed: "Hardware eventually fails. Software eventually works." - Michael Hartung)
So, that goes for microcontrollers embedded in the modules or controller, communications devices, control computers, the whole thing.
I suppose it's curious I leave out hardware design; I personally take great care in my work, so I often overlook this. It's no less critical, of course. Hardware has the advantage that, when designed properly, the possible number of states can be minimized, and probed with relative ease.
In any real software project, exploring the state space is ludicrously impossible. For example, the ~kB of RAM and registers of an ATtiny, giving 2^1000s of total states; which, even if almost all of those states can be disregarded as degenerate states (e.g., the program doesn't -- or, at least, shouldn't -- care if an unused IO register has any random value in it), there's still trillions and trillions of states left to worry about. Software must be written to minimize this count. Put another way, it's the consideration of edge cases, the purity of functions, execution path complexity, all those things and more.
So, all that said: depending on how much confidence you have in that communication link, you might pull some other functions inside the link as well, but pay extra attention to the reliability of the link in that case. There may be some value in a more real-time protocol than CAN (my understanding is CAN silently corrects packet errors, which would be a good warning signal that each module may want to respond to.
Tim
David Hess:
As I recall, current mode control allows the transconductance outputs of the separate error amplifiers which is commonly available as the compensation pin to be connected in parallel together enforcing current sharing which is simple enough.
Average current control is also possible but I do not think it would be as simple to implement and typically only older switching controllers have it built in anyway.
Some switching controllers allow easy injection locking of their internal oscillator which provides an easy way to synchronize all of the clocks.
Navigation
[0] Message Index
Go to full version