reprapy.pl

Witam! Szcęść Boże!
https://github.com/bigtreetech/BIGTREET ... 60T%20Plus

Błąd dotyczy wyboru "MODE", obydwa piny są podciągnięte zewnętrznie do Vio (+3,3-5V) przez rezystory. Pin SPI_MODE ma wewnętrzny pulldown.
Aby ustawić ten sterownik w trybie SPI należy założyć zworkę na goldpiny SD_MODE (opis na spodniej stronie PCB) a goldpiny opisane jako SPI_MODE pozostawić bez zworki.

Chip ogólnie fajny, nie robi na nim wrażenia nawet taka transmisja :
Pozdrawiam!

Możesz odczytać Patt Number MOSFETow? Zawsze mnie ciekawi jakie tranzystory dają z otchłani Chin, to co jest w dokumentacji nie pojawia się w google.

Śmiem twierdzić że to te:
https://www.jjwdz.com/pdf/MOSFET/pdf/JM ... Rev1.0.pdf

Bardzo możliwe, że masz rację, obudowa się nie zgadza, ale pewnie kawałek krzemu ten sam. Przynajmniej na papierze porządny tranzystor, lepszy niż te co z TME brałem pod swoją płytkę a całkiem tanie nie były..

Nie ma żadnych zdjęć prawdziwej płytki, więc nie wiadomo czy obudowa się zgadza czy nie. Sądzę że w projekcie użyto obudowy LPAK tylko dlatego bo tylko taka była dostępna w bibliotece programu. A naprawdę montowany jest taki w obudowie DFN (są wymiarowo mniej więcej zgodne).

ARMed: wstaw zdjęcie płytki.

Witam !
wszystkie 8x : SL1008A
Na schemacie z githuba "JSL1008A".

https://en.sekorm.com/doc/3233217.html

?

Pozdrawiam !

No i potwierdziło się że obudowa to nie jest LPAK.
Ale czy to ta wersja którą podałem, czy ta którą podał ARMed, to nie wiadomo. No ale to mała różnica.

Jutro jeśli czas pozwoli zrobię lepsze zdjęcia pcb.

Co mnie na tą chwilę interesuje to wybór zewnętrznego zegara (wtedy teoretycznie SPI można pocisnąć do 8MHz), ale to też zostawię sobie na jutro.

Pozdrawiam !

A po co Ci SPI 8 MHz?

W tmc nic nie idzie "live" wiec wystarczył by nawet 100X mniej. Podniesienie może więcej narobić problemów niż pożytku bo z reguły one są na małe odległości.

Witam!

Co konkretnie kolega ma na myśli mówiąc że "nic nie idzie live"?
Pozdrawiam !

SPI jest używany do konfiguracji po uruchomieniu drukarki oraz periodycznego sprawdzenia statusu, za bardzo nie ma udziału w samym druku.
Na oko na zdjęciu jest pełna obudowa DFN (5x6mm), więc to nie jest:
https://www.jjwdz.com/pdf/MOSFET/pdf/JM ... Rev1.0.pdf
Tylko:
https://ceultimate.ks3-cn-beijing.ksyun ... A7bx8g.pdf

Nawet lepiej

PS, shunty 22mR - o ile nie zamierzasz iść w prądy >5A RMS, polecam je zmienić na 50-75mR, mikrokroki lepiej będą wychodzić.

8MHz to nie jest "strasznie dużo". Nie ukrywam że przy 4MHz transmisja trochę "muli" - wynika to ze sposobu przesyłu danych i ilości (do tego dochodzi np. nieoczekiwany reset i konieczność ponownego ustawiania rejestrów).

np. Jeśli chcę odczytać wartość rejestru to muszę to zrobić albo 2 razy i pamiętać że kolejna operacja np. zapisu zwróci wartość odczytu poprzedniego rejestru (pogmatwane?) albo robić to w stylu "pipeline" co niby może przyspieszyć wszystko ale w początkowej fazie pisania biblioteki i oprogramowania na uC może spowodować sporo problemów.

Holgin: Nie wiej jak w druku, ale jest możliwość pełnej kontroli "live" od odczytu pozycji po zmiany parametrów ruchu - w czasie ruchu "on the fly".
Tak, racja z tymi Rsens R022, dobiera się je pod konkretny prąd maksymalny (wzór jest w datasheet).

Pozdrawiam !

