Some thought about usability, installation, ergonomics
Opened this issue · 20 comments
Albeit the height of the driver card is relatively small the issue to me is the how to bend cables vertically.
So I came with idea to rotate the driver, exposing motor port to the right side. Why? as on this side there are motror supply voltage pins.
This way the cables came from the side, easier for installation and tying them.
As for start, I did checking the most complicated (to me) circuit, ie. 2130. nd that is how it looks.
No components bodies rendered as I wanted to show you how the power tracke look like.
BTW, what do you think about changing TMC from C328952 to C465947, i.e. QFN-36_EP_5.0x6.0x0.5P package?
One issue with this approach is the airflow. The drivers are designed for horizontal airflow like this:
The connectors would block the air path.
Fair enough.
My proposal comes from the idea of mounting single fanon top of teh enclousere, over the the board with cards. Larger one, like 80x80x15 to make it quiet.
BTW. Any reason to have such a strong air flow? Typical stepsticks with 2209 works fine with small heatsink and one single fan far away from them.
You can make an alternate PCB layout. I don't know how to have 2 PCBs on a single schematics, but it should be possible.
Actually started working on that. Some big reconstruction.
Assumption:
- 8 DRV cards,
- limit board size, to fit into cheap 6 layer PCB
Thus I did a spit of the controller board into two parts:
1- main with all connectors but the PCIex slots, to minimize size I put SMD components on back side, added DCDC buck converter using TDS5430, but.. .thinink about replacing cpu with 144 pin version, as...
2- PCI slots carrier, with 8 slots
Both are to be connected using 50 pin IDC ribbon cable.
Status:
- Carrier board routing completed, but I am still thinking into removal of screw terminal and pass the V_motors through several IDC pins. Board sIze is 95x80
- Controller part: componnets placement alomst finished, power routing completed, some other as wel but stil hudrets of tracks to place. Board sIze is 100x86
So as for now I am using orginal sub schematics, thus only 6 PCI will be used.
When completed and concept confrimed, I will start to reorganize the main board to use stm32f427 variance. More power, but also 8 PCIex. To do so, I will need to remove EXP1/2 connectors, leave only TFT for screen conenction and integrate the ESP-12 module directly on board. Quite a challanging but I like challanges :)
So I have put 144 pin STM32F429 chip.
Routing is not completed, as I had to remap almost all signalling pins. I would say I am in teh miidle of teh way, having almost completed routing of those pins that uses STM32 peripherials, so general GPIO ones are left.
But during working on that following questions arise:
- The ST_ALARM signals from different boards can be mapped to particluar endstop. But what is the reason for ALARM1 input? How FW shall handle that?
- Purpose of the CLOCK dignal towards the driver cards, what is a gain if TMC uses internal or external clock?
- Any reason to use 74HCT04 to drive Mosfets if Vds = 1.7V?
Also please notice the RJ footprint & 3d model.
I will push changes towards main branch with proper footprint for Wurth socket and make the decoupling R&C no more optional.
ST_ALARM was supposed to be a single line where all steppers can signal a stall (or other alarm condition) and the SF would interrogate each driver to determine the cause. This is all well in theory, but in practice Marlin does not support this (AFAIK).
TMC2130 drivers do not work for me without supplying a CLOCK signal. I'm not sure what the cause of this is the datasheet states they should be able to work with internal clock, but alas that is not the case. This was also an issue with PrntrBoardV1 with TMC2130 drivers. I don't know if this is only related to the tqfp package version, because the StepSticks which use the qfn package seem to work fine.
Not sure I understand Q3, the HCT04 is used to boost the gate drive voltage to ~5V so power mosfets can fully open. It would be even better is one can boost is to ~7V, but that would require separate power line or charge pump. Where is the Vds = 1.7V coming from?
Consider the STM32F427ZGT6 part, it is much cheaper than the 429.
ALARM1 - as far as I know Marlin/Klipper/RRF do not use that in TMC handling. Also printer boards I took a look at, maps ST_ALARM to ENDSTOP. So I take that as "good to have".
TMC2130 is old chip and for new designs I prefer 2209 / 5160. For legacy use... understand. Good to have CLOCK on DRV interface. Again, what is purpose of this small eeprom there?
Pricing. Be aware 429 is considered basic part, so from one hand is more expensive, but from other is almost the same price that 427 costs, which in turn is extended part.
Vds=1.7V? Taken a look at that spec https://docs.rs-online.com/7feb/0900766b812e05cf.pdf From fig 8 I can read that with Vds=3.3V mosfet drain current is at 55A, much higher than fuse allows to.
The small eeprom is there so one can make a completely plug & play system. The eeprom would have the driver type and rsense values stored in it.
It is not needed for any current firmware.
I have completed routing of the new controller board, and together with this driver carrier board I have placed order at jlpcb.
For 2 preassembled boards, there is no change in price when selecting STM32F427 or 429 variant.
Here are the changes to the original V2 project:
- STM32F429 (obviously)
- Embedded Buck DC/DC with jumper to select 5V from this converter, external 5V port or USB
- Removal of 3x EXP ports
- Reduction from 6 to 2 thermocouple ports using 2x3 pin header/socket, each with dedicated CS signal (no impact on ADC lines)
- Reduction from 5 to 2 ports with static 12/24V
- Reduction from 5 to 2 ports with static 5V
- Changed WIFI header to 2x6 pins
- Changed TF card connecttion to SDIO 4-bit port
- ST_ALARM remapped to ST_ALARM_X, ST_ALARM_Y and ST_ALARM_Z
- Serial connector changed to TFT connector with RESET line
Additionally:
- Small corrections in decoupling and filtering of the VDD/VDDA
- Dedicated GNDA ground with star connection towards GND
PCB 4 layer: (top - tht) GND, 3V3, 5V, GND (bottom - smd)
Components side:
Carrier board:
- voltage polarity protection
- 3 LEDs to show Vin, and from 2x25 header: 5V & 3V
- 8 PCIx slots
- each slot has populated full serial connectinon (TX & RX lanes, compatible to your design)
- each slot has jumper block to map alarm signal to X, Y, Z or common Alarm lines.
PCB 4 layer: Vin, 3V3, 5V, GND
Components side:
Final thoughts:
- 2x25 pin IDC header is capable of connecting 10 PCix slots.
- By populating Serial ports, one is able to create PCIx card with Ethernet, Wifi , Thermocouples etc
Ouch, newest KiCad 5.99 (kicad-r20550 and later) has issue with zone fillining yet adds something to schema.
Now I can edit in my new Schema but can not import that to old (working) PCBnew :/
Congrats, let me know how it turns out.
I have sucessfuly created new board variant and compiled RRF for stm32f429 mcpu with esp8266.
However Andy's framework is tailored to STM32F4 witch he used for further corrections. Thus is it incompatible with other architectures like F7 or H7.
Thinking about FD-CAN, I saw JLCPCB has on their stock STM32H743IIT6 chip which costs €7.1539 (+extended part fee).
This particular chip would be in par with Duet3 one regarding functionality yet 25% faster. It also has more RAM thus any limitation of RRF STM can be removed :) This is good candidate for PrntrBoardV3, with FD-CAN, Ethernet and 8 PCIex. PCB size would be about 100x180mm, so 4-layer one will at JLCPCB cost €35.22 for 5 pcs.
Thus to go with it, a major reconstruction of RRF build framework must be done. I mean to take original Arduino_Core_STM32 and use it to compile F4, H7 variants.
BTW
In the original Core lib I see support for your PrntrBoardV1 & 2 (PRNTR_Vx - single pin definitions!).
In Andy' version there is only V1 (PRNTR_F407_V1)
In my modified build scripts, STM selection is done by the board name, then proper selection of cpu family and procesor code is done. Thus I am able to compile RRF for PrntrBoardV2 if I will only have proper variant defined. Wanna play?
Talking aboit USB,.. from where have you taken your bootloader?
I am creating mine by using STM32CubeMX, with all peripherials defined, so i have initialziation of all of them in main()
/* Initialize all configured peripherals */
MX_GPIO_Init();
MX_ADC3_Init();
MX_CAN1_Init();
MX_I2C1_Init();
MX_SDIO_SD_Init();
MX_SPI1_Init();
MX_SPI2_Init();
MX_TIM3_Init();
MX_TIM4_Init();
MX_USART1_UART_Init();
MX_USART2_UART_Init();
MX_USART3_UART_Init();
MX_USB_OTG_FS_PCD_Init();
MX_TIM9_Init();
MX_FATFS_Init();
/* USER CODE BEGIN 2 */
I know almost everything is not used, still teh final binary code is less than 32kB, so it fits in first two FLASH meory banks.
So the only question is what parts of the perifperal clocks are deconfigured before jumping to the firmware part.