0x8000ffff Posted 1 hour ago Posted 1 hour ago 1 godzinę temu, error723 napisał(a): Wiem, chciałeś swoje zdanie dołożyć, dołożyłeś - tak w kwestii emocjonalnych uniesień, do których się odwołujesz. No chciałem, zaspokoiłem też swoją potrzebę przekazania z własnego doświadczenia, że można to zrobić prosto, bez przerostu formy nad treścią, przynajmniej w Maszynie to moim zdaniem wystarcza. Automatyka czy elektronika to moje hobby, nie usiłuję udawać że wiem czegoś, czego nie wiem. Nie lubię też gdy inni usiłują w dyskusji wywierać wrażenie ekspertów, bo nikt nikomu dyplomu czy świadectw kwalifikacyjnych nie przedstawiał. Może za MQTT przemawiają jakieś argumenty, jeśli projekt o który toczy się dyskusja miałby pełnić szersze funkcje niż fizycznego pulpitu zastępującego klawiaturę i przyrządy na ekranie, ale odniosłem wrażenie, że dyskusja jest o owym pulpicie z kontrolkami i wskaźnikami.
error723 Posted 1 hour ago Posted 1 hour ago Rozszerzę i może się to komuś przyda przy własnej przygodzie z budową panelu pod proponowane rozwiązanie z MQTT. Broker będzie uruchomiony na Twoim hoście, będąc wpięty do silnika gry, czyli jego latencja to 1-5ms(?) - wiadomości możesz odbierać już na swoim PC czyli nadal możesz stworzyć adapter, którym obsłużysz MIDI (jest to narzut, ale można jak ktoś chce - można także podpiąć RPi0 jako HID, a można spiąć małe ESP32 bezpośrednio z brokerem). I tutaj masz dowolność, czy podepniesz panel po lan, wi-fi, czy rs... każde medium to obsłuży bo jest jedynie pośrednikiem. Czyli model wygląda tak: panel -> wi-fi/lan -> localhost broker (wbudowany w SR) -> silnik gry. W takim ujęciu zapchanie kolejki brokera może być spowodowane złą implementacją własną, notify wywoływane jest jedynie przy zmianie stanu, a nie odpytywanie o każdy element kilka razy na sekundę. Działasz na zasadzie "słucham i reaguje na subskrybowane zdarzenia", nie mnie, nie więcej. Nie, nie ma mowy, że w takim ujęciu zapchasz kolejkę brokera i przez to hamulec zacznie działać po 100ms czy więcej. Tutaj trzeba dodać, jeden broker może obsługiwać wiele kolejek, a to pozwala na to, że notify=hamulec będzie mieć priorytet nad notify=ustawŚwiatłoReflektoraGórnegoStanWłączone. Oczywiście, że nie zaprojektowałbym takiego rozwiązania w urządzeniach typu hard real-time, ale to jest symulator, gra i tutaj przede wszystkim ważne jest to, by jak najwięcej osób było w stanie samodzielnie wykonać zewnętrzne urządzenia bo to pozwoli na rozwój samego produktu - jasne, że chciałbym by było to jak najbardziej skomplikowane, mógłbym zarobić na budowie takich paneli, ale z perspektywy wydawcy, lepiej by chodziły w sieci samouczki z przykładami lub gotowymi rozwiązaniami. MQTT to inny poziom abstrakcji w ujęciu "komunikacja" i to jest kluczem w tej propozycji - niezwykle łatwo to rozszerzyć o kolejne pojazdy, nawet jeśli miałyby nowe elementy do obsługi. Ba, właściwie można przygotować API do każdego elementu w grze oddzielnie, przez co każda lokomotywa byłaby obsługiwana przez dedykowane wiadomości dzięki czemu unikamy konfliktów. Uniwersalność i prostota, a zarazem rozszerzalność - i podkreślam, to jest symulator, tutaj nikt nie zginie jeśli hamulec awaryjny zacznie działać z opóźnieniem 10, 50 czy nawet 100ms!
Recommended Posts