Tak z ciekawości - co za projekt masz ciekawy że Ci transmisja "muli"?
Mam projekt z 5160; przy starcie ustawiam 5 rejestrów a potem tylko odpytuje luźno ~50Hz o status (głównie chodzi o wykrycie zgubienia kroku).
Sterowanie jest przez step/dir; z tego też powodu mam pozycję (choć i tak fałszywą o jeden krok ;p).

Witam !
~5 x TMC5160 skorwlowanych ze sobą
cortex M7 (UART<->PC, SPI<->TMC , rtos)

Interpreter g-code na cortex M7 (pisany od zera), g-code sender PC (pisany od zera).

Ogólnie chodzi o to że będę zmieniał ustawienia w czasie ruchu, to już powoduje pewne problemy przy tych <4MHz , pomijam niefortunne stwierdzenie w datasheet (The SPI command rate typically is a few commands per complete motor motion) a patrzę raczej na (All motion parameters can be changed on the fly. The motion controller recalculates immediately).

Normalnie to faktycznie nie stanowiło by najmniejszego problemu.

Pozdrawiam

A można spytać co dokładnie chcesz osiągnąć zmianą ustawień podczas ruchu? Jestem ciekawy.

To jest dobre pytanie. Niestety niczym was tu nie zaskoczę. Nie ma tu nic czego na step/dir nie można by zrealizować. Trudność raczej bierze się z chęci użycia tylko SPI. Choć pewnie ktoś sprytniejszy by znalazł do tego więcej zastosowań (np.fala zamiast rampy bez stopu? itp). Mi po prostu chodzi o zmianę parametrów pracy na bierząco (bez zatrzymywania) zależnie od różnych czynników zewnętrznych (które będzie ogarniał uC).

I to ma być mimo wszystko tylko dodatek do całości a nie główne założenie.

ARMed pisze: ↑21 sty 2024, 15:42 ~5 x TMC5160 skorwlowanych ze sobą
cortex M7 (UART<->PC, SPI<->TMC , rtos)

Interpreter g-code na cortex M7 (pisany od zera), g-code sender PC (pisany od zera).

O, czyli coś jak moja frezarka.
W końcu jakieś ciekawostki a nie tylko te Marliny i Repetiery.

ARMed pisze: ↑21 sty 2024, 15:42 Ogólnie chodzi o to że będę zmieniał ustawienia w czasie ruchu, to już powoduje pewne problemy przy tych <4MHz , pomijam niefortunne stwierdzenie w datasheet (The SPI command rate typically is a few commands per complete motor motion) a patrzę raczej na (All motion parameters can be changed on the fly. The motion controller recalculates immediately).

Tak, wszystkie parametry zmienisz podczas pracy i większość z nich ruszy od razu. Problem jest taki, że jak czegoś nie przyjmie to dowiesz się tego ze statusu, a w przypadku niektórych możesz mieć losowe opóźnienie (czekasz na przejście przez pełny krok w sytuacji gdy masz działającą aproksymację do dzielnika 256).
Nie pamiętam czy czegoś nie przyjmował dopiero na zbocze En (0->1) bo z czymś takim kiedyś miałem do czynienia ale teraz nie widzę w kodzie żadnych uwag, to może nie tu.

ARMed pisze: ↑21 sty 2024, 16:44Niestety niczym was tu nie zaskoczę.

No weź zaskocz.

Przewertuję jeszcze raz datasheet, ale fakt że w pewnych miejscach dosyć "specyficznie" opisuje działanie kontrolera i łatwo coś źle zrozumieć.

Jak chcesz to dokładnie zbadać to zostaje Ci tylko złożenie stanowiska testowego bo jak chcesz wycisnąć z kontrolera 100% to sporo rzeczy w dokumentacji Ci braknie. A działanie innych może powodować problemy.

dziobu pisze: ↑21 sty 2024, 17:55 Jak chcesz to dokładnie zbadać to zostaje Ci tylko złożenie stanowiska testowego bo jak chcesz wycisnąć z kontrolera 100% to sporo rzeczy w dokumentacji Ci braknie. A działanie innych może powodować problemy.

Nie bardzo wiem dlaczego? Fakt że Trinamic sprzedaje zestawy do testów i udostępnia IDE. Ale większość (wszystkie?) oprogramowania drukarek/cnc bazują na ogólnych bibliotekach np: "plain C tmc5160 driver"
https://github.com/terjeio/Trinamic-library

