EE Student here who recently finished the classical control theory class. I was wondering the process of how the industry or anyone goes from drawing block diagrams to actually implementing in hardware. For example, I'm trying to design a system that keeps a battery from reaching a threshold temperature without having the battery reduce its power output. I'm having trouble visualizing how I will go from a PID controller in theory to the actual hardware system.

  • \$\begingroup\$ How do you normally cool things? \$\endgroup\$ – Chu Jul 28 '19 at 8:13
  • \$\begingroup\$ Start by showing your block diagram. \$\endgroup\$ – Andy aka Jul 28 '19 at 11:13
  • \$\begingroup\$ Questions here must be specifically answerable; this is not. Your topic belongs in a discussion forum rather than here. \$\endgroup\$ – Chris Stratton Jul 28 '19 at 13:12
  • \$\begingroup\$ That logic is so flawed, 99% of the time there are many ways to solve a problem. Its up to the reader to filter all the inputs and take what they want from it. \$\endgroup\$ – Sorenp Jul 28 '19 at 13:16

I used to have the same feeling when I were introduced to control systems. We always worked on this perfect little DC motor with a nicely made test bench with good sensors etc.

Implementing the hardware is usually, drivers (high/low side), communication protocols, sensors networks, this isn't really the worst thing.

Always research your options https://www.electronicdesign.com/electromechanical/add-simple-temperature-monitoring-battery-management-systems

So my way to go about this -

  1. Identify your sensors and actuators. (Learn all you can about them most important step!!)
  2. Identify your system. (disturbances, integrating influences, unlinearities etc.)
  3. Choose a proper control scheme. (Fuzzy logic, cascaded, MIMO etc.)
  4. Draw a block diagram. (then think about the system as a whole and redraw it 10 times)
  5. Implement and tune accordingly.

That's the quick and dirty, as you gain experience you will start to look at more advanced things, such as the influence of clock jitter, automatic gain scheduleing etc.

|improve this answer|||||
  • 1
    \$\begingroup\$ First thing is to list all the functionalities you want, deciding to add one at the end of the process is fatal... \$\endgroup\$ – Solar Mike Jul 28 '19 at 7:58
  • \$\begingroup\$ There is some good stuff here, so it is unfair to mark this as wrong or not useful, but the design process normally starts with requirements. \$\endgroup\$ – Mattman944 Jul 28 '19 at 13:09
  • \$\begingroup\$ This is why we do not allow broad question on stack exchange, but only questions which can be specifically answered. This question cannot be. \$\endgroup\$ – Chris Stratton Jul 28 '19 at 13:11

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.