MKS TinyBee

[Jarewa]

BIGTREETECH ma fajne LCD dużo lepsze od MKS.

[Marvin27]

To jest jeden ze sposobów stosowanych w Marlinie, choć mało popularny.

Hmm, może tak, ale widzę że jest nawet poradnik tego zastosowania i na podobnej płytce z MCU jako ESP32.
https://teck78.blogspot.com/2020/01/set ... n-mrr.html

źródło: https://www.youtube.com/watch?v=dtXiUXb5DvQ

[arkomania.pl]

Jest wyświetlacz Makerbase MKS H43 (interfejs HMI).
Jest do niego oprogramowanie przy pomocy którego możemy zmieniać firmware. Dość proste oprogramowanie.

https://github.com/makerbase-mks/MKS-H4 ... 8c78hvyXL2

[arkomania.pl]

Doszła do mnie MKS TINYBEE.



Pierwsze spostrzeżenia:

1. Podłączyłem zamiast termistorów rezystory po 100K. Dla NTC 3950, 100k odpowiada temperaturze 25C.
Mam te same rezystory do testowania i zawsze na płytach pokazuje około 25C.
Na TINYBEE pokazuje 34C, czyli o 8C więcej.Można to skorygować dodając szeregowo do termistora rezystor lub
poprzez zmianę w tabelach thermistor_x.h Robiłem kiedyś już taką korektę. Występuje to na 2 portach. napięcie na stabilatorze
jest 3.3V.

Wnioski - wada.

2. Pobrałem z poleconej przez MKS strony Github-a Marlina. Ich wersja, to 2.0.9.2

Ponieważ podłączyłem wyświetlacz H43 po TX2 RX2 musiałem w configuration.h wybrać DGUS_MKS.

W czasie kompilacji szereg dziwnych uwag. Nie lubię tego.
Mimo tego kompilacja się udała.

Wgranie firmware robimy przez kabel USB, w Atomie dolny, lewy róg programu, zakładka PIO Build.

Przyszła pora na Marlina pobranego z marlin.org
Płyta TinyBee jest obsługiwana od Marlina 2.0.9.3 (mimo iż MKS daje wersję 2.0.9.2).
Jest to jedyna wersja i ostatnia.

Za Chiny Ludowe nie mogę skompilować. Ustawienia konfiguracyjne są proste i nie popełniłem pomyłki.
Bez zdefiniowania DGUS_MKS kompilacja jest poprawna,
Z DGUS_MKS kompilacja z błędem.

Wnioski - wada.

3. Wracam do Marlina dedykowanego przez MKS pobranego z Github-a.
Próbuję skonfigurować TMC2209 w trybie programowania.
Konfiguruję programowy UART, Nie raz to robiłem, na dowolnych portach.

Tak jak zawsze edytuję plik od pinów.

Kompilator staje na błędzie, że nie skonfigurowałem UARTów sprzętowych (nie programowych).
To jest robota firmy MKS. Ponieważ płyta TinyBee z zasady nie ma możliwości obsługi UARTA programowego.

Oglądając schemat od razu znalazłem wyjaśnienie. Niemal wszystkie porty wyjściowe są realizowane za pomocą
3 popularnych rejestrów przesuwnych 74HC595 połączonych szeregowo.

Tak zrealizowano tzw, ekspander portów. Ale są to tylko porty wyjściowe. Tak zrealizowano
24 porty. Aby przesłać dane do rejestrów potrzeba 24 cykle taktujące.

Czyli, programowego UART-a nie da się zrealizować.

Wnioski - wada.

Sterowanie mosfetami wszystkich grzałek jest podpięte pod jeden z tych rejestrów.


Czyli już wiadomo, że sprzętowego PWM-a nie ma. Programowy nie wchodzi tu w uwagę.
Tylko wentylatory podpięte są pod porty procesora ESP32.

Wnioski - wada.



Na razie same wady.

Wgrałem ESP3D-WEBUI

Transfer plików na poziomie 10MB w 4min w trybie AP (56).
Zrobiłem parę transferów. Bez przerwań w transmisji.

Wnioski - zaleta.

Podsumowując:

Niemal same wady, Brak wsparcia dopracowanym firmware.

Spróbuję zamiast wyświetlacza obsłużyć dwa TMC2209.
Jest obsługa przez WEB można pominąć wyświetlacz.

[cyfron]

ESP32 z zasady został stworzony do innych celów - Twój test tłumaczy dlaczego ESP32 jest tak mało popularne w tego typu konstrukcjach. Po prostu średnio nadaje się do tego zadania. Dzięki za test.

[arkomania.pl]

Bo ta płyta powinna być zrobiona na ESP32-S3 który ma 44 GPIO i podejrzewam, że w tym kierunku z czasem pójdą.

[arkomania.pl]

Po krótkiej przerwie wracam do tematu płyty MKS TinyBee.

Po wielokrotnych próbach przeprowadzonych na firmware MKS TinyBee Marlin 2.0.9.2 pobranych z Github-a
stwierdziłem, że trzeba porzucić tę wersję ze względu na dużą liczbę pojawiających się fusów w trakcie kompilacji,
mimo iż firmware działa.

Pobrałem świeżą ogólnodostępną wersję Marlina 2.0.9.3 Bugfix i rozpocząłem testowanie płyty.

Zacząłem od skonfigurowania TMC2208/2209 w trybie UART z wykorzystaniem interfejsu sprzętowego UART 2, czyli TX2/RX2.

W Configuration,h

#define SERIAL_PORT_2 -1
#define BAUDRATE_2 115200



W Configuration_adv.h dodałem brakujące wpisy:

#if HAS_DRIVER(TMC2209)
#define X_HARDWARE_SERIAL Serial2
#define Y_HARDWARE_SERIAL Serial2
#endif

zdefiniowałem adresy stepstickow
//MS0 musi być zawsze w trybie UART na OFF
#define X_SLAVE_ADDRESS 0 //MS2-OFF MS1-OFF MS0-OFF
#define Y_SLAVE_ADDRESS 1 //MS2-OFF MS1-ON MS0-OFF


Teraz test.

Ustawiłem stepsticki X i Y na fizyczne 256 mikrokroki (nie ma interpolacji) i w:

#define DEFAULT_AXIS_STEPS_PER_UNIT { 1280, 1280, 400, 500 }

Zrobiłem plik z g-codami, który w powietrzu drukuje box-a z jednym obrysem i wypełnieniem 30% z prędkością
150mm/s. Test wypadł poprawnie. To było sprawdzenie czy wyrabia expander portów przy tak dużej liczbie impulsów
na sekundę (1280x150x24=4608000 imp/s, to niecałe 5MHz, dla prędkości 150mm/s).Tych impulsów jest nieco więcej, ale procentowo niewiele.
Przygotowanie danych do rejestrów przesuwających, itp. ale to nie praca naukowa na temat transmisji szeregowej.


Po sprzętowym UART, przyszła pora na UART programowy (softwerowy).

Próby zakończyły się niepowodzeniem. Już sanity wypluł komunikat, że ESP32 nie obsługuje takiego trybu komunikacji.

"TMC220x Software Serial is not supported on ESP32."

Usunięcie komunikatu i tak niewiele zmieniło, wyskoczyło jeszcze więcej innych diabełków.

Konkluzja:

Osoby które zaadoptowały płytę MKS TinyBee do Marlina, założyły, że nie ma wolnych dwukierunkowych
portów na których można zasymulować programowy UART. Jest to nieprawda, ponieważ ja założyłem, że
do portu sprzętowego UART2 mogę podłączyć wyświetlacz (np. H43), a ze złącza EXP2 użyję dwa porty GPIO12 i GPIO14,
które wykorzystam do skonfigurowania programowego UART. Ale nic z tego. Nieścisłością dużą jest komunikat z sanity z HAl-a ESP32.
Muszę nadmienić, że jest płyta FYSETC-E4 z ESP32S z dużą liczbą portów bez expandera i ten sam HAL jest mu przypisany.
Tylko, że FYSETC-E4 obsługuje sprzętowo wszystkie 4 wbudowane stepstiki przez UART sprzętowy, bez użycia kabelków,

Wracając do TinyBee.

Zostaje nam tylko sprzętowy UART2 do skonfigurowania TMC i brak podłączenia wyświetlacza.

Za wyświetlacz robi ESP3D.


Innym problemem jaki wystąpił na TinyBee, to zły pomiar temperatury. Marlin raportował temperaturę pokojową na poziomie 65C.
(wszystkie 3 wejścia).
Termistor czujnika jest podciągnięty przez rezystor do napięcia odniesienia 3.3V lub w starszych płytach 5V (zależnie od mikrokontrolera).
Jednak na płycie TinyBee napięcie to wynosi około 2,55V. Widać na schemacie, że nie jest to 3.3V. I tu zaczynają się właśnie
zgrzyty z wyliczeniem temperatury. Aby wskazania były dobre musiałem pomiar pomnożyć lub podzielić, jak kto woli, ja wybrałem mnożenie,
przez odpowiednią wyliczoną stałą. Ja pomnożyłem przez 2.55V/3.3V, czyli 0.773.

Zmiany zrobiłem w Marlin\src\module\thermistor\thermistor.h

#define OV(N) int16_t(OV_SCALE(N) * (OVERSAMPLENR) * (THERMISTOR_TABLE_SCALE*0.7745)) // 2.55/3.3V=0.772727

Ja tę wartość skorygowałem minimalnie przybliżając się do rzeczywistych wartości.

Kupiłem, jak już wspomniałem we wcześniejszym poście tę płytę w celu opiniodawczym.
Dzięki niej trochę poćwiczyłem umysł. Praktycznie płyta nie jest zła jak na tę cenę.
Uważam, że wina jej ułomności tkwi głównie po stronie programistów od Marlin zarówno
w firmie MKS Makerbase , jak i moderatorów z marlin.org. Wprowadza się do firmware Marlin
produkt, który jest poprawnie sprawdzony. A ta wpadka z pomiarem temperatury, to porażka.
Jak wspomniałem wcześniej firmware z GitHub MKS miało zawyżony pomiar o 8C.

Na koniec znany schemat podłączenia do stepsticków UARTA2.