Stanowisko testowe i tak zrobię, ale planowałem je raczej z powodów 'logistycznych' (dostępu do wszystkiego - żeby było "pod ręką").

Bazują bo chyba żadna drukarka nie używa generatora ruchu/ramp tylko po prostu step/dir plus konfiguracja

No to teraz kwestia dlaczego nie używają wbudowanego kontrolera ruchu?
Bo skoro nie używają - musiał być ku temu jakiś powód.

Problem z synchronizacją ruchu kilku silników?
'Lepszy' kontroler ruchu programowy?
Implementacja czegoś co już mieli ogarnięte step/dir była prostsza?
...?

No masz problem synchronizacji kilku napędów, czyli podstawa jazdy w tym wypadku.
Poza tym fw do drukarki obsługuje wiele kontrolerów a zestaw step/dir jest uniwersalny; no i gdy planer ruchu powstawał to nie było tych TMC. Przy obecnym natłoku ARMów to też nie wiem jaki jest sens używania tych wbudowanych bajerów; albo zwyczajnie nie mam kontaktu z miejcami w których ma to zastosowanie.

Na pewno problemem była by synchronizacja przy próbie użycia np. DcStep.

Z resztą na razie się nie wypowiem, wyjdzie w praniu. To i tak raczej z ciekawości (na codzień używam LinuxCNC step/dir). Ale nie ukrywam że będę się cieszył jeśli poświęcony czas da pozytywne rezultaty.

Osobiście mam zamiar powalczyć z CoolStep - perspektywa podbijania prądu podczas przyśpieszenia jest dla mnie bardzo kusząca

Powiem tak: ustawianie timingów i tych wszystkich współczynników + kształt przebiegu na TMC, to już jest praca dyplomowa. Zobaczcie np. temat: viewtopic.php?t=6764 - to dopiero zajawka tego czego można się spodziewać. Do tego dokumentacja od Trinamic-a do tego wszystkiego jest napisana przez kogoś, kto rozumie jak to działa dla kogoś innego, co też to doskonale rozumie i dużo 'oczywistości' jest w niej pominięte i można sobie to czytać z 10 razy i nic z tego nie wyniknie. Do tego ciągłe mieszanie 'umownych' wartości parametrów z ich przesuniętymi wartościami jakie lądują w rejestrach i jest bajzel ciężki do ogarnięcia.
A gotowe stepsticki czasem dosyć luźno podchodzą do zaleceń producenta i np. często brakuje filtra RC z Rsens, brak rezystorów do bramek mosfetów, albo 'wysokonapięciowe' nie mają osobnego stabilizatora mimo, że datasheet jasno mówi, że na wewnętrznym do ~30V maks. Czyli zabawa powinna się zaczynać od analizy schematu i sprawdzenia wszystkiego czy jest takie jak ma być.

Bawiłem się timingami, ale po policzeniu idealnych parametrów i tak skończyło się na przeleceniu wszystkich możliwych kombinacji parametrów na gotowej maszynie + analizator widma i sprawdzanie rezonansów i ich głośności. Oczywiście końcowe współczynniki średnio pokrywają się z wyliczonymi

Ale życzę sukcesów, z oscyloskopem + stanowisko do testów zachowań silnika i na pewno będzie pierwszorzędna zabawa

majek pisze: ↑21 sty 2024, 20:31 Czyli zabawa powinna się zaczynać od analizy schematu i sprawdzenia wszystkiego czy jest takie jak ma być.

Nawet lepiej, chyba trzeba będzie dokładnie - fizycznie - sprawdzić wszystko bezpośrednio na PCB.

A teraz czytam sobie :
https://github.com/teemuatlut/TMCStepper/issues/157

Szybkie potwierdzenie dotyczące głównego tematu :

Rejestr 0x04 IOIN, bit 6

Z zworką na SD_M
bin: 0b00010011 Bez zworki na SD_M
bin: 0b01010011

Po ponownym przestudiowaniu manuala : pozostawię na razie Rsens 0.022 R i będę dalej testował specjalnie na jakiś malutkich silniczkach np. 17SH4401 (1.5A). Optymalny Rsens dla tych silników powinien wynosić 0.15 R.

Rsens 0.022 R 17SH4401 FULL SPI. Pierwsza próba.

Szału nie ma, ale to są standardowe ustawienia i pierwszy obrót tego silnika.

