My first P2 PCB (single axis servo)

I'm just about routing my first PCB with the P2. It's a single axis servo controller (to avoid confusion, I mean a brushless motor controller for use in CNC machines, not a model size servo used in RC cars or robots). The basic design was already there from my previous attempt with an ARM CPU. Replacing that with a P2 added a bit to part count and space due to added voltage regulators, EEPROM and passives. But it also greatly reduces routing complexity because pin assignment is far less constrained.

On the left side is the power stage and two big terminal connectors for AC power, motor and (abs) encoder. The left one of the pin headers goes to the power module (IGBTs) on the heatsink. The relay (K1) is for soft start. On the right side is the low voltage part with the big P2 chip in the middle. the small pin header left to it is for programming (prog plug) the big on the right for expansion (resolver, +/-10V command input). The connectors at the bottom side are for command input and (incremental) encoder. On the right side are terminals for low voltage power supply (24V) and cooling fan.
1093 x 874 - 129K
«1

Comments

  • Sheet metal case with extruded heat sink...
    dimensions: heatsink 100x100mm, PCB 100x80mm
    1151 x 869 - 63K
    1263 x 722 - 56K
  • Very compact. Is that just two layers only? That's a tough job if so.

    You might want to get an idea of power needed and temperature management of the prop2 as well. I'm assuming you'll be pushing the MHz for max maths performance. If some of that air flow circulates past the prop2 area then that would be good for it.

    Here's a table of some test loops using both one and eight cogs and the amount of VDD current needed - https://forums.parallax.com/discussion/comment/1482622/#Comment_1482622 Pgm0 is simple cogexec, pgm1 is lots of WAITX's, pgm2 is the cordic unrealistically maxed out, pgm3 is same but with hubRAM bandwidth also maxed out, pgm4 and 5 are similar to pgm0 but in hubexec with different extremes of hubRAM bandwidth.

  • The board has 4 layers. I've just hidden the inner layers in the picture to avoid "visual overload". I have lots of voltage regulators on board:

    1) switching regulator 24V to 5.3V, 600mA max
    2) linear LDO 5.3 to 3.3V for P2 digital VIO and expansion (<100mA expected)
    3) switching regulator 24V to 5.0V 200mA max for encoder, ModBus and command interface (P2 stays alive if this one is shorted)
    4) linear LDO 5.3 to 3.3V for P2 analogue VIO (<100mA)
    5) switching regulator 5.3 to 1.8V for P2 VDD, 2A max
    6) linear LDO 5.3V to 5.0V for current sensors (~30mA)

    and on the AC side:
    7) switching regulator 320V to 14V for IGBT gate drivers
    8) linear regulator 14 to 5V for slave CPU and optoisolators

    I think the P2 will not be loaded to anything near 1A. Single axis PID and a bit park transformation should be pretty boring for it. Everything can be handled with smartpins, streamer and cordic unit. There's not much actual math work to do for the CPU. I just want to try out what is required and scale it up if it also could be done for 6 axes simultanously. With the multi axis project I'll probably come close to the limit...
  • Sounds good.
  • Here is the preliminary schematic, at least the P2 with supply, EPROM and analogue front end.

    Don't mind the odd signal names (USART, SSC, TC and so on...) they are remainings of the older ARM design. I was just too lazy to delete them.

    I hope I've connected the EEPROM and supply correctly. Please tell me if you find a problem. I know, the XI/XO is rated for 10..20MHz. I just have some 25M crystals in stock and use them for the prototype. Can be changed to 20M later if necessary.
  • rosco_pcrosco_pc Posts: 379
    edited 2019-12-18 - 11:09:26
    One thing: from the pcb view it looks like you have a solid patch of copper under the P2. it was suggested not to have a solid pcb patch below the p2, but interspersed with vias in a specific grid. I can not find the discussion anymore, but look at what @Peter Jakacki did with P2D2
  • Routing is not finished yet. The red area you see is the copper pad how it is defined in the package. I'll add a grid of vias for thermal and electrical connection to the ground plane similar to those in the picture of the P2D2 from Peter.
    bc4a3887e5857543d5c3cc166cde5e.jpg

    Doing the solder stop and paste mask for exposed pad QFN or QFP boards is always a bit "vodoo" science. If too little paste gets printed on the exposed pad or if there are too many or too big vias then the molten solder will drain into the via holes. If there's too much paste then the chip will swim on it and possibly not all of the gull wing pins will solder correctly.

    I've made good experience with having around half the copper surface open in the paste stencil. It's a prototype... If the amount of paste is wrong I could adjust the stencil later.
  • Thermal vias for the exposed pad and power distribution for VIO and VDD is done. I put a ring around the ePad for VDD like Peter did. A solid ground plane is on the top inner layer and 3.3V is on the bottom inner layer.

    There are two bypass capacitors for VDD and two for VIO at each edge adding up to 16 altogether. I think that should be enough.
    862 x 792 - 40K
  • The postal service was busy during christmas but I finally got my P2 samples, today. :-D So I immediately started to assemble the boards...
    1024 x 1365 - 276K
    1024 x 1365 - 261K
    1620 x 1024 - 316K
  • Nice Board! How did the thermals work out?
  • What do you mean with "thermals"? The vias in the ground plane below the P2?
  • PublisonPublison Posts: 11,432
    edited 2020-01-04 - 19:39:33
    ManAtWork wrote: »
    What do you mean with "thermals"? The vias in the ground plane below the P2?

    Sorry, meant vias.

  • Who did you order the PCBs from?
  • Nice pcb :)
  • Well done! Especially since you are dealing with mains and high currents! How are your open-loop current sensors arranged and connected? I can only count 2 header pins per sensor. Are you sharing any parts of the schematic for us more curious ones?

    I also notice that in your pick'n'place that there were a lot of caps that weren't sitting on both pads. I take it that you did a final alignment but I find that a photo after the alignment is more useful for when things go awry after reflow.
  • Publison wrote: »
    Nice Board! How did the thermals work out?

    I can only say that soldering worked well. To tell wether the thermal connection of the P2 case to the ground plane is good I'd need an X-ray machine. But I'm optimistic. If the HAL is done well and there's not too much solder paste so that the chip swims or there are side balls then everything should be fine.
    Who did you order the PCBs from?

    I order prototype boards from jlcpcb.com (if it's not urgent). They are cheap and have a nice online gerber preview so you can spot the most obvious errors before ordering. Production boards and urgent prototypes I buy at multipcb.de. They have better process quality (drill alignment, trace width and copper layer thickness tolerances).

    Well done! Especially since you are dealing with mains and high currents! How are your open-loop current sensors arranged and connected? I can only count 2 header pins per sensor. Are you sharing any parts of the schematic for us more curious ones?
    The current sensors are IC1 to IC3 and have nothing to do with the header pins. If you look carefully you can see the isolation barrier shining through as a bit brighter "trench" across the board from the relay at the bottom left to the 6-pin header on the top right.
    I also notice that in your pick'n'place that there were a lot of caps that weren't sitting on both pads. I take it that you did a final alignment but I find that a photo after the alignment is more useful for when things go awry after reflow.

    Yes, this was caused by my sloppiness. Normally, when I assemble two sided boards I have to make a support structure to place the top side. I was too lazy for only 2 boards so the PCB tilted and clattered sitting unevenly on the already placed bottom side components. That caused the misalignment. But the reflow-soldering process is very forgiving. If all paste dabs are touched somehow capillar force of the melting tin will re-align the not too heavy components automatically. I only had to manually re-align two or three caps.
  • I still think you were very lucky with those caps if you left them that way. Quite a few didn't even seem to be touching the other pad.

    I was looking at the final pcb but I just glanced at the pcb artwork and those sensors do seem to go to 0.1" header pins. Am I wrong?
  • ManAtWorkManAtWork Posts: 724
    edited 2020-01-07 - 09:24:03
    For those who are interested, this is the schematic of the power stage. The pin 2x12 array on the left side of the PCB goes to the IGBT module (MOD IGBT in the schematic). It holds 7 IGBTs directly attached to the heatsink.

    The smaller 1x5 and 2x3 pin headers are for programming of the P2 and the HV-side slave processor (IC21). The 2x12 pin header on the right side is for extensions (resolver and tacho analog front end). The 3-pin header on the top right is for the cooling fan.
  • The first smoke test was sucessful (no smoke). All voltage regulators work as expected. I also ran a small test program that sets the clock mode to PLL and blinks an LED. It didn't work the first time with my own opto-isolated prog plug. I double checked all supply and programming pins, then I tried again with the original Parallax prog plug. This time it worked. It seems that the P2 uses a higher baud rate than the P1 which upsets my progplug.
  • I was looking at the final pcb but I just glanced at the pcb artwork and those sensors do seem to go to 0.1" header pins. Am I wrong?

    Ah OK, I know what you mean. Yes, pins 7 to 12 of the sensor are connected to two pins of the header. This is the center tap of one IGBT half bridge. The IGBTs sit on a separate aluminium core PCB on the heatsink below the main board. Pins 1 to 6 of the sensor go to the motor terminal via the inner layer. Remember, it's a 4 layer board.
    917 x 680 - 85K
    1024 x 941 - 117K
  • It has been quiet here for a while so I'm posting a quick update. I recently achieved some progress but it's mainly invisible internal stuff that's not (yet) suited to make a impressive demo...

    * Full duplex UART communication between P2 and slave processor is running now at 10MBd

    * CRC generation and verification sorted out

    * Timeout and re-connection supported (power stage could be switched off at any time)

    * 3-phase PWM is working

    * Clock synchronisation between PWM (slave CPU) and ADC cycle (P2) is working. This is done with a PD control loop in software which compares packet reception times against PWM counter phase and tunes the PWM frequency accordingly. There is no hardware link between the clocks. The P2 runs on a crystal and the ARM has a built in calibrated RC oscillator that can drift about 0.5% or something.

    * A/D conversion of the current sensor signals works with auto-calibration

    * Measurement of DC bus voltage and temperature works. Temperature measurement required quite some math. The (cheap) NTC I used is non-linear and requires 3rd order polynomial approxximation to get nice linear readings.

    * Park transformation and inverse transformation works

    * PID control calculations are implemented and tested to some degree

    * Parameter storing in the boot flash rom is working

    * Interface for optical absolute encoders is working (Tamagawa and SanyoDenki serial protocol, 2.5MBd RS485)
  • The next thing I have to do is implementing a command line interpreter and an interface to my tuning and diagnosis software. The I can tune the PID loops and debug in realtime with the scope display. The picture shows the software written for the older P1 servo. The bandwidth was quite limited. With the P2 I can probably display multiple scope traces with higher resolution.
    1046 x 683 - 26K
  • First test run completed!

    It still runs open-loop (without encoder feedback and velocity control loop) and only with 48V power supply. But at least it demonstrates that the slave processor for PWM, the power stage and the park transformation is working.
  • Nice!
  • cgracey wrote: »
    Nice!

    That is a thing of beauty!

    But I'm a bit weird :lol:

    Great job Nicolas 👍👍👍😎
  • Thanks. :blush:

    BTW, I'm currently porting all the code that that is dedicated to this project to C. I try to keep the part of the code that could also be used for other purposes (encoder drivers) in Spin. Any objections? (For the case that I make it opensource, later)
  • Ok, the command interpreter is working, at least the most basic commands for changing, loading and saving parameters. I had some struggles with the C compiler but it was partly caused by my own ignorance and partly by missing documentation.

    It's amazing, the P2 can deal with two serial connections, one for debugging (230kBd) and one for the scope and monitor (1MBd RS485) and all that in a single cog. I also learned how to talk to an FTDI USB device directly. Those VCP drivers and especially the handling of COM ports in Windows suck!

    I hope I can finish the scope software soon so I can go back to the actual task: programming the propeller.
    773 x 323 - 9K
  • That's looking good, ManAtWork. Sounds like you are not running out of cogs, yet.

    Years ago, I tried to use the VCP driver for the FTDI chips and was like a brick wall. How do you talk to the FTDI USB directly?
  • The last version of the servo drive used up all cogs of the P1:
    1 cog for command interpreter (user interface for tuning + scope)
    3 cogs for current PID control loop
    (6 counters required for ADC and PWM, many multiplications also used up almost all the computing power of those 3 cogs)
    1 cog for velocity and position PID loop
    1 cog to handle encoder or resolver feedback
    1 cog to handle command input
    1 cog for serial communication (either debugging or user interface, both at the same time was not possible)

    Now with the P2 it's like this:
    1 cog for command interpreter
    1 single cog for current control (cordic unit is extremely useful and reduces computing time to a few µs)
    1 single cog for two serial ports (user interface + debugging)
    3 cogs for vel+pos loop, command input, feedback

    If I ran out of cogs I could even run the vel+pos control loop in an interrupt of the interpreter cog. Feedback and command input could surely be done in a single cog, too. But as long as I have enough cogs I leave it that way because it's more flexible. I can simply swap out objects to handle different types of encoders, for example.
  • cgracey wrote: »
    Years ago, I tried to use the VCP driver for the FTDI chips and was like a brick wall. How do you talk to the FTDI USB directly?

    I use the ftd2xx driver. You have to check the "Load D2XX Driver" option in the FT programming utility. Then no VCP driver is loaded when the device is connected to USB. You can then use the ftd2xx.dll to talk to the device directly. It's possible to open a connection by name (string descriptor programmed into the FTDI EEPROM) instead of port number. So you don't have to scan all ports to find the right device.

    BTW, the propeller tool handles COM ports quite well. I always had problems providing correct timeout handling in my own software. I used to take an open source library (ctblib) but it no longer works reliably with Windows10. COM ports above COM10 are treated differently and are no longer found on all PCs.
Sign In or Register to comment.