Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Some thought about usability, installation, ergonomics #19

Open
ArkadiuszRaj opened this issue Jan 20, 2021 · 20 comments
Open

Some thought about usability, installation, ergonomics #19

ArkadiuszRaj opened this issue Jan 20, 2021 · 20 comments

Comments

@ArkadiuszRaj
Copy link
Contributor

ArkadiuszRaj commented Jan 20, 2021 •
edited
Loading

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.

obraz

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?
@ghent360
Copy link
Owner

One issue with this approach is the airflow. The drivers are designed for horizontal airflow like this:
IMG_2061

The connectors would block the air path.

@ArkadiuszRaj
Copy link
Contributor Author

ArkadiuszRaj commented Jan 21, 2021 •
edited
Loading

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.

@ghent360
Copy link
Owner

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.

@ArkadiuszRaj
Copy link
Contributor Author

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.

obraz
obraz
obraz

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 :)

@ghent360
Copy link
Owner

ghent360 commented Jan 22, 2021 via email

@ArkadiuszRaj
Copy link
Contributor Author

ArkadiuszRaj commented Jan 22, 2021 via email

@ArkadiuszRaj
Copy link
Contributor Author

So I have put 144 pin STM32F429 chip.

obraz

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:

  1. 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?
  2. Purpose of the CLOCK dignal towards the driver cards, what is a gain if TMC uses internal or external clock?
  3. Any reason to use 74HCT04 to drive Mosfets if Vds = 1.7V?

@ArkadiuszRaj
Copy link
Contributor Author

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.

@ghent360
Copy link
Owner

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?

@ghent360
Copy link
Owner

Consider the STM32F427ZGT6 part, it is much cheaper than the 429.

@ArkadiuszRaj
Copy link
Contributor Author

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.

@ghent360
Copy link
Owner

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.

@ArkadiuszRaj
Copy link
Contributor Author

ArkadiuszRaj commented Jan 29, 2021 •
edited
Loading

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:
obraz

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:
obraz

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

@ArkadiuszRaj
Copy link
Contributor Author

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 :/

@ghent360
Copy link
Owner

Congrats, let me know how it turns out.

@ArkadiuszRaj
Copy link
Contributor Author

ArkadiuszRaj commented Jan 29, 2021 via email •
edited
Loading

@ArkadiuszRaj
Copy link
Contributor Author

ArkadiuszRaj commented Jan 31, 2021 •
edited
Loading

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?

@ghent360
Copy link
Owner

ghent360 commented Jan 31, 2021 via email

@ArkadiuszRaj
Copy link
Contributor Author

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.

@ghent360
Copy link
Owner

ghent360 commented Jan 31, 2021 via email

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
2 participants
@ghent360 @ArkadiuszRaj