Całe zamieszanie wzieło się z tego że te sterowniki i manuale (btt) są zrobione pod oprogramowanie nie wspierające MODE 1 "full spi" sterownika - "kości" (tmc). Moim zdaniem btt trochę wprowadza w błąd.

Czyli:
1)zworka na SD_M : tryb full spi MODE1
2)brak zworek : spi do konfiguracji + step/dir, MODE 2

Temat chyba jest już wyjaśniony?

Pozdrawiam

FULL SPI MODE 1 - druga próba

-power supply : 1A 24V C.V.
-tmc5160 spread cycle, stealth chop, 0,5A max
-Rsens 0.022 R

Największy hałas robi zasilacz. Silników praktycznie nie słychać nawet pod obciążeniem. Pewnie można by się jeszcze pobawić z parametrami ale jak dla mnie to już jest ok !

A weź dużym prądem silnik, i ciut większe obroty bo po zasilaczu widać że to dyma ledwo 8W

Jasne ! Ale od czegoś trzeba zacząć. Pod obciążeniem ma max 0,5A ~ 12W.

Trochę zaczynamy odbiegać od głównego tematu.
Tak na szybko trzeci test 1.5A max 24V prędkość max x2 poprzedniej.

TMC5160 z FULL SPI MODE 1 działa. Reszta to kwestia doboru parametrów. Ale to "temat na inny temat" zapewne.

Audio na maxa (tak że z zamkniętymi drzwiami słychać roznowy z innego pomieszczenia - bardzo naukowy test), silniczek przy samym mikrofonie.



Ale dalej do tematu to nic nie wnosi.

Sterowanie przez SPI wymaga innego podejścia, innych obliczeń, nic dziwnego że nikt do tej pory nie wprowadził tego do swojego oprogramowania. Główny kontroler ruchu i synchronizacji nie jest sprawą trywialną. Chyba jeszcze przez jakiś czas żaden z większych projektów tego rozwiązania nie wprowadzi. A szkoda. Mi się to coraz bardziej zaczyna podobać.

Pozdrawiam

Masz sondy prądowe, żeby obejrzeć co tam się dzieje na fazach silnika?

Jedynie przez Rsens. Nie mam sondy prądowej.

Na pewno przyda się później sprawdzić też przebiegi i zweryfikować te wszystkie parametry. Ale na razie się tym nie przejmuje. Po pierwsze: bo tego temamu jeszcze dobrze nie znam : muszę się w to dopiero zagłębić (na szczęście tutaj są ludzie którzy temat silników i parametrów mają już opanowany ) a po drugie na tym etapie to nie ma sensu (później tak ale teraz nie ... ).

Uwaga uwaga, a jednak ktoś tego używa
https://twitter.com/josefprusa/status/1 ... 4931311748 Warto w sumie dodać, że to co pisałem wcześniej jest trochę nieprawdą - jest jedna firma, która nie używa step/dir - jest to Bambu Lab. Nie używają oni w ogóle stepsticków, tylko generują sygnały sterujące MOSFETami bezpośrednio przez procesor - czyli z pominięciem TMC2160/5160. Jest to rozwiązanie bliskie do SPI Direct Mode.

Przykro mi ale NIE ! Tmc2130 nie posiadają motion controllera, to jest zwykłe sterowanie step/dir tylko konfiguracja i kontrola przez SPI - co już jakiś czas temu udało mi się opanować I nie tylko mi.

Sterowanie mosfetami też nie jest tym samym, takie kontrolery są już od dawna. Bliższe to moim zdaniem jednak do step/dir. ST się w tym trochę 'wyspecjalizował'.

Pozdrawiam

Mi nie chodzi o Motion Controller tylko bezpośrednie sterowanie prądami cewek przez SPI. Pozwala to znacznie lepiej sterować silnikiem niż tylko Step/Dir.
Dyskretny sterownik to przeniesienie całego algorytmu do uC (pomiar prądów), pozwala to uzyskać chyba najlepsze rezultaty, oczywiście wymaga to mocnego procesora i dojrzałego softu.

Jasne, tylko jak już mówiłem to nic nowego. I to jest chyba pierwsze co zrobiłem (bo było najprostsze). Do tego dochodzi jeszcze automat - coolstep + np. monitorowanie prądów cewek (czyli jakby ~obciążenia - stallguard). uC zbiera dane i dostosowuje to czego chce człowiek od maszyny do realnych możliwości maszyny lub konkretnych zadań, przyspieszeń itp.

Cała idea tmc wiąże się z przerzuceniem tych zadań z uC na sterownik tmc. Bo nawet najlepsze uC raczej nie dadzą sobie z tym rady w kilku osiach + mając jeszcze dodatkowe zadania do wykonania.

Jeśli czegoś z Twojej wypowiedzi nie zrozumiałem to wybacz, temat jest dosyć obszerny i jeśli nie mówimy o konkretach technicznych "co i jak dokładnie" to może być teudno dojść do porozumienia.

Jeśli jesteś w temacie to możesz opisać co dokładnie oni robią, jak, jakie są korzyści jakie problemy to stwarza. Bo może interpretuję to po prostu z perspektywy swoich doświadczeń i togo co robię aktualnie.

Pozdrawiam

Oj poradzą sobie - przecież Bambu Lab działa. Tam nie ma żadnego Trinamica ani Allegro, tylko procek, gate driver, MOSFETy i shunty.

Nowe, nie nowe - no właśnie poza Bambu i teraz Prusą, wszyscy w świecie druku 3D lecą na Step/Dir. Jakie zalety ma rezygnacja z tego - to można przeczytać w poście Prusy, obiecują szerszy opis niedługo. Ogólnie - mniejsze wibracje, cichsza praca

Było by fajnie jakbyś to opisał

TMC2130 na rynku od 2014 roku? 10 lat?

Pozdrawiam

Co dokładnie miałbym opisać?
Wpływu rezygnacji ze Step/Dir aż tak nie wytłumaczę, ale dobrą referencją są wątki o Bambu i tym jakie zmiany przynoszą aktualizacje softu (cisza, kultura pracy).

Tak, TMC2130 jest stary, ale co z tego? W drukarkach króluje Step/Dir. Chyba że znasz jakąś konstrukcję, która działała inaczej?

Z tego co widzę to bambu używa uP cortex A7 quad (?) - czyli pod tym względwm bardzo blisko mu do ~takiego 'słabego' na dzień dzisiejszy raspberry pi 2.

Nie posiadam bambu, wierzę na słowo że kontroluje bezpośrednio końcówki mocy. Takie rozwiązanie już dawno stosuje ST i to nie tylko dla krokowców. Tutaj jest bardzo dużo informacji:
https://www.st.com/content/st_com/en/ec ... ystem.html

Jeśli to ma być na prawdę efektywne to wypadało by żeby jeden rdzeń zajmował się kompleksową kontrolą tylko jednego silnika.

Co do tego że tmc2130 jest 'stary' - to tylko tyle że dużo czasu im zajęło ogarnięcie i implementacja funkcji tego sterownika.

Jeśli chodzi o sterowanie step/dir to jest to standard już od wielu lat i jeszcze przez jakiś czas tak zostanie

Temat od początku jest jednak o "MODE 1: Full Featured Motion Controller & Driver" i nijak się ma do tego co robi prusa czy bambu.

Pozdrawiam

Okej, nic już nie piszę - chciałem tylko pokazać, że ktoś robi coś innego niż Step/Dir i że ma to sens

PS sterowanie silnikami bez dedykowanego drivera tylko z softem nie jest tylko domeną ST, oni po prostu udostępnili sporo narzędzi, żeby przyciągnąć klientów. Na wielu małych prockach robi się FOCa i inne algorytmy, od tego się właściwie zaczęło - kiedyś nie było gotowców w ogóle

Znalazłem chwilę żeby przejrzeć dokumętację 2130, już wiem o co chodzi. Po prostu datasheet tmc5160 nie podaje tego nawet jako coś wartego szczególnej uwagi. Można powiedzieć że zrezygnowali z tego na rzecz zintegrowanego kontrokera ruchu i większej automatyzacji tego procesu. Choć te opcje są dalej dostępne. W przypadku tmc5160 to raczej mija się z celem, w przypadku 2130 to jedyne sensowne rozwiązanie w kierunku do kontroli przez SPI.

"Nic już nie piszę"

Daj spokój. Ciekawe informacje tu podajesz

Pozdrawiam

Tutaj G-CODY nie są jeszcze buforowane, wszystko wykonuje się na bierząco ale nawet teraz nie wygląda to najgorzej. Teraz przyszła pora na buforowanie i intensywniejszą pracę w tle uC.

Spread cycle. Rsens zostaną wymienione pod RMS 5,5A 12,5Nm i 2A 2Nm.

Pozdrawiam

