Category Archives: Motor Controllers

Universal Motor Controller – Actuator Control System

I have a few electronic designs that annoy me simply because I lack time to work on them. The reason is simply to much happening in RL with projects (have to pay the bills) + focus on Software. This one is the worst. It is actually one of my most advanced designs and a very capable Actuator Control System.

I started this partly because I wanted to make my own 3-phase motor controller. But, as I did the design I also added a 4th Half-Bridge, Hall Sensors, Temperature Sensors, End point Sensors, Resolver input as well as the RS-X port. It is much better 3-phase motor controllers than this around, but that’s the point – this is not a motor controller it is a scalable Actuator Control System.

I

I blogged a lot about MicroPLC/Home Automation lately, and this design fit’s right into this scheme. We can’t use long wires with actuators involved as they need to be close to the objects they control (high currents). A centralized PLC design is not optional in a home that actually need distributed unit’s like this.

I will get down to it, but for now I want to focus on getting the HMI running. One of the first projects will be test applications for these devices.

The concept I will use is that the HMI Browser contact this device and upload the HMI. So all you install on the desktop, phone or tablet is a HMI Browser. This is similar to things you know from classic Web Browsers and HTML5, but the main difference is that we operate on a closed, industrial network consisting of a combination of technologies.

One aspect of easyIPC that I have not mentioned is that you have a set of HMI & devices that actually are a closed, industrial loop. It is not connected or available to internet or the outside world unless you want it to. Neither will you be able to connect any phone or tablet if it is on Wifi – the devices will need to be enabled from inside (white listed).

PLC Ethernet/GSM Revision 1.0 Annotated

These pictures show the annotated 3D. Full PDF documentation can be found on the Download page (here).

  1. 4 pin HMI header.
  2. Super capacitor for RTC.
  3. SWD.
  4. W5500
  5. Raspberry PI Zero W mounting holes.
  6. Ethernet RJ45
  7. GPS Antenna
  8. GSM/GPRS Antenna
  9. Nano SIM Card holder.
  10. Standard mounting holes. M2.5 in each corner.
  11. SIM808 module
  12. Analogue Audio/USB connector.
  13. 4V PSU (MIC29302BU)
  14. 2 x MAX3485 for RS485.
  15. STM32F405RG
  16. 3.3V PSU (LM1113)
  17. 40 pin PLC backbone connector
  18. 40 pin Raspberry PI 2/3/Zero W connector
  19. Audio/USB available on back side. 5V + VBUS available here.
  20. Test holes for PCM
  21. Extra wiring to enable swapping of PCN In/Out

PLC Backbone Block Diagram

Using STM32F405RG on everything is an overkill, but I can always consider dropping down to STM32F105RB/C later. This M4 gives us a powerfully MCU on each module capable of truly distributed processing as we are promoting in Plain.

Ethernet Module is what I have started on now. This will host a STM32F405RG, 2 RS-485’s for the backbone, a W5500 based Ethernet and optionally a ESP-12 module for wireless. I am also adding RTC battery, SPI flash and a SWD connector. I need to see what space I have available, but as with my previous Raspberry PI Hat’s I intend to re-use much of the MCU related design on every Board if pins & space allow it.

RS-X Module connect the 2 backbone lines to 3-4 isolated network lines. I want isolation on anything in & out of the PLC.

Mobile Phone module is for internet connectivity on remote places or as a secondary backup should a primary internet be cut. It exist so many small, low cost modules these days that we just grab one of those.

Battery Control Module is so we can connect a LIPO package to operate if mains fall out. This should also include charging and monitoring of the battery.

PSU Mains Module is basically PSU modules needed for 5V, 12V, 24V &48V.

Raspberry PI Module will allow us to interconnect with a Raspberry PI for computing, Ethernet, Wifi, USB, Bluetooth etc. The target here is Raspberry PI 2, 3 or Zero W.

