-
Notifications
You must be signed in to change notification settings - Fork 14
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.
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
Some thought about usability, installation, ergonomics #19
Comments
Fair enough. 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:
Thus I did a spit of the controller board into two parts: Status:
So as for now I am using orginal sub schematics, thus only 6 PCI will be used. |
I would recommend against carrying large current over IDC cable. The power
input on the motor driver boar would allow the drivers to be run at 36V -
for example.
…On Fri, Jan 22, 2021 at 7:17 AM Arek ***@***.***> wrote:
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.
[image: obraz]
<https://user-images.githubusercontent.com/16072469/105503632-1ece0e80-5cc7-11eb-9ce9-68e72ef1bc57.png>
[image: obraz]
<https://user-images.githubusercontent.com/16072469/105503706-37d6bf80-5cc7-11eb-8e7e-d2fbd75403b6.png>
[image: obraz]
<https://user-images.githubusercontent.com/16072469/105504052-9a2fc000-5cc7-11eb-909a-aa30fc26f19c.png>
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 :)
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#19 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AB6FRVR5CCOUYIZTUJUUSXDS3GJIBANCNFSM4WKMDOAA>
.
|
Yeah.
W dniu pt., 22.01.2021 o 18:34 ghent360 <notifications@github.com>
napisał(a):
… I would recommend against carrying large current over IDC cable. The power
input on the motor driver boar would allow the drivers to be run at 36V -
for example.
On Fri, Jan 22, 2021 at 7:17 AM Arek ***@***.***> wrote:
> 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.
>
> [image: obraz]
> <
https://user-images.githubusercontent.com/16072469/105503632-1ece0e80-5cc7-11eb-9ce9-68e72ef1bc57.png
>
> [image: obraz]
> <
https://user-images.githubusercontent.com/16072469/105503706-37d6bf80-5cc7-11eb-8e7e-d2fbd75403b6.png
>
> [image: obraz]
> <
https://user-images.githubusercontent.com/16072469/105504052-9a2fc000-5cc7-11eb-909a-aa30fc26f19c.png
>
>
> 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 :)
>
> —
> You are receiving this because you commented.
>
>
> Reply to this email directly, view it on GitHub
> <
#19 (comment)
>,
> or unsubscribe
> <
https://github.com/notifications/unsubscribe-auth/AB6FRVR5CCOUYIZTUJUUSXDS3GJIBANCNFSM4WKMDOAA
>
> .
>
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
<#19 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AD2T6FK6KDOBI7OATWQSIE3S3GZKNANCNFSM4WKMDOAA>
.
|
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.
|
Also please notice the RJ footprint & 3d model. |
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. |
Ouch, newest KiCad 5.99 (kicad-r20550 and later) has issue with zone fillining yet adds something to schema. |
Congrats, let me know how it turns out. |
Thanx. Will do.
Waiting for the prototypes I have started to define a new variant in
STM32_duino for STM32F429.
Also I am preparing a new environment to compile RRF using this specific
variant.
BTW, RRF uses TIM1/5 for internal purposes (i.e. TIM1 for SoftUART and TIM5
for stepping).
In V2 you are using PA8 for PWM which is mapped to TIM1_CH1. Thus there is
a clash with current STM32F4 RRF code.
|
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). 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 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? |
Andy is using an old version of the stm32duino core as base for the
CoreSTM32F4 repository. That is why there is only v1 or my board.
I have a clone of RRFBuild, CoreSTM32F4 and RepRapFirmware with mods to
compile RRF for the prntrboard v2 and updated to the latest stm32duino
version.
That said the RRF port is not quite complete and it does not work on my
board yet. One issues is that Andy has not ported the part of the code that
can share a serial port to talk to the 2209 steppers. Also there is
something odd with the usb and it does not seem to work yet. I suspect the
SKR has bootloader that is initializing the usb and i don’t have that code.
…On Sun, Jan 31, 2021 at 2:36 AM Arek ***@***.***> wrote:
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 arhcitectures 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.
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 on 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?
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#19 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AB6FRVWEJVZG5ORFPRZMY5TS4UXDLANCNFSM4WKMDOAA>
.
|
Talking aboit USB,.. from where have you taken your bootloader?
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. |
I also used the CubeMX to generate the startup code, but I wanted to fit in
16k, so only use minimal peripherals SDIO and some LEDs. I tried to
de-configure all clocks before jumping to the main app to try and mimic the
reset state. I don't think there is a strict rule, as long the main app is
not confused by the bootloader settings it should be ok.
…On Sun, Jan 31, 2021 at 8:44 AM Arek ***@***.***> wrote:
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.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#19 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AB6FRVQCGDTQFZO2QOGI27TS4WCIHANCNFSM4WKMDOAA>
.
|
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?
The text was updated successfully, but these errors were encountered: