- Symulator MaSzyna -
Symulator EU07 (i nie tylko) => Bieżące Symulatorowe => Wątek zaczęty przez: maciek001 w 13 Listopada 2016, 17:07:48
-
Konfiguracja portu szeregowego (COM):
Standardowa ramka UART -> 8 bitów danych, 1 bit stopu, bez kontroli parzystości i przepływu
Prędkość można ustawiać w pliku eu07.ini. Ja używam 0,5Mbps (przejściówka UART-USB).
Jak działa transmisja:
Transmisję rozpoczyna PC-et wysyłając pierwszy bajt danych. Mikrokontroler od razu odsyła pierwszy bajt danych.
Drugi bajt danych z PC - drugi bajt danych z uKontrolera itd.
Jeżeli uKontrolerowi skończą się dane do wysłania to tylko odbiera.
Jak to działa w praktyce: komputer nadaje całą ramkę danych. Mikrokontroler powinien niezwłocznie nadać dane do komputera. Mikrokontroler może wysłać wszystkie dane w momencie odebrania czegokolwiek od PC-ta (full-duplex). Nie wysyła się danych do PC-ta więcej razy niż PC-et wysłał do mikrokontrolera. Taki sposób transmisji zabezpiecza przed wysyłaniem danych jeżeli port szeregowy w komputerze nie został jeszcze otwarty.
Konfiguracja wejść (przycisków i przełączników):
Przypisania wejść do funkcji dokonuje się w pliku eu07_input-uart.ini. Umożliwia konfigurację sygnału jako impulsowego lub bistabilnego (przełącznika).
Konfiguracja wyjść (lampek kontrolnych, itp):
Nie ma możliwości skonfigurowania tego rodzaju sygnałów. Są one na stałe przypisane do danego Bajtu i bitu (patrz dokumentacja w arkuszu kalkulacyjnym).
Wpisy do pliku eu07.ini:
Do wygenerowania wpisów polecam aplikację MWD SerialPort tester (link niżej). Umożliwia załączenie/wyłączenie obsługi nastawników, kranów hamulców (wejść), kalibrację mierników (manometrów i elektrycznych), konfigurację prędkości transmisji danych i inne.
Programy i przydatne pliki do programowania i testowania elektroniki do pulpitów:
Pod linkiem https://drive.google.com/drive/folders/17aRJMr7fRE2PSOPi4jztCh_sjgfq0Xwz?usp=sharing (https://drive.google.com/drive/folders/17aRJMr7fRE2PSOPi4jztCh_sjgfq0Xwz?usp=sharing) znajdziecie kilka plików i program, które mogą przydać się przy budowie elektroniki do pulpitu:
- Program MWD SerialPort tester służy do generacji wpisów do pliku eu07.ini oraz testowania komunikacji z elektroniką - emulacja symulatora. Można w nim zadawać i odczytywać stany przełączników i kontrolek, odczytywać wartości nastawników i innych kontrolerów. Podczas pierwszego uruchomienia generują się pliki indicatorInfo.ini i switchInfo.ini, w których można przypisać nazwy do kontrolek i przełączników. Program wspomaga ramkę danych od Milek7, opisaną w pliku poniżej.
- Plik * Maszyna Uart.ods zawiera informacje na temat danych wysyłanych w obu kierunkach
- Plik libserialport-0.dll: można go podmienić z plikiem w folderze maszyny jeżeli komunikacja z moim programem działa, a Maszyna się nie włącza i generowany jest plik dump (mnie pomogło).
MWD SerialPort tester
Zrzuty z programu dostępne tutaj: https://drive.google.com/drive/folders/1kNK0Q2bLePwM6I0lvyZe6gXf6CnAO8Gt (https://drive.google.com/drive/folders/1kNK0Q2bLePwM6I0lvyZe6gXf6CnAO8Gt)
Wypuściłem wersję 1.2.2 1.0 (u mnie działa). Jeżeli są jakieś problemy proszę o stosowną informację w PW. Program zgodny z wersją MaSzyny21.04 i exe od Tmj.
Komunikacja od dłuższego czasu działa na standardowym exe, pomimo tego załączam linki do exe Tmj:
- od Milek7: https://ci.appveyor.com/project/Milek7/maszyna/build/artifacts (https://ci.appveyor.com/project/Milek7/maszyna/build/artifacts)
- Tmj: https://eu07.pl/forum/index.php/topic,28920.0.html (https://eu07.pl/forum/index.php/topic,28920.0.html)
exe od Tmj obsługuje już nową ramkę.
Linki do plików źródłowych na github:
https://github.com/eu07/maszyna/blob/master/uart.h
https://github.com/eu07/maszyna/blob/master/uart.cpp
Lista zmian:
Aktualizacja 2021.05.10 2220
MWDSerialPortTester 1.2.2. Dodana obsługa manometru pantografu i porządki w kodzie.
Aktualizacja 2020.05.31 1130
Edycja postu: uzupełnienie informacji.
Aktualizacja 2020.05.12 2100
MWDSerialPortTester 1.0. Poprawa wyglądu i drobne porządki w kodzie.
Aktualizacja 2020.04.13 1320
Aktualizacja arkusza kalkulacyjnego o przekaźnik różnicowy (ground_relay). Exe Tmj powinno współpracować z nową ramką.
Aktualizacja 2020.04.10 1830
MWDSerialPortTester 0.2.2 poprawiono generację wpisów do pliku eu07.ini oraz dodano wpis uarttachoscale - mnożnik prędkości.
Aktualizacja 2020.04.09 2135
do programu MWDSerialPortTester dodano generację wpisów do pliku eu07.ini.
Aktualizacja 2020.04.08 1855
Powoli dokonuję zmian w tym wpisie. Będę go czyścił i redagował na nowo.
Exe z jakim współpracować będzie opisana ramka będzie od Milek7.
-
Udało mi się przekonwertować nadawanie i odbiór według Twojego przykładu z pierwszego postu na język Arduino (bajty w tablicach liczone są od 0):
volatile uint8_t TablicaZPC[31] = {0};
volatile uint8_t TablicaDoPC[17] = {0};
void setup() {
pinMode(13, OUTPUT); //ustawienie pinu 13 (wbudowana w Arduino dioda LED) jako wyjście cyfrowe
digitalWrite(13, LOW); //ustawienie stanu niskiego na pinie 13
Serial.begin(500000); //nawiązanie komunikacji z prędkością 500000b/s
while(!Serial){}; //czekanie do nawiązania komunikacji z komputerem
}
void loop() {
for(byte i=0; i<31; i++){ //pętla umożliwiająca wysłanie 31 bajtów danych
while(!Serial.available()); //czekamy na odebranie bajtu danych
TablicaZPC[i] = Serial.read(); //zapis danych do naszej tablicy
if(i < 17){ //zabezpiecznie, żeby nie wysłać za dużo danych do komputera
Serial.flush(); //sprawczanie czy już wysłano wcześniejsze dane (czekanie na wysłanie danych)
Serial.print(TablicaDoPC[i]); // wysłanie danych do komputera
}
}
digitalWrite(13, (TablicaZPC[4] & (1<<1))); //ustawienie wyjścia 13 (dioda LED) według stanu bitu 2 w bajcie 4 w TablizaZPC
}
Zacząłem od sprawdzania poszczególnych kontrolek i tak np. w ET41 zamiast kontrolki jazdy na oporach jest kontrolka sygnalizacji wentylatorów oporów, a w ET22 jak i w EU07 303E nie działa to w ogóle. Kontrolek CA, SHP, styczników liniowych i WSa jak na razie nie udało mi się uruchomić ani w ET41, ani w ET22. Do tego mimo wpisu "mwdbreakenable no", nie daje mi się z klawiatury sterować kran hamulca pomocniczego (zasadniczy działa).
-
Masz tego aktualnego exe-ca? Sprawdzałem przedtem oby dwa i działało ;) Aktualnie są jakieś kończące się prace z przenosinami do Cpp i nie wiem czy nie będzie przerwa na razie.
-
Tak, mam tego z ostatniej aktualizacji. Natomiast za pomocą dołączonego programu testowego doszedłem do tego, że aby odczytać bit 2 bajtu 5, muszę mieć w kodzie wpisane odczytywanie bajtu 8. Podobnie z pozostałymi bajtami - przesunięcie o 3 numerki. Mimo tej poprawki i możliwości ustawienia stanu wyjścia z programu odpowiednim bitem, kontrolka jazdy na oporach nadal nie reaguje z poziomu MaSzyny. Natomiast jeśli dodam do kodu wysyłanie jednego bitu, to wysyła ten bit "impulsowo" (czyli najpierw 1 i od razu 0) na wszystkie bajty:
if(digitalRead(2)==LOW){ //jeśli wejście na pinie 2 ma stan niski (zwarte przycikiem do masy)
TablicaDoPC[3] = TablicaDoPC[3] | (1<<1); //ustawienie bitu 2 w bajcie 3 w TablicaDoPC na 1
}
else{
TablicaDoPC[3] = TablicaDoPC[3] & !(1<<1); //w przeciwnym przypadku na 0
}
Edit: Dodam jeszcze tylko, że kiedy sprawdzam działanie komunikacji na arduinowym monitorze portu szeregowego, to wszystko działa poprawnie. Jedynie zamiast "Serial.write()" muszę używać wtedy "Serial.print()", bo inaczej nic mi nie wyświetla w oknie odbioru danych, ale z kolei przy "Serial.print()" w Twoim programie jest już całkowita dyskoteka - odczytuje chwilowe przesłanie dosłownie każdego bitu po kolei (mimo ustawionych zer w tablicy "DoPC").
Natknąłem się natomiast na coś takiego, jak Arduino DUE. Jego klon kosztuje 1/3 tego co PoKeys (oryginał 169zł), a gdyby zadziałało z MaSzyną, to dałoby znacznie więcej możliwości od PoKeys. Środowisko programowania jest to samo, ale w odróżnieniu od innych Arduin, to oparte jest nie na ATmedze 16MHz, ale na procesorze ARM 84MHz. Posiada 54 cyfrowe wejścia/wyjścia, w tym 12 kanałów PWM, 4 osobne interfejsy UART, jeden I2C, do tego osobno drugi interfejs I2C, 12 wejść analogowych i 2 wyjścia analogowe. Dla "nieznających się", łącznie dwa interfejsy I2C (piny SDA i SCL) pozwalają m.in. zwiększyć ilość cyfrowych wejść/wyjść za pomocą dopinanych układów scalonych o przynajmniej 384 i więcej, jeśli tylko znajdzie się układy z innymi adresami! Do tego pełna swoboda przypisywania sobie poszczególnych wejść/wyjść według własnego uznania (program pisze się samemu - na forum można by wstawić też jakiegoś gotowca dla mniej wymagających) i możliwość dodania innych funkcji w tym samym urządzeniu (obsługa mierników NN, symulowanie efektów świetlnych przy załączaniu/wyłączaniu się sprężarek i co kto sobie jeszcze wymyśli). Więcej szczegółów technicznych dot. płytki na stronie polskiego dystrybutora (https://botland.com.pl/arduino-moduly-glowne/1214-arduino-due-arm-cortex.html).
-
I2C pozwala zaadresować max 128 urządzenia o różnych adresach (od 0 do 127). Jeżeli chcemy zwiększyć ilość elementów na magistrali musimy używać dodatkowych scalaków (np multipleksery I2C). Do zwiększenia ilości wejść/wyjść można wykorzystać SPI i bufory SIPO i PISO. Prędkość mikrokontrolera nie ma większego znaczenia ;)
Funkcja Serial.Printf() najprawdopodobniej posługuje się znakami ASCII, a Serial.Out() wyrzuca bit po bicie tak jak jest w buforze (tablica, struktura).
Co do samego kodu: będę testował dopiero w tygodniu na symulatorze bo nie mam na tyle sprzętu w mieszkaniu.
-
Drodzy czytelnicy i udzielający się w tym wątku.
Postanowiłem zrobić dokumentację w arkuszu kalkulacyjnym znajdującym się TUTAJ (http://pliki.pwsztar.edu.pl/~m_witek/maszyna/)
Plik zawiera opis:wejśćwyjśćwpisów do pliku eu07.iniinformację o używaniu debugowania (kalkulator wartości)
Edit: aktualne linki w pierwszym poście.
-
Według mnie to uK powinien pierwszy rozpocząć komunikację przez wysłanie pierwszego bajtu o wartości np. 0xFF (255). To by otworzyło drogę do Plug & Play.
Przy komunikacji liczą się pojedyncze bajty czyli liczby całkowite, więc wyrzuciłbym wpisy w pliku eu07.ini dla liczb rzeczywistych.
Trzecia rzecz też odnośnie komunikacji, idźmy w Full Duplex czyli transmisję w dwie strony jednocześnie, a nie jak teraz Half Duplex. Nie potrzeba wątków, ale wystarczy wysyłać po bajcie sterującym od uK do maszyny, a maszyna rozpocznie wysyłanie ramki do uK. Arduino ma bufor danych więc nie ma z tym problemów, odczyta to co zostało wysłane kiedy będzie miało czas. (uK - mikrokontroler)
P.S. Includy dla arduino na https://git.eu07.pl/Lakasabasz/Arduino-Maszyna-Port (https://git.eu07.pl/Lakasabasz/Arduino-Maszyna-Port)
-
Według mnie to uK powinien pierwszy rozpocząć komunikację przez wysłanie pierwszego bajtu o wartości np. 0xFF (255). To by otworzyło drogę do Plug & Play.
Moim zdaniem lepiej jednak, kiedy to MaSzyna rozpoczyna komunikację z tego względu, że pulpit (mikrokontroler) jest z reguły połączony przez USB z komputerem przed uruchomieniem się exe MaSzyny i może sobie spokojnie czekać, aż wczyta się jakiś scenariusz i exe zgłosi gotowość do współpracy przez wysłanie pierwszej informacji. W sytuacji odwrotnej potrzebny byłby jakiś dodatkowy przycisk, który wciskałoby się po stwierdzeniu, że scenariusz już się wczytał i uK może nawiązać komunikację z exe.
A czy działa Ci może komunikacja z Arduino na obecnych exe C++ od @tmj? Bo mi od exe++170330 nie działa odbieranie danych z uK, choć @tmj nie wprowadzał w tym czasie żadnych celowych zmian w tym zakresie. Poniżej kod, którego używam w UNO do testów nie zmieniając go i do exe++170330 wszystko działa, a od niego włącznie już nie odbiera informacji z uK...
volatile uint8_t TablicaZPC[31] = {0};
volatile uint8_t TablicaDoPC[17] = {0};
int cleanbuf;
void setup() {
pinMode(13, OUTPUT); //ustawienie pinu 13 (wbudowana w Arduino dioda LED) jako wyjście cyfrowe
digitalWrite(13, LOW); //ustawienie stanu niskiego na pinie 13
pinMode(2, INPUT_PULLUP); //ustawienie pinu 2 jako wejście z podciągnięciem do zasilania
Serial.begin(500000); //nawiązanie komunikacji z prędkością 500000b/s
Serial.setTimeout(10);
while(!Serial){}; //czekanie do nawiązania komunikacji z komputerem
}
void loop() {
//while(Serial.available()){ //jeśli jakieś dane są w buforze
for(byte i=0; i<31; i++){ //pętla umożliwiająca wysłanie 31 bajtów danych
while(!Serial.available()){}; //czekamy na odebranie bajtu danych
TablicaZPC[i] = Serial.read(); //zapis danych do naszej tablicy
if(i < 16){ //zabezpiecznie, żeby nie wysłać za dużo danych do komputera
Serial.flush(); //sprawczanie czy już wysłano wcześniejsze dane (czekanie na wysłanie danych)
Serial.write(TablicaDoPC[i]); // wysłanie danych do komputera
}
}
//}
digitalWrite(13, (bitRead(TablicaZPC[6], 1))); //ustawienie wyjścia 13 według stanu bitu 1 w bajcie 4 w TablicaZPC (kontrolka jazdy na oporach)
if(!(digitalRead(2))){ //jeśli wejście na pinie 2 ma stan niski (zwarte przycikiem do masy)
bitWrite(TablicaDoPC[3], 0, 1); //ustawienie bitu 1 w bajcie 3 w TablicaDoPC na 1 ( zał. baterii)
}
else{
bitWrite(TablicaDoPC[3], 0, 0); //w przeciwnym przypadku na 0
}
delay(10);
}
-
Mój projekt tworzę tak, że pierwsze inicjujesz klasę podając w konstruktorze bitrate, a potem jeżeli chcesz używać innych pinów do UART to rx, tx, jeśli nie to zostaje domyślnie. Gdy zainicjujesz klasę wywołujesz funkcję read(), a ona odczytuje dane z maszyny i porządkuje je do odpowiednich zmiennych. Odczytujesz wartości zmiennych przez getXX(). Więc ten sposób lepiej żeby uK rozpoczynał komunikację.
Nie testowałem biblioteki na "żywca", nie jest jeszcze skończona. Zrobiłem obsługę odczytu danych (funkcja read() i getXX()), ale jeszcze nie ma obsługi wysyłki danych (send())
-
Dotarłem do momentu gdzie w dokumentacji są luki...
Chodzi o to gdzie mają być dane impulsowe, a gdzie ma być stała wysyłka danych. Potrzebuje informacji o przetwornicy, sprężarki, ogrzewania, pantografy, przyciemnienie reflektorów, bateria i światła. Bez tego nie ruszę, bo mogę dla ułatwienia użyć słowa static i to zabezpieczy przed niechcianym wyłączeniu np. przetwornicy.
75% ukończenia projektu. Potem wyślę na git zip i opis jak używać biblioteki.
-
Czyli jednym słowem hebelki? Nie wiem, na jak bardzo robisz "gotowca" pod względem obsługi wejść/wyjść w Arduino, ale jeśli o to chodzi, to prawdziwe hebelki (i włącznik baterii też) mają styki bistabilne, czyli po załączeniu zwierają np. dany pin Arduino do masy przez cały czas, a z kolei exe potrzebuje (przynajmniej z klawiatury) tylko impulsu na załączenie/wyłączenie danego elementu obsługiwanego hebelkiem.
-
Klasa będzie w pełni obsługiwać komunikację. Jedyne funkcje które powinieneś używać to .read() .send() i wszelkiego rodzaju .setXX(). Potem dam rekomendację, aby nadpisać funkcję set() tak aby obsługiwała tylko to co masz na pulpicie. Co by ci tu jeszcze powiedzieć? Nie będziesz musiał się babrać w tablicach i wyszukiwać odpowiedniego bitu danych.
Edit: I tak nie ruszę bez danych standardu komunikacji od maciek001. Proponuję nazwać ten standard MaszCOM ver 1 :D
-
I będzie to wprowadzone do gałęzi rozwojowej @tmj, żeby można było korzystać ze wszystkich nowych możliwości exe C++? Jak tak, to świetnie :-D Bo teraz próbuję coś sklecić z Arduino DUE i PoKeys jednocześnie, ale najlepsze exe, jakie mam do dyspozycji z działającą komunikacją jest z 26 lutego...
EDIT: Aha, jak byś mógł, to dodaj też od razu możliwość zmiany prędkości transmisji jak u maćka001, bo np. takie Arduino DUE ma logikę na 3,3V i przy domyślnych 500000bd/s robią się straszne zakłócenia i musiałem obniżyć, puki co na standardowe dla Arduino 9600bd/s.
-
Nie, to będzie biblioteka na arduino. Maciek tworzy standard i wprowadza obsługę od exe, a ja stoję po drugiej stronie i na podstawie dokumentacji standardu przygotowuję bibliotekę do arduino (i innych uK obsługujących arduino ide), która zajmuje się całą komunikacją. U nie ma "domyślnej prędkości", przy konstruktorze klasy z automatu musisz podać prędkość, albo kompilator cię nie puści.
https://git.eu07.pl/Lakasabasz/Arduino-Maszyna-Port (https://git.eu07.pl/Lakasabasz/Arduino-Maszyna-Port)
Tam masz to co udało mi się napisać. To dwie klasy, ale postaram się uprościć obsługę drugiej do maksimum, tak abyś musiał używać jednej, głównej. Jutro jadę na wczasy więc nie będę nic commitował przez 2 tyg, ale nadal czekam na uwagi w sprawie kodu i oczywiście czekam na Maćka aby podał mi hebelki.
-
Ok, przetestuję w przyszłym tygodniu, bo po jutrze jadę z pulpitem do Chabówki ;) A ze standardową prędkością przesyłu danych w Arduino chodziło mi o to, że 9600bd/s to najczęściej spotykana prędkość w przeróżnych przykładach i stąd określiłem ją jako standardową.
-
Projekt dead?
-
Cały czas lecą poprawki na gicie. Czemu projekt ma być dead?
-
Poczytaj poprzednie posty. Stanęło na tym że w dokumentacji brakuje paru szczegółów co uniemożliwia dalszą pracę, a autora niema od wakacji więc...
No chyba że ktoś aktywny przejmie projekt.
-
Sorki! Żyję :) Prace trwają z pomocą milek7. Aktualnie podstawowe rzeczy w ET22 (bo na tym mam jak testować) działają. Podstawowe mam na myśli pulpit (bez przełącznika hamowania). Najnowsze exe dostępne pod adresem: https://ci.appveyor.com/api/buildjobs/yoh3vc3f007wb9u9/artifacts/builds%2Fbuild_win64%2FRelWithDebInfo%2Feu07%2B%2Bng.exe
Wczoraj pulpit jeździł na Małopolskiej Nocy Naukowców na PWSZ w Tarnowie.
Co zostało przerobione:
- normalne sterowanie (nie ma już emulacji klawiatury)
- wykorzystana biblioteka opensource zamiast windowsowskiej - czy będzie działać na innych systemach? chyba tak.
- zmiana w parametrach z pliku eu07.ini (update już niedługo)
//uart <nazwa portu> <nie zmieniać> <częstość wysyłania danych (czas)>
uart COM3 500000 0.1 0.05
//uarttune <ham. zespolony min> <max> <ham. dodatkowy min> <max> <ciśnienie max w zbiorniku gł.> <max wartość dla PWM> (to samo dla przewodu gł i cylindrów hamulcowych)
uarttune 46.0 943.0 175.0 874.0 0.9 1023.0 0.7 1023.0 0.5 1023.0 4000.0 1023.0 800.0 1023.0
//uartfeature <nastawnik> <bocznik> <hamulec> <hamulec lokomotywy>
uartfeature no no yes yes
//uartdebug <wyświetlanie danych debugowania w konsoli>
uartdebug no
-
maciek, wracając do poprzedniego problemu: potrzebuję odpowiedzi na pewne pytania
Dotarłem do momentu gdzie w dokumentacji są luki...
Chodzi o to gdzie mają być dane impulsowe, a gdzie ma być stała wysyłka danych. Potrzebuje informacji o przetwornicy, sprężarki, ogrzewania, pantografy, przyciemnienie reflektorów, bateria i światła. Bez tego nie ruszę, bo mogę dla ułatwienia użyć słowa static i to zabezpieczy przed niechcianym wyłączeniu np. przetwornicy.
Mógłbyś dodać te informacje do dokumentacji? Byłbym bardzo wdzięczny
-
Nie rozumiem pytania. Pod tym względem dokumentacja jest chyba poprawna.
Można zobaczyć do implementacji w obecnym exe, jest dosyć bardziej czytelna od starej.
https://github.com/Milek7/maszyna/blob/lua/uart.h
https://github.com/Milek7/maszyna/blob/lua/uart.cpp
-
Szanowna administracjo, proszę o czytanie poprzednich postów, ale jeżeli tak bardzo nie chcecie to przypomnę o co chodzi:
maciek001 implementuje mechanizm komunikacji przez port COM w maszynie i prowadzi dokumentację protokołu komunikacji. Ja aktualnie czekam, aż maciek uzupełni pewne fragmenty swojej dokumentacji, abym mógł dokończyć bibliotekę. Dokumentacja nie precyzuje "hebelków", które w maszynie są impulsowe, a w prawdziwym pulpicie bistabilne. Ja nie wiem czy przy każdym wysyłaniu aktualizacji wysyłać sygnał wysoki np. dla pantografów, czy tylko wystarczy raz, a potem drugi, aby je opuścić.
Kod w implementacji na git może być zmieniany z godziny na godzinę, a zmiany w dokumentacji będą wymuszały zmianę wersji całego protokołu komunikacji, przez co ja będę mógł pracować w swoim tempie dostosowując się do aktualnej dokumentacji, a implementacja na git w swoim.
-
Działanie hebelków odpowiada rzeczywistemu stanu przełącznika na pulpicie, zależnie od tego jakiego jest rodzaju w symulowanej lokomotywie.
-
Dokumentacja nie precyzuje "hebelków", które w maszynie są impulsowe, a w prawdziwym pulpicie bistabilne. Ja nie wiem czy przy każdym wysyłaniu aktualizacji wysyłać sygnał wysoki np. dla pantografów, czy tylko wystarczy raz, a potem drugi, aby je opuścić.
Typ przelacznikow po stronie exe zalezy od konfiguracji kabiny danego pojazdu. Jaki by on nie byl, instrukcje odbierane przez exe to z reguly "zmiana stanu urzadzenia X" wiec nie ma potrzeby wysylac polecen bez przerwy, a jedynie gdy zachodzi potrzeba przelaczenia urzadzenia z jednego polozenia w drugi.
-
"zmiana stanu urządzenia" jest zawsze przy sterowaniu z klawiatury, ale w przypadku interfejsu UART sterowane jest rzeczywiste położenie przełącznika. (czyli przy hebelku bistabilnym żeby podnieść pantografy trzeba trzymać bit cały czas, w przypadku impulsowego tylko w momencie załączenia).
-
No chodzilo mi o przesylanie instrukcji z modulu obslugi pulpitu do reszty exe, nie o wymiane miedzy modulem i fizycznym pulpitem. Z pytania dosc ciezko wywnioskowac o ktore faktycznie chodzi.
-
@Łakasabasz Witam wszystkich, czy biblioteka komunikacyjna dla arduino powstała? Czy autor dodał już rekomendację do ustawiania odpowiedniego pulpitu? I gdzie można znaleźć tą bibliotekę?
Dzięki za odp.
-
@adi-edu hmm biblioteka powstała do połowy czyli obsługuje poprawne odbieranie stanu z symulatora, niestety obsługi wysyłania danych do symulatora nie udało mi się napisać. Biblioteka nie była testowana, ale w związku z zainteresowaniem tym tematem podejmę pracę nad odświeżeniem kodu.
@maciek001 mógłbyś mi wysłać aktualną dokumentację komunikacji?
@Administrator/Deweloper czy jest dostępna jakaś platforma do kontroli kodu czy mam korzystać z github? git.eu07.pl nie działa, może macie jakieś plany z tym?
-
Nie ma, używaj githuba.
-
Proponowałbym wyczyścić ten temat i napiszę wszystko jeszcze raz od nowa. Co o tym myślicie?
-
Jestem za, bo z punktu widzenia nowicjusza w temacie jest trochę namieszane ;)
P.S. PANOWIE - wielkie dzięki za kawał dobrej roboty!!! :D
-
Wracam do domu 6.08.br. i będę skrobał całość jeszcze raz. W pierwszym poście zrobię edit jak się da i napiszę jeszcze raz wszystko przejrzyście.
-
O i dobrze
-
I jak Panowie, ruszyło się coś w temacie?
Dodatkowo pytanie o wasze sposoby na fizyczny nastawnik jazdy np EN57? Tzn. Jak sczytujecie położenie do mikrokontrolera?
-
Troszkę cierpliwości. Mam teraz trochę pracy. Kilka osób już pracuje nad kodem dla Arduino. W dziale "Nastawnik/Pulpit do komputera - Wskazówki i gotowe projekty" można poczytać co nieco na ten temat. Postaram się szybko naskrobać coś sensownego choć może być mało jasne ;)
-
Gdzie jest ta dokumentacja ?
Bo nigdzie znaleźć nie mogę
-
Witam, jakieś nowości odnośnie projektu?
-
Witam i przyłączam się do pytania.
Czy w ostatniej wersji symulatora 19.04 komunikacja przez uart odbywa się bez problemów?
I gdzie można znaleźć dokumentację odnośnie wymiany danych?
Bo generalnie plik moich marzeń linkowany w tym wątku - http://pliki.pwsztar.edu.pl/~m_witek/maszyna/ (http://pliki.pwsztar.edu.pl/~m_witek/maszyna/) - jest 503 forbidden
Da się coś z tym zrobić? Albo może ktoś sobie zapisał?
-
Jestem po testach metodą prób i błędów, zbudowaniu testowego pulpitu i mogę odpowiedzieć sobie na pytania. Może ktoś skorzysta...
Tak, komunikacja przez uart z Maszyną w wersji 19.04 działa.
Generalnie komunikacja odbywa się wg schematu opisanego w pierwszym poście tego wątku (te poskreślane). Poza jednym wyjątkiem - sygnał z nastawnika, bocznika i hamulców trzeba wysyłać o jeden bajt wcześniej.
Pojawiły się za to nowe pytania. Ktoś wie w którym miejscu Maszyna oczekuje od kontrolera pozycji nawrotnika??
No i po raz kolejny apeluję o udostępnienie dokumentacji dot. komunikacji z Maszyną po uart, jeśli ktoś posiada.
-
Pojawiły się za to nowe pytania. Ktoś wie w którym miejscu Maszyna oczekuje od kontrolera pozycji nawrotnika??
Nie ma obecnie wyciągniętego osobnego parametru. Można podpiąć sterowanie pod polecenia reverserincrease i reverserdecrease w konfiguracji eu07_input-uart.ini
Do informacji jak działa komunikacja można popatrzeć do kodu:
https://github.com/eu07/maszyna/blob/master/uart.cpp
https://github.com/eu07/maszyna/blob/master/uart.h
-
Dzięki za odpowiedź. Nawrotnik ogarnięty.
Ale pojawił się problem z nastawnikiem.
Odczytuję jego pozycję z potencjometru, mapuję z zakresu przetwornika 0-1023 na 0-42 i wysyłam:
TablicaDoPC[6] = map(analogRead(A1), 0, 1023, 0, 42);Po uruchomieniu symulatora wygląda obiecująco. Koło nastawnika wirtualnej kabiny obraca się razem z moim potencjometrem w całym zakresie. Tylko po uruchomieniu lokomotywy nie ma jazdy. Zadaję pozycję i... nic się nie dzieje. Problem nie występuje po "odłączeniu" nastawnika w pliki eu07.ini i sterowaniu klawiaturą. Moja idea chyba nie jest zła bo identycznie mam zrealizowany bocznik (tylko w zakresie pozycji 0-6) i działa. Problem nie jest sprzętowy, bo zamieniałem je miejscami. Z bocznikiem działa, z nastawnikiem nie. Co ciekawe, kiedy mapuję nastawnik tylko na 6 pozycji, to mogę ruszyć. Co więc robię źle? Jest jakiś warunek, którego nie spełniam, że nie mogę ruszyć? Dlaczego jeśli wysłam liczbę z zakresu 0-6 to jadę, a jeśli z zakresu 0-42 to nie? Nawet jeśli pozycję nastawnika mam zmapowaną dla przedziału 0-42, a potem podaję nawet pierwszą pozycję, to też nie mogę ruszyć.
Niestety nie jestem przesadnie biegły w programowaniu, stąd może głupie pytania... Ze znalezieniem w kodzie informacji, że coś "idzie" na szóstym bajcie, a nie na siódmym sobie poradziłem. A tego nie mogę ugryźć.
-
Przypadkiem wpadłem na genialne w swojej prostocie rozwiązanie problemu. Zwyczajnie nie mogą być jednocześnie włączone programy ArduinoIDE i Maszyna, bo się gryzą i powstaje taki oto efekt. Nie było pytania. Jadę dalej...
-
Pytanie do EXEkoderów. Chciałbym się przymierzyć do podłączenia rysików Haslera i widziałem, że są zarezerwowane bity na tę okoliczność (bajt 6 bity od 0 do 4). W tej chwili mam wrażenie, że tylko jazda pod prądem (B6b4) oraz hamowanie, ciśnienie w cylindrze hamulcowym (B6b3) są wyprowadzone. Ktoś mógłby to potwierdzić i jeśli tak to jest to czy pozostałe wyjścia można byłoby dopisać? Wg dokumentacji możliwości jest sporo ale ja dla przykładu mam Haslera z 5 dodatkowymi zapisami (1 pojedynczy i 2 podwójne opisane jako 5 ELR). W takiej konfiguracji można zapisać poza jazdą pod prądem/bez prądu oraz hamowanie (to co jest teraz), także przejechanie nad rezonatorem SHP z rozróżnieniem kierunku jazdy oraz kasowanie CA. W zasadzie kasowanie CA mogę ogarnąć poza symulacją, przejechanie nad rezonatorem SHP trochę trudniej ale też raczej mogę choć nie bardzo mogę ustalić, z której kabiny jest jazda bo to jest chyba rejestrowane przy SHP.
-
Obecnie jest: ciśnienie w cylindrze, prąd na silnikach, aktywny radiostop i mruganie/buczenie ca/shp.
-
Hmm to ciekawe, bo ciśnienie i prąd udało mi się zaobserwować ale pozostałych to już nie bardzo. Czy to na wspomnianych bitach bajtu 6 jest czy inaczej?
W sumie to te opcje nie są potrzebne bo kasowanie CA mam skąd wziąć i od biedy najechanie na rezonator (czyli zapalenie lampki SHP) wystarczy. Jedynie problemem jest rozpoznanie z której kabiny jadę, bo tego niestety nie mam jak rozpoznać. Da radę to wyprowadzić na COM, żeby było wiadomo czy jadę z A czy z B?
-
Sama komunikacja trochę ewoluuje i aktualne moje prace związane są bardziej z tą modyfikacją @Milek7.
Postaram się to wszystko odświeżyć i opracować. Mam dużo pracy więc proszę o cierpliwość. Jeżeli ktoś jest ciekawy co jest przesyłane, polecam zobaczyć pliki UART.c na repozytorium.
@Tmj i @Milek7 czy możemy ramkę danych ujednolicić?
-
Postaram sie wrzucic milkowa wersje uart.h/cpp do nastepnej aktualizacji, jesli nic sie przy okazji nie zbobczy.
-
U Milka nie ma chyba tych dodatków, które Ty wprowadzałeś, np. bit przebywania w kabinie A/B.
-
Wydaje mi się, że zmiana kabiny jest u Milka. Częściej korzystam z jego exe i mam poprawny zapis na taśmie.
-
Nie wiem jak na (starszej) paczkowej, ale w biezacej galazce /sim informacja o kabinie jest podawana, to tylko u mnie brakuje dodatkowych elementow :>
-
A dodana jest obsługa lampki przekaźnika różnicowego obwodu głównego? Jest na nią miejsce na 5 Bajcie 3 bicie, między między nadmiarowy przetwornicy a nadmiarowy silników trakcyjnych.
Milek7 ma prędkość na 16 bitach ale bez wartości po przecinku. Co myślicie o tym, aby zwiększyć dokładność prędkości do 0,1km/h? 4 młodsze bity na wartości po przecinku lub prędkość mnożyć x10 i pulpit by już sobie to dekodował.
Aby zachować kompatybilność wsteczną z 8bitową prędkością można zrobić wpis do eu07.ini do parametru uartfeature na koniec z defaultową wartością no. Osobiście twierdzę, że prościej jest mnożyć prędkość x10 i w takiej formie przesyłać bez kombinacji z przesuwaniem bitów.
-
W exe Milka jest dostępny parametr uarttachoscale do wpisania w ini. Podanie mu wartości 10.0 daje takie właśnie rezultaty, jak opisałeś, czyli prędkość jest mnożona razy 10 i dzięki temu podawana z dokładnością do 0,1km/h.
-
xD
Już sam zapominam co dodawałem..
-
W exe Milka jest dostępny parametr uarttachoscale do wpisania w ini. Podanie mu wartości 10.0 daje takie właśnie rezultaty, jak opisałeś, czyli prędkość jest mnożona razy 10 i dzięki temu podawana z dokładnością do 0,1km/h.
Dobrze wiedzieć. Dodam do programu zaraz :)
Milek7 jest więcej takich niespodzianek? ;)
-
Na wyższych bajtach jest też data, godzina, przebyty dystans w decymetrach i numer wybranego kanału radiowego, ale co na którym i jak, to nie pamiętam. Na pierwszych czterech dostaje się 0xEF i tak samo trzeba wysyłać na pierwszych czterech 0xEF. Tylko to jeszcze chyba zależy, które exe. Ja używam w zasadzie tylko simowego, tylko z kolei shadery do niego nie są dostosowane do paczki 20.01, no i nie ma wielu zmian od tmj (choćby zrzucanie powietrza z PG przy wyłączonej baterii).
-
Wersja 20.410 dostala przeszczep modulu komunikacji uart, powinna dzialac tak samo jak galazka sim. Doszla przy okazji sygnalizacja stanu lampki przekaznikow roznicowych (bajt 5, bit 3)
Aktualna zawartosc ramki:
std::array<uint8_t, 52> buffer {
//preamble
0xEF, 0xEF, 0xEF, 0xEF,
//byte 0-1 (counting without preamble)
SPLIT_INT16(tacho),
//byte 2
(uint8_t)(
trainstate.ventilator_overload << 1
| trainstate.motor_overload_threshold << 2),
//byte 3
(uint8_t)(
trainstate.coupled_hv_voltage_relays << 0),
//byte 4
(uint8_t)(
trainstate.train_heating << 0
| trainstate.motor_resistors << 1
| trainstate.wheelslip << 2
| trainstate.alerter << 6
| trainstate.shp << 7),
//byte 5
(uint8_t)(
trainstate.motor_connectors << 0
| trainstate.converter_overload << 2
| trainstate.ground_relay << 3
| trainstate.motor_overload << 4
| trainstate.line_breaker << 5
| trainstate.compressor_overload << 6),
//byte 6
(uint8_t)(
m_trainstatecab << 2
| trainstate.recorder_braking << 3
| trainstate.recorder_power << 4
| trainstate.radio_stop << 5
| trainstate.springbrake_active << 6
| trainstate.alerter_sound << 7),
//byte 7-8
SPLIT_INT16(brake_press),
//byte 9-10
SPLIT_INT16(pipe_press),
//byte 11-12
SPLIT_INT16(tank_press),
//byte 13-14
SPLIT_INT16(hv_voltage),
//byte 15-16
SPLIT_INT16(current1),
//byte 17-18
SPLIT_INT16(current2),
//byte 19-20
SPLIT_INT16(current3),
//byte 21-22
SPLIT_INT16((time.wYear - 1) * 12 + time.wMonth - 1),
//byte 23-24
SPLIT_INT16((time.wDay - 1) * 1440 + time.wHour * 60 + time.wMinute),
//byte 25-26
SPLIT_INT16(time.wSecond * 1000 + time.wMilliseconds),
//byte 27-30
SPLIT_INT16((uint16_t)odometer), SPLIT_INT16((uint16_t)(odometer >> 16)),
//byte 31-32
SPLIT_INT16(lv_voltage),
//byte 33
(uint8_t)trainstate.radio_channel,
//byte 34-48
0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0
};
-
Przetestowane i jest git. Mogę zrezygnować z przełącznika wersji exe i dostosowania się do ramki danych :)
Teraz tylko muszę przerobić kod w Arduino żeby uwzględnić obsługę lampki obwodu głównego z symulatora... ale może poczekam na obsługę (enable/disable) zaworu trójdrogowego... Jest szansa?
I jeszcze pytanie czy lampka przekaźników różnicowych działa tylko na 4E czy też na 303E? Bo mam wrażenie, że na 303E nie świeci.
-
W sensie nie wysyła sygnału na port, czy w którymś modelu kabiny coś skopane? Wszystko jest siódemką, to 4e od 303e nie powinny się absolutnie niczym różnić pod kątem zwracanych danych.
-
To muszę jeszcze raz dokładnie porównać bo na 4E różnicowy działa jak na filmie, a mam wrażenie, że na 303E nie zapala się lampka po popełnieniu. Może coś przegapiłem bo szybko testowałem. Nie było reakcji na symulacji i w związku z tym na pulpicie też się nie zapaliła więc pomyślałem, że 303E ma inaczej niż 4E.
Update. Rzeczywiście to moje niedopatrzenie. Zrobiłem testy jeszcze raz i rzeczywiście różnicowy działa w obu przypadkach.
-
Na wyższych bajtach jest też data, godzina, przebyty dystans w decymetrach i numer wybranego kanału radiowego, ale co na którym i jak, to nie pamiętam. Na pierwszych czterech dostaje się 0xEF i tak samo trzeba wysyłać na pierwszych czterech 0xEF. Tylko to jeszcze chyba zależy, które exe. Ja używam w zasadzie tylko simowego, tylko z kolei shadery do niego nie są dostosowane do paczki 20.01, no i nie ma wielu zmian od tmj (choćby zrzucanie powietrza z PG przy wyłączonej baterii).
W arkuszu kalkulacyjnym są rozpisane ramki w dwie strony.
@Tmj: dorzucam link do Twojego exe.
-
ale może poczekam na obsługę (enable/disable) zaworu trójdrogowego... Jest szansa?
Szansa zawsze jest :>
(komendy sa obslugiwane od wersji 20.416)
-
ale może poczekam na obsługę (enable/disable) zaworu trójdrogowego... Jest szansa?
Szansa zawsze jest :>
Jakbyście coś modyfikowali to dajcie znać na PW to będę czuwał nad aktualizacją plików ;)
EDIT: nie macie wrażenia, że jest trochę bałagan w ułożeniu bitów w bajtach wskaźników? Co o tym myślicie?
-
Aktualny uklad zawartosci ramki, dla wersji 20.701
std::array<uint8_t, 52> buffer {
//preamble
0xEF, 0xEF, 0xEF, 0xEF,
//byte 0-1 (counting without preamble)
SPLIT_INT16(tacho),
//byte 2
(uint8_t)(
trainstate.epbrake_enabled << 0
| trainstate.ventilator_overload << 1
| trainstate.motor_overload_threshold << 2),
//byte 3
(uint8_t)(
trainstate.coupled_hv_voltage_relays << 0),
//byte 4
(uint8_t)(
trainstate.train_heating << 0
| trainstate.motor_resistors << 1
| trainstate.wheelslip << 2
| trainstate.alerter << 6
| trainstate.shp << 7),
//byte 5
(uint8_t)(
trainstate.motor_connectors << 0
| trainstate.converter_overload << 2
| trainstate.ground_relay << 3
| trainstate.motor_overload << 4
| trainstate.line_breaker << 5
| trainstate.compressor_overload << 6),
//byte 6
(uint8_t)(
m_trainstatecab << 2
| trainstate.recorder_braking << 3
| trainstate.recorder_power << 4
| trainstate.radio_stop << 5
| trainstate.springbrake_active << 6
| trainstate.alerter_sound << 7),
//byte 7-8
SPLIT_INT16(brake_press),
//byte 9-10
SPLIT_INT16(pipe_press),
//byte 11-12
SPLIT_INT16(tank_press),
//byte 13-14
SPLIT_INT16(hv_voltage),
//byte 15-16
SPLIT_INT16(current1),
//byte 17-18
SPLIT_INT16(current2),
//byte 19-20
SPLIT_INT16(current3),
//byte 21-22
SPLIT_INT16((time.wYear - 1) * 12 + time.wMonth - 1),
//byte 23-24
SPLIT_INT16((time.wDay - 1) * 1440 + time.wHour * 60 + time.wMinute),
//byte 25-26
SPLIT_INT16(time.wSecond * 1000 + time.wMilliseconds),
//byte 27-30
SPLIT_INT16((uint16_t)odometer), SPLIT_INT16((uint16_t)(odometer >> 16)),
//byte 31-32
SPLIT_INT16(lv_voltage),
//byte 33
(uint8_t)trainstate.radio_channel,
//byte 34-48
0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0
};
Jesli jest zapotrzebowanie na zmiane ukladu, prosze zglaszac.
-
A ja mam takie pytanie bo zrobiłem sobie "atrapę" przedziału maszynowego (https://youtu.be/UBv32-zB9lQ) i wszystko fajnie bo nie muszę bawić się z klawiaturą podczas przechodzenia między kabinami ale niestety nie do końca. Po wejściu do drugiej kabiny stoimy sobie na środku i trzeba użyć myszy, żeby usiąść zanastawnikiem. Czy jest jakaś metoda, żeby te kliknięcia myszą również zrealizować w komunikacji szeregowej?
-
Obawiam sie ze nie bardzo, przynajmniej na razie -- zmiana polozenia kamery przypisana jest na sztywno w exe do przyciskow myszy i nie wykorzystuje systemu komend ktory steruje urzadzeniami pojazdu.
Jakims tam bieda-rozwiazaniem moze byc teoretycznie szamysntwo w postaci edycji pliku mmd pojazdu, i wpisanie tam takich samych parametrow dla driverXpos: i driverXsitpos: W takiej aranzacji kamera po wejsciu do kabiny bedzie umieszczona w tej samej pozycji w jakiej znajduje sie gdy "siadamy" uzywajac prawego przycisku.
-
To mam jeszcze jedno pytanie w kwestii komunikacji szeregowej. Dlaczego po uruchomieniu symulacji i zainicjowaniu komunikacji stany przełączników nie są od razu zgodne z tym co fizycznie na pulpicie jest tylko trzeba przeklikać hebelek lub przełącznik? Przykładowo rodzaj hamulca zgłasza się domyślnie jako osobowy nawet jeśli przełącznik jest w innej pozycji. Dopiero przełączenie go na pulpicie powoduje przestawienie w symulatorze. Wydaje mi się, że bity są transmitowane na bieżąco i spodziewałbym się, że od razu po przesłąniu pierwszej ramki stan przełączników symulatora powinien odpowiadać fizycznemu położeniu tych przełączników na pulpicie.
-
Ma to zwiazek z tym, ze stan przyciskow w danej kabinie ustawiany jest w momencie "wejscia" do niej, na podstawie lokalnego stanu pojazdu. Komendy obslugi urzadzen generowane sa jednorazowo przy stanie zmianu urzadzenia na pulpicie, dlatego tez dopoki taka zmiana nie ma miejsca, symulator w efekcie utrzymuje swoj "stan biezacy".
-
Mi to już od dawna działa dobrze, również na najnowszym (200824) exe @tmj, tzn. jeśli na fizycznym pulpicie przełącznik hamulca jest ustawiony np. na pospieszny, to po wczytaniu symulacji w MaSzynie też ten przełącznik od razu przestawia się na tą pozycję. Przy czym w eu07_input-uart nie używam komend powodujących przełączenie o jedną pozycję w którąś ze stron, ale ustawiających przełącznik w konkretnej pozycji:
toggle brakeactingspeedsetrapid // wybor trybu hamulca dla pociagu pospiesznego
toggle brakeactingspeedsetpassenger // wybor trybu hamulca dla pociagu osobowego
toggle brakeactingspeedsetcargo // wybor trybu hamulca dla pociagu towarowego
-
No to dziwne, ja w eu07_input-uart.ini też tak mam
35 toggle brakeactingspeedsetcargo
36 toggle brakeactingspeedsetpassenger
37 toggle brakeactingspeedsetrapidPo uruchomieniu symulacji startuje na osobowym, tak jak jest bez pulpitu i muszę coś ruszyć, żeby się przestawiło.
-
Dzień dobry.
Panowie, może ślepy jestem, ale gdzie znajdę opis ramki wejściowej (z kontrolera do PC)? Pcham obecnie zera i nie mogę sterować z klawiatury. Patrzenie na LED od SHP już mi się znudziło ;)
Dzięki za snippety w tym wątku - dużo pomogły, bo dokumentacja jest bardzo skromna.
Czy jest gdzieś dostępna ta biblioteka dla arduino? Jakiś GitHub? Zamierzam zbudować pulpit dla dzieciaka i parę wierszy mógłbym do kodu dołożyć.
EDIT:
Odpowiadam sobie po części - zdaje się, że pierwsze bajty zamapowane są wg eu07_input-uart.ini
EDIT 26/05/2021
Aby obsłużyć więcej przełączników na moim Uno w celu testowania proponowanej przeze mnie obsługi świateł, musiałem dołożyć multipleksery do hardware. Kod dla Arduino nieco się skomplikował, zrobił się nieczytelny i przestałem czerpać przyjemność z eksperymentów. A ponieważ będę dokładał więcej klamotów, to nadszedł czas na przygotowanie solidnych fundamentów.
Z tego powodu przerobiłem te moje próby na zalążek biblioteki dla Arduino, do obsługi całego pulpitu (a nawet wielu pulpitów - zależnie od limitów i koncepcji sprzętowych). Kod biblioteki wrzuciłem na Githuba: https://github.com/marcinn/maszynaduino
Biblioteka jest w fazie mocnego rozwoju i przewiduję zmiany w API (szczególnie w kontekście muxów). Głównym celem jest prostota użycia i czytelność kodu, bowiem wszelkie eksperymenty czy testy wymagają skupienia się, a warto skupiać się na "mięchu" a nie na wszystkich "bebechach", szczególnie kiedy ma się bardzo mało czasu na hobby.
Jeśli to kogoś zainteresuje, to zachęcam do zgłaszania sugestii najlepiej przez https://github.com/marcinn/maszynaduino/issues
Opis z przykładem jest w readme dostępnym z pierwszego odnośnika.
Aktualnie pracuję (w miarę możliwości czasowych) nad Maszynaduino v0.2. Będą większe zmiany:
- monitor do diagnostyki po UART (dedykowany program),
- wsparcie dla rejestrów przesuwnych do sterowania kontrolkami (wyjścia),
- ulepszona komunikacja UART z MaSzyną, wraz z synchronizacją i wyeliminowanym opóźnieniem związanym z oczekiwaniem na dane z PC (serial timeout),
- uporządkowana obsługa analogowych multiplekserów (wejścia).
Nie prościej jakieś ekspandery na I2C albo PISO i SIPO i komunikować przez SPI?
W kolejnych wersjach rozważam wsparcie dla układów typu MCP23017. Dotychczas I2C/SPI uważałem za "armatę na muchę", a mój prototyp powstaje w oparciu o rejestry 74595 w szeregu dla wyjść (kontrolki) i mux 74HC4067 dla wejść (przyciski, przełączniki).
-
Tak, to tego pliku można sobie samemu wstawiać wpisy komend z eu07_input-keyboard we własnej kolejności i te, które są potrzebne. A nastawnikami i kranami powinno dać się sterować z klawiatury po zmianie w eu07.ini:
//uartfeature <nastawnik> <bocznik> <hamulec> <hamulec lokomotywy>
uartfeature yes yes yes yes
na:
//uartfeature <nastawnik> <bocznik> <hamulec> <hamulec lokomotywy>
uartfeature no no no no
ale od dłuższego czasu ta funkcja wyłączania obsługi nastawników i kranów nie działa. Pozostałymi urządzeniami zawsze powinno dać się sterować z klawiatury, nawet przy aktywnej komunikacji UART.
-
Cześć.
Czy aby nie brakuje poleceń enable/disable dla tylnych świateł?
Zdefiniowane polecenia to:
headlighttogglerearleft,
headlighttogglerearright,
headlighttogglerearupper,
redmarkertogglerearleft,
redmarkertogglerearright,
Jak włączacie tylne światła hebelkami z pulpitu?
-
No raczej z jednego pulpitu to ciężko sensownie obsłużyć obie kabiny. Ja osobiście ignoruję oświetlenie tyłu. Można też przechodzić między kabinami i załączać co tam potrzeba. To nawet bardziej realne bo w realu raczej nie ma możliwości osygnalizowania obu stron z jednej kabiny. Trochę to dziwnie wygląda, bo trzeba wejść do kabiny, włączyć światła, przejść do drugiej kabiny, wyłączyć hebelki i włączyć znowu ten drugi koniec. W sumie można wyłączyć hebelki podczas przechodzenia, będąc jeszcze w przedziale maszynowym. To powinno zadziałać bo tam hebelki nie zareagują na światła.
-
Ok, rozumiem. Dzięki za wyjaśnienia!
Robię pulpit do stonki (custom, nie replika), a wszystkie heble od świateł są w niej na jednym pulpicie.
-
No tak, przy tych jednokabinowych lokach to inna bajka :)
-
Aby obsłużyć więcej przełączników na moim Uno w celu testowania proponowanej przeze mnie obsługi świateł, musiałem dołożyć multipleksery do hardware.
Nie prościej jakieś ekspandery na I2C albo PISO i SIPO i komunikować przez SPI?
Edit: I jak możesz to scal Swoje wpisy;)
PS: nowa wersja programu do testowania. Na razie nie przejmujcie się komunikatem o linijce kodu w dole aplikacji. Zapomniałem go usunąć ;)
-
Szczerze? Nie wiem jak. Najchętniej usunąłbym większość nic nie wnoszących.
Przycisk "Modyfikuj" w prawym górnym rogu wypowiedzi, obok "Cytuj" ;)
-
Czy w protokole byłoby miejsce na dodatkowe wyjścia cyfrowe na potrzeby ezetów/szynobusów? Przede wszystkim brakuje tu kwestii związanych z zezwoleniami i stanem otwarcia drzwi, ale przydałoby się również podświetlenie wybranego kierunku (tu ogólniej pod asynchrony).
-
Tak, jest na to przewidziane miejsce. Są puste bajty. Pasowałoby kiedyś siąść i zrobić porządek, dodać wszystkie aktualne ficzery itp.
-
Pasowałoby kiedyś siąść i zrobić porządek, dodać wszystkie aktualne ficzery itp.
Mogę się tym zająć.
-
Witajcie, wraz z kolegą podjąłem sie budowy pulpitu, dla państwa symulatora, opierając się na Arduino. Jako że samo zrozumienie ramki do i z Arduino, zajęło dużo nam czasu, to chciałbym podsumować swoją wiedzę i prosiłbym o wskazanie gdzie czegoś nie zrozumiałem, albo pomyliłem. Naturalnie o kilka spraw chciałbym też dopytać.
Przeglądałem państwa wikipedię, ale zatrzymała sie na LPT, o uarcie nic nie widziałem:
https://wiki.eu07.pl/index.php/Informacje_zwrotne (https://wiki.eu07.pl/index.php/Informacje_zwrotne)
Może na początek mały błąd: że świeżo po zainstalowaniu MaSzyny nie ma w eu07.ini linijek uarttune, uartfeature, uartdebug i program startowy nie potrafi ich dopisać, w sensie nie zapisuje tego co tam wpiszę. Ale po dopisaniu stosownych lini, już zmiana poprzez program startowy działa.
Brakujące linijki wziąłem od p. Maćka:
https://baur.pl/soft-do-zmiany/ (https://baur.pl/soft-do-zmiany/)
uart COM3 115200 0.03 0.03
uarttune 26 225 71 236 1.4 255 0.8 255 0.8 255 0.8 255 4000 255 800 255 150 255
uartfeature yes yes yes yes
uartdebug no
Pierwszą rzeczą o którą chciałem dopytać jest "0.03 0.03" w poprzednim poście państwo wspomnieli że to <częstość wysyłania danych (czas)>. Rozumiem że "0.03" to 30ms.
W kodzie programu znalazłem ">> uart_conf.updatetime;", dlatego też nie rozumiem dlaczego "0.03" jest dwa razy. Kiedy wpisałem "0.03" jeden raz program działał tak samo.
uarttune jest skalowaniem wartości, z COM do PC(dla hamulców) i z PC do COM(dla manometrów i mierników) żebym w mikrokontrolerze nie zużywał niepotrzebnie zasobów, na skalowanie wartości.
Czyli p. Maciek ustawił kolejno:
>> uart_conf.mainbrakemin = 26 // Hamulec główny (Train brake)
>> uart_conf.mainbrakemax = 225
>> uart_conf.localbrakemin = 71 // Hamulec dodatkowy (Independent brake)
>> uart_conf.localbrakemax = 236
>> uart_conf.tankmax = 1.4 // Trzeci okrągły manometr - Ciśnienie w zbiorniku głównym(Tank press)
>> uart_conf.tankuart = 255
>> uart_conf.pipemax = 0.8 // Drugi okrągły manometr - Ciśnienie w przewodzie głównym(Pipe press)
>> uart_conf.pipeuart = 255
>> uart_conf.brakemax = 0.8 // Pierwszy okrągły manometr - Ciśnienia hamulców (Break press)
>> uart_conf.brakeuart = 255
>> uart_conf.pantographmax = 0.8 // (Domyślam się, nie sprawdziłem) Ciśnienie pantografu (pantograph press)
>> uart_conf.pantographuart = 255
>> uart_conf.hvmax = 4000 // Piąty prostokątny miernik - Napięcie od pantografu (HV voltage)
>> uart_conf.hvuart = 255
>> uart_conf.currentmax = 800 // Trzeci i czwarty prostokątny miernik - Prąd silników (HV current 1 oraz HV current 2)
>> uart_conf.currentuart = 255
>> uart_conf.lvmax = 150 // Drugi prostokątny miernik - Napięcie baterii (LV voltage)
>> uart_conf.lvuart = 255
W okrągłych nawiasach jest nazwa z opisu ramki danych "20220910 Maszyna UART.xlsx" z pierwszego wpisu.
Niestety ciśnienia pantografu nie sprawdziłem, próbowałem, ale te wskazanie ani drgnęło podczas testowej jazdy.
Czyli w ramach hamulców głównego(mainbrake) i lokomotywy(localbrake):
jeżeli mój potencjometr daje wartości od 70 do 180 to ustawię:
>> uart_conf.mainbrakemin = 70 // <- minimalna pozycja hamulca
>> uart_conf.mainbrakemax = 180 // <- maksymalna pozycja hamulca
a MaSzyna sama przelicza ile powinna ustawić, na podstawie otrzymanej wartości.
Z kolei tank, pipe, brake, pantograph, hv, current, lv to prostokątne i okrągłe mierniki na symulacji.
I działa to tak że '***max' to skala górna jaką mamy na mierniku fizycznym, a '***uart' to największa liczba jaką wpisuje np. jako wypełnienie PWM w Arduino.
Czyli jak dla prądu pierwszego zestawu silników (HV current 1) mam skale 1200A,
a maksymalne wypełnienie PWM w Arduino mam 65535(to tylko przykład, normalnie jest 255) to wpiszę:
>> uart_conf.currentmax = 1200
>> uart_conf.currentuart = 65535
i dostanę od maszyny liczbe "gotową" wyskalowaną wartość, którą nie musze przekształcać i wpisuje bezpośrednio do wypełnienia PWM.
uartfeature <nastawnik> <bocznik> <hamulec> <hamulec lokomotywy>
jest prosty: jeżeli jest "yes" to wartość wysłana z Arduino do MaSzyny jest wiodąca i nie można ustawić z klawiatury bo ta nastawa będzie nadpisywana. Jeżeli "no" to wartości z Arduino nie będą brane pod uwagę i sterowanie wiodące jest z klawiatury(w przypadku nastawnika i bocznika jeszcze można sterować za pomocą "Switch group", wtedy też jest na "no" w uartfeature).
Wspomniane cztery nastawy wysyłamy zgodnie z "20220910 Maszyna UART.xlsx" -> Data from pulpit to MaSzyna
<nastawnik> -> Master controller: podajemy liczbe od 0 do 43 i jest to aktualna pozycja.
<bocznik> -> Second controller: podajemy liczbe od 0 do 7 i jest to aktualna pozycja.
<hamulec> -> Train brake: podajemy odczytaną wartość analogową, MaSzyna sama ją wyskaluje za pomocą uarttune.
<hamulec lokomotywy> -> Independent brake: podajemy odczytaną wartość analogową, MaSzyna sama ją wyskaluje za pomocą uarttune.
Wspomniane wcześniej "Switch group" koreluje z "eu07_imput-uart.ini"
Switch group to 48 bitów sterujących(Z arduino DO MaSzyny) gdzie w "eu07_imput-uart.ini" wpisujemy numer bitu, rodzaj akcji, akcje. Akcja jest taka same jak w "eu07_input-keyboard.ini", więc wysłanie ustalonego bitu z Arduino do MaSzyny wywołuje akcję, którą normalnie możemy zrobić skrótem klawiszowym.
Rodzaje akcji są dwie impulse(guzik) oraz toggle(przełącznik). Po "impulse" dajemy jedną akcje, po "toggle" dwie akcje, pierwsza będzie wykonana kiedy bit jest '1', druga kiedy bit jest '0';
Na podstawie przykładu programu z wcześniejszego wpisu napisałem program na kilka podstawowych kontrolek/przełączników, oraz nastawnik i bocznik, na Arduino:
https://github.com/kaczor112/SterownikKontrolekMaSzyna (https://github.com/kaczor112/SterownikKontrolekMaSzyna)
Niestety nie wiem dlaczego działa mi tylko dla prędkości 9600.
Nie potrafię sie komunikować z MaSzyną dla innych prędkości nawet 19200,
jeżeli ktoś z państwa ma na to radę to bardzo bym prosił o pomoc!
Niestety nie znam za dobrze angielskiego i przy czytaniu "20220910 Maszyna UART.xlsx" brakowało mi go.
Jeżeli mają państwo jakąś rozpiskę co jest czym, angielsko - polską to bardzo bym prosił.
Chodzi mi wyłącznie o "Indicator group 0-4", bo do pozostałych, jak widać wyżej już doszedłem(Hasler to 'Tacho').
Na chwilę obecną wiem że:
alerter - czuwak
line breaker - lampa wyłącznika szybkiego
motor resistors - lampa jazdy na oporach
Jeżeli ma ktoś z państwa rozpisane te bity również po polsku, to ułatwiłoby to nam zadanie!
Zdaje sobie sprawę że moja wiadomość nie wnosi nic nowego.
Może jedynie stanowić małe ułatwienie dla przyszłych nowicjuszy jak ja.
A ja będę miał zysk taki że upewnię sie czy wszystko dobrze zrozumiałem,
naturalnie proszę o podpowiedź gdzie coś sknociłem.
Brakuje mi jeszcze do pierwszego prostokątnego miernika(prąd ładowania akumulatora z przetwornicy), wiedzieć który sygnał(Data from MaSzyna) od MaSzyny jest właśnie dla niego.
Bardzo dziękuję za wszelką podpowiedź!
-
Wpisy uart do eu07.ini można wygenerować MVD SerialPort Testerem.
Odnośnie tłumaczenia arkusza to na szybko machnąłem na podstawie tamtej anglojęzycznej wersji to:
https://docs.google.com/spreadsheets/d/1Vfiz9cuiguorj52YouhP_floWe6zszJxulRkOrARFt4/edit?usp=sharing
Odnośnie danych z pulpitu do symulatora to funkcje przypisujemy w pliku eu07-input_uart.ini. Polecenia można zaczerpnąć z eu07-input_keyboard.ini (tam są opisane). Składnia wygląda nastepująco
(numer bitu z grup) (impulse/toggle) (komenda) [komenda alternatywnie w przypadku toggle]Numer bitu z grup można również odnaleźć w MVD SerialPort Testerze.
Niestety nie wiem dlaczego działa mi tylko dla prędkości 9600.
Wystarczy w tej linijce zmienić prędkość transmisji i powinno zatrybić. (https://github.com/kaczor112/SterownikKontrolekMaSzyna/blob/6e5b7be21d578053aa6e0d0d5ebb5ddd4174ceaa/SterowanieKontrolek_v2/SterowanieKontrolek_v2.ino#L59)
Jakbyś potrzebował pomocy z czymś więcej, to możesz do mnie uderzyć śmiało na prywatnej wiadomości - najwyżej się wymienimy jakimś bardziej "chatowym" kontaktem to pomogę, na ile będę potrafił.
-
Przeglądałem państwa wikipedię, ale zatrzymała sie na LPT, o uarcie nic nie widziałem:
https://wiki.eu07.pl/index.php/Informacje_zwrotne (https://wiki.eu07.pl/index.php/Informacje_zwrotne)
Cześć,
sprawdź informacje w pierwszym poście. Znajdziesz tam linki do pomocy :) W Wiki dodałem właśnie link do tego wątku.
Co do prędkości UART-u to pokaż kod w Arduino. Pewnie tam masz ustawione na 9600. Musisz wpisać taką samą wartość w Arduino i w Maszynie.
Ładowanie baterii nie wiem czy jest obsługiwane.
-
Hej, bardzo dziękuję za wszelką pomoc! Najbardziej Hirkowi który jeszcze ze mną pisał prywatnie.
Udało mi się opanować na tyle tą komunikację, że napisałem poradnik do nowicjuszy jak ja, żeby mieli prościej.
https://pawelkaczmarczyk.pl/maszynauart-komunikacja-podstawowa-38/ (https://pawelkaczmarczyk.pl/maszynauart-komunikacja-podstawowa-38/)
Za wszelkie uwagi też bardzo dziękuję, chce też żeby ten poradnik był "sprawdzonym" źródłem.
-
Witam piszę z zapytaniem odnośnie tego poradnika Czy dałoby się zrobić pulpit na dwóch mikrokontrolerach? ponieważ posiadam dwa PRO Micro ATmega32U4 Leonardo one małą łącznie 16 pinów (nie licząc 3 pinów GND, RXI, RAW itd) tylko same 2,3,4,5 A1, A2 itd. nie wiem czy dam rade na 16 pinach zrobić cały pulpit siódemki. Tak więc wracając do mojego pytania czy dałoby się to zrobić na dwóch jeżeli tak to jak? czy jednak kupić jeden większy.
Pozdrawiam!