reprapy.pl

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.