Analogue Input Module is a x channel 16 or 24 bit ADC input module. This allow us to read analogue sensors with some accuracy. We need more than the internal 12 bit ADC, so I am thinking maybe a low cost 12 bit board and a bit more expensive 24bit board.

PWM Module is a x channel PWM output, each channel formed as a Half H-Bridge and supporting 2A continuous current. We probably should manage 8 channels – not shure.

Composite Camera Module. I am not sure about this board as I am tempted to use H.264 camera’s only in which case I will ditch this module.

Sound In/Out Module is basically targeting doorbell, but I am open for the possibility to provide a multi-channel music mixer as well. I need to consult with friends in the London music industry a bit, and it is possible this actually will be several boards to adapt to a stage show.

DC/Stepper Module will basically be very similar to the PWM module, but I probably need various currents & voltages for different motors. I am thinking only of small motors supported directly because I expect separate controllers for the larger motors.

3-Phase Motor controller – well, the name say it all, but I am not sure I want to make this board. The reason is because a 3-phase motor usually require some power that is better handled on a separate controller on the other side of an isolated RS-X. Let’s see…

Servo Controller is probably a 16 channel controller like we created before on a Hat, but I will be using Timer’s for PWM this time to get a 16-bit resolution on the PWM duty out.

As mentioned a few times before – this is an idea draft and I write it down to let it mature – plans will change.

New Micro PLC Backbone

My previous backbone board had to little space between connectors + no connection for PSU & communication – this one has 10mm between connectors which is more realistic – thought I still expect one Add-On board to use ca 20mm width. The total width “as is” is 100mm, so it is still very small.

I actually need to find a solution on the mechanical boxing before I finish this one + this is still only an idea draft that need to mature. I probably should add bias and terminator for RS485 on the backbone. Have some spare space on right.

As for add-on boards I am toying around with the following ideas;

  • An Ethernet connectivity board.
  • An RS-X connectivity board.
  • An Raspberry PI connectivity board.
  • An analogue input board.
  • A PWM channel board.
  • A camera input board.
  • A voice & mic board.
  • A DC-/Stepper- Motor board.
  • A 3-Phase motor board.
  • A GSM/3G/4G Board.

We can have a lot of fun here, but I will let these ideas mature a bit…

Universal Motor Controller

Finally got the PCB’s for the Universal Motor Controller, so we will have some fun the next days. Sadly I also instantly realise a few mistakes. The holes in the adapter board is to small for the capacitors I bought, but I can manage by using a small drill to widen some holes. Comparing the actual board with the 3D model is always a surprise. This board is smaller and tighter than I expected, so I am sure we will need to do some mechanical adjustments – but, well that’s part of the game.

Universal Motor Controller 1.1

I initally hoped to test rev 1.0 of this Controller back in february, but as often happens with hobby plans – they get delayed because of real life. I am still waiting for the PCB’s on 1.0, but I am already starting the planning for rev 1.1.

  • Testing the design on 11.1V battery.
  • Testing power and heat under full load.
  • Testing spike tolerance.
  • I am not fully happy with connectors, their size and location. Need to evaluate if we can improve this.
  • SWD needs to be moved/turned a little.
  • RS485 should be upgraded to galvanic isolated version. This is a challenge as I need physical space.
  • I am considering tilting the MCU 45 degrees left because a lot of PCB lanes would then be Shorter. It could save some Space.

I was considering 48V and more current, but the truth is that we then start moving towards specialized needs that is better handed as such due to the effects involved.

CAN or Ethernet is still an option. Despite having advocated CAN and written CAN stacks in the past – I am not a fan of CAN. RSX is better for many reasons. I would love Ethernet, but the truth is Ethernet wiring and need for switches is a drawback in robotics. I will consider an add-on option for communications, but I am actually happy with RSX because it is robust, flexible and easy. For now I assume I have to wait 1-2 weeks 🙁

Universal Motor Controller – rev 1.0