Feedrate test, dla śruby pitch 5, mm/min. Przelicza już dane dla 5 osi. Exact stop mode. Spread cycle.

Holgin pisze: ↑03 mar 2024, 10:09 Uwaga uwaga, a jednak ktoś tego używa
https://twitter.com/josefprusa/status/1 ... 4931311748
prusa.PNG

Warto w sumie dodać, że to co pisałem wcześniej jest trochę nieprawdą - jest jedna firma, która nie używa step/dir - jest to Bambu Lab. Nie używają oni w ogóle stepsticków, tylko generują sygnały sterujące MOSFETami bezpośrednio przez procesor - czyli z pominięciem TMC2160/5160. Jest to rozwiązanie bliskie do SPI Direct Mode.

Oni twierdzą że używają direct mode tylko do kalibracji (dobrania ustawień tmc2130)? Trochę to bez sensu, równie dobrze mogli by po prostu zmieniać te ustawienia i obserwować wyniki (co prawdopodobnie robią)? Informacje zwrotne czerpią z akcelerometru. Później i tak używają step/dir do normalnej pracy?

Nie widzę tu żadnych korzyści ponad tym co oferuje stealthchop, coolconf, step/dir.

Jeśli ktoś posiada więcej informacji odnośnie tego jak to dokładnie działa i jakie są korzyści to proszę śmiało pisać

Pozdrawiam

Jesteś pewien, że to tylko do kalibracji?

Nie jestem pewien Do kalibracji na pewno, a czy do normalnej pracy też?

https://github.com/prusa3d/Prusa-Firmwa ... .0.0-alpha

Dla mnje te opisy nie są zbyt konkretne jeśli o to chodzi.

Trzeba by poszperać w źródłach - jak ktoś jest w stanie to szybko sprawdzić (wie gdzie szukać) to niech śmiało dementuje moje przypuszczenia

Trzeba poczekać, Joseph obiecał tłusty opis, więc wszelkie wątpliwości powinny być rozwiane, ale ja myślę, że to nie jest tylko kalibracja tylko praca ciągła.

Możliwe ciekawe jeszcze jest to że pracują nad stealth chop, ale to ma być ich własna implementacja czy wykorzystają sprzętowy stealth chop?

Nie StealthChop (napięciowa kontrola silnika, patent Trinamic) tylko Stealth Mode - czyli Prusowy tryb cichy. Porównałbym to do tego co zrobiło Bambu - active noise cancelling.

No też jestem ciekaw co tam naprawdę robią.
W sumie gdzieś już tu była dyskusja, że na vfa, to właśnie akcelerometr powinien wystarczyć do tuningu.
Ja przerabiałem mnóstwo kombinacji rejestrów TMC, żeby uzyskać jako taką pracę 5160 z trochę większymi silnikami i gdyby to właśnie zautomatyzować, to trwałoby to chwilę, a nie kilka dni.
Marzy mi się kiedyś zrobić stanowisko, gdzie na silnik jeszcze będzie założony eknoder, żeby dostosować dodatkowo kształt sinusoidy generowanej do rzeczywistych ruchów silnika, bo w TMC można sobie wgrać swój kształt przebiegu, ale nie widziałem żeby ktoś z tego korzystał.

Tak się zastanawiam czy nie dało by się bez akcelerometru. Wykorzystując informacje z back emf, dostępne do odczytu.

majek pisze: ↑11 mar 2024, 21:29 w TMC można sobie wgrać swój kształt przebiegu, ale nie widziałem żeby ktoś z tego korzystał.

Ludzie się tym bawili do minimalizowania VFA.

Ludziska mówią że direct mode jest używany do kalibracji tabeli LUT nie do normalnej pracy. Co w sumie miało by sens i na pewno też jest sporym osiągnięciem Ale to dalej nie potwierdzone info.

Pozdrawiam

Tutaj kilka zrzutów na szybko

1 kanał :

min res: trochę przesada, ale ogólnie można załapać o co chodzi:
max zoom:

Na co patrzymy?

Oglądamy przebiegi choppera (spread cycle) za końcówkami mocy, pomiar Rsens. Tak jak 'widzi' to tmc5160.

Rsens idą w tej płytce bezpośrednio do GND, dzięki czemu spokojnie można dokonać pomiaru 1 sondą.
Screeny to trochę lipa, muszę sprawdzić czy dało by się jakoś przechwycić video (po sieci?).

Podstawa czasu jest na górze każdego screena przy czerwonym napisie 'stop'.