Now that the driver has been integrated into the āMCU-Stackā, the NEMA23 POWERSTAGE is much cleaner. The high side power trace for the FETs is now a almost uninterrupted plane. Furthermore, since there is no need for 12v wires for switching, because of the onboard buck converter, there is suddenly room for a extra electrolytic-capacitor, possibly two (one large per āphaseā and a smaller one just because). Getting closeā¦
Also, now that the external FET drivers are out off the way, there is better room for low side current limiting resistor and diode in front of the FETs.
Because there are various power voltages for cooling fans 5v / 12v / 24v I have decided to break out the fan power. The fan header/connector is still relevant because of the PWM speed control, which will adjust the cooling compared to measured heat/temperature development. If using a 5v cooling fan, it could be powered by the 5v USB power. It would then need jumpers from the USB headers to the fan PWR. I will try to break out the regulated 12v for testing on the fan while switching. A Noctua 60mm fan only uses like 0.1amp so in theory it will not drain the power too much. One concern, doing this, is if the 12v fans can handle the 15v the STSpin32G4 buck can output. Raising the switching voltage to 15v could lower the Rds(on) and thereby run the FETs cooler (if the gate can handle 15v).
I am tempted to run the 5V to the cooling fan and make it a closed solder bridge, in order for it to be possible to use 12v, but the 5v would be standard. @runger Du you think it will work, if the CAL_EN pin for the MT6835 was tied to a switch/button ? Hopefully the calibration is a onetime thing and the motor does not need to be mounted to perform it. Its actually a bit difficult to discern, by reading the datasheet, if the CAL_EN shall be toggled or held down?
Just realized that Noctua cooling fans can be controlled by 3.3v.
Edit: Although they probably can work with a 3.3v signal, somewhere I found a dude saying the PWM line is pulled up to 5V inside the FAN. So I am opting for a Schmitt-Trigger (level-shifter).
Note: Since running a stepper using FOC should keep everything cooler then normal (Not FOC), I still think it is a cool feature to have it available if pushing the motors for extended times.
Since this powerstage just as well can drive a 3phase BLDC (Push wire terminals are rated for 9amp), and now there is room for the 3th electrolytic (composite) capacitor, I will go ahead and place it. Keep in mind that they are not that large. They might seem large in this image, but in fact they are quite small (8mm diameter). The lifetime expectancy of capacitors is heavily reliant on how hard they are driven, so adding a 3th large cap will increase the overall lifetime of the other two caps, and will of course increase the overall system performance, especially when driving NEMA34s.
I have made a 2mm pitch header for the CAL_EN pin. This way one can wire the button if needed in some unthinkable scenario where you want to calibrate or re-calibrate the sensor while the motor is mounted on a machine, where it can be hard to access a small button. Naturally the belt or what ever drive train is used has to be taken off, if the motor needs to spin fast and freely during the calibration. One can also wire it to one of the available pins on the MCU stack, if one needs to calibrate often, for some strange reason. Hopefully it is just a onetime event.
Just been looking through this again. Although you a right, the order is different. MISO is channel 1. Was concerned they flipped the order on the two SPI channels, but its ok. Just have to use PD2 for ETR on the Port A SPI interface, since it not present on SCK. Since both SPI1 and SPI3 are present on the Port B interface, it would be nice if we keep that port SPI3 in the pin definitions. Otherwise it might crash with the SPI1 on Port A.
I have tried to mess around with the SlimStack. It is actually possible to have a SPI interface if the MT6835 is turned in one direction and ABZ if the sensor is turned the other direction, this without possibility for short-circuit. See below.
Edit: just checked the datasheet and there is a 250k pull-down on the CAL pin (internally). Further pull-down could be placed on the sensor breakout, so it does not interfere with the SPI lines if turned 180 degrees.
Ok, this is quite cool, but this is pretty confusing for the user, I thinkā¦
I think you have to be clear on the goals and make clear specifications, and then decide where to solve what.
The shared SPI/Encoder interface is something specific to the STSPIN32 module youāve made. It could be a design feature of other STM32s with similar pinouts, and I think also ESP32ā¦ but its unclear whether this could work with an NRF52 or SAMD based boardā¦
So I think this is a local problem to be solved locally on the MCU board, not by rotating the sensor.
In my mind the sensor should always connect in the same way, and since its easy to get these board to board connectors with many pins, why not use one with 10 or even more pins, and have standard pins for ABZ, SPI, UVW, error, calibrate, PWM, Analog, etcā¦ You could even add a pin called āIDā - which attaches to a small ROM on the sensor. Then the MCU board can read the ROM data via the ID pin, find out which sensor is attached with which protocol(s), and initialise itself accordingly.
But even without the nifty auto-detect, having a standard pinout with all the signals means the MCU can select the ones it needs, and for example on your STSPIN board you could either connect both SPI and ABZ to the two ports, or make one of the ports selectable between the two using a multiplexer or buffers with OE function.
Yes, well, I see your point regarding it being confusing for some, it will of course need a detailed explanation and clear and visible indications on the sensor and board. I have faith in the user
The thing is. One of the ports/sides will be routed to headers on the Powerstage. I need to limit the pin_count on those dual_row headers. So the SPI interface will be standard. If the user wants SPI and ABZ interface, thatās possible using jumber_wires from the Powerstage (ABZ output header) to the MCU stack. Pure ABZ is also possible if the user need the other SPI port for something else.
So if for example the ABZ interface is not on the SPI pins (like the STSpin32G4) if using a MCU stack with a different MCU, then the user has SPI as standard, but also the possibility to interface the ABZ.
Now the current sense amplifier INA241 from TI is finally available, I have made the jump. This makes the current sense part so much cleaner. Since it can survive 120v I will not place TVS diodes like with the MAX46056. I will still place a large (main) TVS close to the bulk capacitor. This sensor is a real upgrade compared to the MAX40056, although because it is so fast 1100 kHz, not all MCUs are able to read it. The ADC of the STSpin32G4 is fast, so there should be no problem with this combo.
Changed shunt resistors to larger 2010 package 4W rated. The INA241 I could get my hands on are the 10V/V (Gain) one. This means relatively high heat dissipation, but up to 5 amp should be OK, more then most NEMA23 can handle.
Edit: It is always tricky to set the shunt current range, because we want highest possible precision within the application specific parameters. That said, we can still have useful reading in the lower 50% if the result is in 14 or even better 16bit. This entails oversampling in the case of STspin32G4 since it āonlyā has 12bit native ADC resolution (ADC 4MSPS). Naturally we would like to get close to the wire terminal ratings (9amp), but that is far beyond the range of any NEMA23 even NEMA34 does not usually go that high. We also want some headroom for 3phase BLDC use, so 8 amp sense range is IMO a good tradeoff (8amp @48V = 384w). With that kind of power we can actually drive a small eBike (250w nominal in the EU).
For the uninformed: 12bit is 4096 resolution, 14bit is 16384, 16bit is 65.536, so even in the lower 50% range of 14bit we have a resolution of 4096 in both directions (current flow).
That leaves us with a 18mOhm shunt_resister (with additional margin to spare). Although maxing out the current on that resistor will dissipate 1.2W, which means it will start to get luke_warm.
Maybe 22mOhm is more appropriate for this kind of application ? @Valentine
Iād go for hall-based current sensors, cold 0R single chip, avoid all that mess with opamps, shunts, and overheating. Each shunt has more resistance that the mosfets they are measuring themselves. Whatās the point of spending so much time picking a nice low R mosfet then throwing up all over with a shunt.
Its not comparable, since the MOSFETS RDs(ON) is turn_on resistance not resistance in the shunt_sense. In a sense you can say, that the shunt will not dissipate the energie calculated by Ohm, since we PWM the current, like the gate resistor does not overheat.
Just contemplating why one would have separate MCU power from Analog power. Then it hit me, since the digital power may radiate unwanted noise, hawing the Analog Power separate and filtered with appropriate caps, may improve the analog domain. Just some random thoughts I wanted to share.
Regarding the Inductor for the Buck converter, there are some hmmā¦ not so specific info in the ST reference design (BOM). In the schematic it clearly says 18uH inductor, while the BOM list a 15uH inductor, so im trying out the 15uH just because it has higher current rating. I guess the buck converter will try to maintain / hit the target voltage no matter what, and adjust the switching accordingly.
All components has been ordered. Working on a small combined panel. Lets do this !
Good thing to always be patient when designing circuit boards. There always seem to pop errors up here and there. By completing the CUBE_MX project I found it is necessary to move the NEOPIX LED pin to PA10 on TIM2. Hawing that LED on a separate timer is crucial to make it work on STM, since those LEDs need a 800kHz PWM signal.
Found room for a small Switch for the RESET pin, this way the DAC1 pin can be routed to the pin_header row. Not sure when to use the DAC in a motor controller, but maybe it is useful for some arbitrary purpose. That pin can also be Analog input, or perhaps function as a step/dir input.
Im not using all the pins on the STSPIN32G4, so those not in use is marked Z. Pins marked X is not available on the STSPIN32G4 (Combined MCU and 3phase driver).
Which code are you using? Is there a STM32 timer-based Neo-pixel driver? Iād be interested!
The NeoPixelās annoying 1 wire protocol works at 800kHz, but the encoding is based on varying the duty cycle to encode the bits. This is non-trivial to implement with timers, which is why I think many drivers use the SPI peripherals (which naturally have the ability to shift out data bit-wise onto pulses) to emulate this encoding.
Although annoying they are quite powerful RGB diodes. Signaling or some low level HMI is suddenly quite simple. Red = Error! Something is wrong. Off = saving power when everything is OK. Green Blink = Got it! Message received. Blue = ? (not sure)
But unless you plan to implement that code into your firmware, I would check how one of the common Arduino Libraries does it: Adafruit NeoPixel (the standard) or FastLED come to mind, but there are othersā¦ might turn out they need a timer, but might also be they want an SPI pinā¦
They also give the RGBW LED sample. Pretty neat IMO. Maybe the white could be like constant ambient on light, set to 20% intensity or what ever the user want I guess. Some folks like it when they change color like RGB ledĀ“s on RAM blocks.