This is the front and back 3D model of the Rev 1.0 of my Universal Motor Controller. I will be leaving the non-isolated RS485 for now. I want to do some changes around the MCU layout later anyway as I actually have a lot of spare pins here, but lack space to support a com adapter. This board is 80 x 40mm and only 2-layer PCB with a lot of functionality.

Design doc is located on the Download page!

Universal Motor Controller – PSU

The HEXFET on my Universal Motor Controller is 30V, so I decided to change my existing DC-DC to 12V out and add a classing LM1117 for the 3.3V. The LMR14206 based DC-DC is basically so small that it is not much larger than LM1117 on PCB space. It is restricted to ca 800mA, but it will only drive the gate drivers, MCU and com etc so it should be sufficient.

I did find a few DC-DC converters with a different range on Voltage/Ampere, but they also use more PCB space. Jumper J5 and J11 allow 12V to be connected directly if your using 11.1V battery etc. The issue is that the Gate drivers need 10+ V to operate and as the DC-DC will drop 1-2V we might get a challenge using 11.1V LIPO batteries so I added the jumpers in case they are needed.

I would have loved to operate from 5V and up, but to do that I would need a very powerfully step-up DC-DC converter as we would feed the motors as well. It is doable, but it add to the size. We will be looking at optimizations later anyway.

This 2nd diagram is also part of the PSU and show the adapter connector as well as the P4SMA suppression diode from Vishay. This will break down around 27ich V and suppress any unwanted pulses. These diodes are life savers, but they take some time to react which is why you must add an adapter board with either a capacitor or battery. What will happen is that capacitors will take the edge of the pulse giving the suppression diode time to suppress the pulse. If you have a large capacitor or battery that will need tom be “filled up”, meaning that the diode will only react if the battery or capacitor is overrun.

If you recall my previous breakdown and discussion I concluded that a 24V motor can spike up into 20x (480V). The HEXFET’s will basically short those spikes and might be feeding them into the PSU part. A capacitor/battery can charge that energy, but we have a suppression diodes around to prevent that these spikes do damage. The basic adapter Board is only a specialzed vero Board to allow mounting of hole-through capacitors.

Universal Motor Controller

I designed this universal motor controller capable on driving DC-, Stepper-, BLDC- and even AC – motors earlier. The design parameters was 12-24V at 15A. This is quite a capable controller, but I did a mistake that limit the controller to 12-20V since I connected the Gate Drivers to the Motor PSU directly. To compensate for this I need to modify the design and implement a separate 12V PSU. As I correct this I also want to consider some additional changes.

I am considering is to replace the RS485 with an isolated RS485 due to the amount of energy involved. The 3rd change is Ethernet on a separate adapter board. Basically I want to copy the modules I use on the Universal Adapter as soon as I have tested them.

I am not sure about Ethernet. Ethernet sound nice due to the functionality, but it is a clumsy, 4-wire 1:1 solution. RS485 is slower, but it is a 2-wire network. It actually makes more sense having dual RS485 to be honest. CAN & Ethernet is easier to deal with using an adapter board- RS485 is considered a lower level of communication than CAN because CAN have protocols like CANopen, J1939 etc. The reality is that if we use RS-X that changes.

What I probably should do at some point is to create a “Ethernet” on top of RS-X by using a dual RS-X connection. But, that is fun for later…

So the modified design will be

  • STM32F405RG MCU, 168Mhz, 32bit M4, 1MbFlash, 192KbSRAM
  • 4 x separate half bridge drivers, 30V @15A
  • Current sensors on all
  • BEMF sensors
  • PSU Voltage Sensor
  • Separate 3.3V supercap to sustain MCU in power dips.
  • 3 x hall sensors
  • 2 x temperature sensors.
  • 1 x resolver
  • 2 x end sensors
  • 1-2 x RS485
  • Adapter board for battery/caps
  • Adapter board for CAN/Ethernet/Wifi

Applications

  • Solenoid driver
  • DC Motor driver
  • Stepper Motor Driver
  • Brushless 3-Phase motor driver