MicroCity Smartcontrol

[microcity]

Możesz zamieścić chociaż screen, jak wygląda taka aplikacja, panel sterowania, czy to jakieś wirtualne przyciski, można je samemu konfigurować, np w grupy?
(Nie mam FB i nie chce zakładać)
Dla siebie widział bym Twój system w roli sterowania (nadrzędnego)moim systemem na zasadzie komunikacji między pulpitem, a makietą.
Wystarczyły by mi ekspandery z możliwością podawania na wyjściach stanu niskiego, stabilnego / chwilowego.
Konfiguracja każdego wyjścia wg mojego widzi mi się. Jest taka możliwość?

Na tą chwile nie mam jeszcze oprogramowanego interfejsu wejść z wykorzystaniem expandera, ale taki punkt jest na liście wdrożeniowej

Idea zakłada również, aby system był kompatybilny z fizycznymi analogowymi pulpitami i to da się zrobić właśnie za pomocą expandera/pinów IN.

Na tą chwilę działamy tylko na "wyjściach", możesz konfigurować zwrotnice i oświetlenie wg swoich potrzeb bez ograniczeń i masz do dyspozycji albo stałe wyjście arduino (PINOUT) lub poprzez PWM z wykorzystaniem PCA9685. Za ich pomocą możesz konfigurować obsługe serwomechanizmów (dla zwrotnic, szlabanów, itd) oraz oświetlenia z wykorzystaniem diody led.

Sekcje oświetleniowe również możesz konfigurować dowolnie, dla przykładu mamy bocznicę kolejową która ma 7 latarni, każdą latarnie wpinamy pod oddzielny slot na PCA i każdą latarnią możemy sterować indywidualnie lub grupowo.

Wtedy mamy możliwość np pod jednym przyciskiem "Bocznica Kolejowa" włączyć oświetlenie na całej bocznicy.
A np w innej konfiguracji np. Bocznia sektor 1 (3 latarnie) i Bocznica sektor 2 (4 latarnie) masz wtedy dwa przyciski które aktywują dany sektor.
Dodatkowo jest jeszcze opcja aby każda latarnia = dioda led = slot w PCA miał indywidualny efekt świetlny, np wł/wył, powolne zapalnie/gaszenie, stroboskop, jasność diody itd. A w niedalekiej przyszłości udostępnię moduł nad którym już pracuje do definiowania własnych efektów świetlnych, da to możliwość tworzenia iluminacji, czy efektów specjalnych takich jak zepsuta żarówka w latarni, spawarka, dyskoteka itd

Już niebawem będzie moduł do obsługi semaforów z wykorzystaniem PCA9685 lub ShiftRegister, tworzenia tras przebiegów i innych wiele funkcji
No i oczywiście wszystkie opcje sterowania dostępne z wirtualnego planu makiety

Jeżeli chodzi o film prezentujący, to muszę taki przygotować (chwilowy brak czasu), ale jak założysz konto na www.microcity.app to w centrum pomocy znajdziesz video w którym prezentuje całą aplikację krok po kroku (niestety tutaj nie da się dodać załącznika w formie mp4)

A co do grupy na FB, właśnie ze względu na to że nie każdy ma konto na FB, będzie nowa zakładka na stronie www Blog/Forum.

 

[Lucky]

Całkiem ciekawe, ale czy się przyjmie. Zobaczymy.
Przede wszystkim taki system od lat istnieje, nazywa się gbb kolejka i - co ważne - współpracuje z systemem DCC, który wszyscy "cyfrowi" modelarze już mają.
Twój będzie działał tylko we własnym obrębie, a zapewniam Cię, że nikt nie zrezygnuje z DCC, a korzystanie z dwóch kompletnie różnych systemów cyfrowych na makiecie mija się zupełnie z celem.

Może inaczej, u mnie będą dwa systemy, DCC do lokomotyw i standardowy system analogowy (przyciski, czujniki położenia rozjazdów itd) do całej reszty.

Takie przykłady:

Przejazd kolejowy - działa automatycznie, zbliża się pociąg, załącza się sygnalizacja.
(Nie potrzebuje sterowania z zewnątrz)

Latarnie - włączane/wyłączane lokalnie / czy choćby czujnikiem zmierzchowym (całe grupy). Symulacja uszkodzonej żarówki (mały układ zamontowany przy jednej z latarni) to też nie potrzebuje rozbudowanego sterowania.

Semafor - a i owszem, to ja naciskam guzik "droga wola", ale...
O tym co się wyświetli, już decyduje system (zależnie od położenia rozjazdów i stanu następnego semafora), a do tego potrzebuje tylko podania GND z przycisku na pulpicie.

Takie zaświecanie każdego światła jakie się chce na semaforze jest zupełnie nie realne w rzeczywistości.

Rozjazdy - to samo, krótki impuls z pulpitu.

Widzę natomiast twój system jako pośredniczący między pulpitem, czy to fizyczne guziki, czy to pulpit wirtualny - a makietą.

Pod ręką mam załóżmy 40 guzików i część twojego systemu. Od pulpitu do makiety biegną trzy przewody SDA, SCL i Gleba.

Na makiecie druga część twojego systemu z ekspanderami.

Albo pulpit to tablet, łączność bezprzewodowa z makietą, na makiecie Arduino i ekspandery, które sterują już czym tam chcesz.

Tyle, że to rozwiązanie dla analogowcow, dla zredukowania ilości kabli między pulpitem, a makietą.

Tak jak mówię, z DCC na pewno nikt nie zrezygnuje.

No ale powodzenia

 

[t_domagalski]

Aplikacji się nie kupuje, ponieważ aplikację udostępniam za free. Nie zarabiam na tym.
Cały czas go rozbudowuje i ulepszam głównie na własne potrzeby..

Nie chcę być złym prorokiem, ale....
Przed tobą było już kilka projektów takich systemów, które miały zapewnić prostą i modularną obsługę makiet. Ot, choćby Wajchownia. Projekty te jednak "umierały" w sytuacji, gdy ich twórcy zmieniali pracę, żenili się lub rodziły im się dzieci, czyli generalnie wtedy, kiedy przestawali mieć czas na hobby.

Jednak o ile w przypadku starszych rozwiązań typu standalone lub embeded można było z nich dalej korzystać pomimo braku wsparcia (usuwanie bugów, obsługa nowego sprzętu), to w przypadku twojego projektu widzę nowe i spore zagrożenie. Co będzie, jak któregoś dnia zaprzestaniesz opłacać subskrypcję chmury Azure? Co się wtedy stanie z projektami użytkowników twojej aplikacji mobilnej?
Domyślam się, że pozostanie tylko to, co zostało wgrane do Arduino. Natomiast korzystanie z tabletów, smartfonów i samej aplikacji do projektowania stanie się już niemożliwe...

 

[Maxxc]

Dzień dobry,

Projekt wydaje się ciekawy.

Mam zapytanie techniczne do Kolegi - czy Kolega sprawdzał już działanie ekspanderów na magistrali I2C w warunkach rzeczywistych (czyli zakłócenia od taboru w "analogu", samo DCC też trochę "sieje"). Zauważyć chciałbym, że I2C ma ograniczoną długość magistrali, wynikającą z pojemności kabli. A sama magistrala jest dość mało odporna na zakłócenia - stan niski jest wymuszany zwarciem do masy tranzystorów w ekspanderach czy mikrokontrolerze, stan wysoki natomiast to tylko magistrala podłączona do +5V (lub 3,3V) przez rezystory o rezystancji kilku kiloomoów.
Już przy kilkudziesięciu centymetrach przewodów mogą dziać się cuda, wynikające z zakłóceń na magistrali. Są oczywiście układy scalone stanowiące izolatory czy repeatery magistrali I2C, które mogą ograniczyć te problemy. Tylko trzeba o tym pamiętać i je uwzględnić w projekcie.
Same ekspandery wydają się porządne (praca do 1MHz na magistrali, filtracja zakłóceń), pytanie jak się zachowa Arduino jako "master" / kontroler magistrali. Tam uzyskać 400kHz (fast I2C) było niejakim problemem. Ale chyba klasyczne 100kHz na I2C wystarczy - pytanie, ile rejestrów w ekspanderze chce Kolega zapisywać w jednym obiegu, bo jeżeli wszystkie kilkadziesiąt, które posiada ekspander, to może być problem z przepustowością samej magistrali.

Ten wpis nie ma na celu zniechęcać Kolegi, chciałbym tylko zwrócić uwagę na pewne aspekty techniczne zagadnienia, które powodują, że nie wystarczy "połączyć klocków" i "wszystko działa". O ile "dla siebie" nie ma problemu, żeby tak robić - o tyle potencjalni użytkownicy mogą mieć pretensje, że "coś nie działa".

W razie czego mogę technicznie podpowiedzieć co nieco, proszę pytać - chyba najlepiej przez forum - to inni też będą mogli z tego skorzystać.

PS. Mediów społecznościowych nie posiadam i nie zamierzam posiadać

Z poważaniem,
Maxxc

 

[microcity]

Dzień dobry,

Projekt wydaje się ciekawy.

Mam zapytanie techniczne do Kolegi - czy Kolega sprawdzał już działanie ekspanderów na magistrali I2C w warunkach rzeczywistych (czyli zakłócenia od taboru w "analogu", samo DCC też trochę "sieje"). Zauważyć chciałbym, że I2C ma ograniczoną długość magistrali, wynikającą z pojemności kabli. A sama magistrala jest dość mało odporna na zakłócenia - stan niski jest wymuszany zwarciem do masy tranzystorów w ekspanderach czy mikrokontrolerze, stan wysoki natomiast to tylko magistrala podłączona do +5V (lub 3,3V) przez rezystory o rezystancji kilku kiloomoów.
Już przy kilkudziesięciu centymetrach przewodów mogą dziać się cuda, wynikające z zakłóceń na magistrali. Są oczywiście układy scalone stanowiące izolatory czy repeatery magistrali I2C, które mogą ograniczyć te problemy. Tylko trzeba o tym pamiętać i je uwzględnić w projekcie.
Same ekspandery wydają się porządne (praca do 1MHz na magistrali, filtracja zakłóceń), pytanie jak się zachowa Arduino jako "master" / kontroler magistrali. Tam uzyskać 400kHz (fast I2C) było niejakim problemem. Ale chyba klasyczne 100kHz na I2C wystarczy - pytanie, ile rejestrów w ekspanderze chce Kolega zapisywać w jednym obiegu, bo jeżeli wszystkie kilkadziesiąt, które posiada ekspander, to może być problem z przepustowością samej magistrali.

Ten wpis nie ma na celu zniechęcać Kolegi, chciałbym tylko zwrócić uwagę na pewne aspekty techniczne zagadnienia, które powodują, że nie wystarczy "połączyć klocków" i "wszystko działa". O ile "dla siebie" nie ma problemu, żeby tak robić - o tyle potencjalni użytkownicy mogą mieć pretensje, że "coś nie działa".

W razie czego mogę technicznie podpowiedzieć co nieco, proszę pytać - chyba najlepiej przez forum - to inni też będą mogli z tego skorzystać.

PS. Mediów społecznościowych nie posiadam i nie zamierzam posiadać

Z poważaniem,
Maxxc

Dzięki za rzeczowy post

System na mojej makiecie ma obecnie 9 sterowników PCA9685 i są one połączone szeregowo. Na dniach dojdzie kolejnych 6 na kolejny sektor makiety i jeszcze 4-5 na ostatni sektor. Zobaczymy czy przepustowość da radę

Jeżeli chodzi o długość przewodów to zauważyłem że powyżej 50cm sygnał ginie i wzmacniam go podciągając przewody sygnałowe do 5v z rezystorem 1kom i działa to świetnie nie mam żadnych problemów z długościami przewodów, a połączenia między PCA9685 mają po kilka metrów.

Używam również rejestrów przesuwanych i tu już pojawiły się problemy z zakłóceniami, ale odfiltrowałem sygnał do układów scalonych kondensatorem ceramicznym i śmiga.

W przyszłości planuje przygotowanie gotowych dodatkowych układów wspomagających, które będą te problemy rozwiązywać.

Na ten moment jeżeli wychodzą problemy na mojej makiecie testowej to szukam rozwiązań i na pewno będę się nimi dzielił.

W projekcie MicroCity Smartcontrol zakładam możliwość podłączenia więcej niż jednego arduino, aczkolwiek na ten moment nie ma takiej potrzeby.

Pozdrawiam

 

[microcity]

Całkiem ciekawe, ale czy się przyjmie. Zobaczymy.
Przede wszystkim taki system od lat istnieje, nazywa się gbb kolejka i - co ważne - współpracuje z systemem DCC, który wszyscy "cyfrowi" modelarze już mają.
Twój będzie działał tylko we własnym obrębie, a zapewniam Cię, że nikt nie zrezygnuje z DCC, a korzystanie z dwóch kompletnie różnych systemów cyfrowych na makiecie mija się zupełnie z celem.

Może inaczej, u mnie będą dwa systemy, DCC do lokomotyw i standardowy system analogowy (przyciski, czujniki położenia rozjazdów itd) do całej reszty.

Takie przykłady:

Przejazd kolejowy - działa automatycznie, zbliża się pociąg, załącza się sygnalizacja.
(Nie potrzebuje sterowania z zewnątrz)

Latarnie - włączane/wyłączane lokalnie / czy choćby czujnikiem zmierzchowym (całe grupy). Symulacja uszkodzonej żarówki (mały układ zamontowany przy jednej z latarni) to też nie potrzebuje rozbudowanego sterowania.

Semafor - a i owszem, to ja naciskam guzik "droga wola", ale...
O tym co się wyświetli, już decyduje system (zależnie od położenia rozjazdów i stanu następnego semafora), a do tego potrzebuje tylko podania GND z przycisku na pulpicie.

Takie zaświecanie każdego światła jakie się chce na semaforze jest zupełnie nie realne w rzeczywistości.

Rozjazdy - to samo, krótki impuls z pulpitu.

Widzę natomiast twój system jako pośredniczący między pulpitem, czy to fizyczne guziki, czy to pulpit wirtualny - a makietą.

Pod ręką mam załóżmy 40 guzików i część twojego systemu. Od pulpitu do makiety biegną trzy przewody SDA, SCL i Gleba.

Na makiecie druga część twojego systemu z ekspanderami.

Albo pulpit to tablet, łączność bezprzewodowa z makietą, na makiecie Arduino i ekspandery, które sterują już czym tam chcesz.

Tyle, że to rozwiązanie dla analogowcow, dla zredukowania ilości kabli między pulpitem, a makietą.

Tak jak mówię, z DCC na pewno nikt nie zrezygnuje.

No ale powodzenia

Na ten moment system jest niezależny od DCC. W przyszłości planuje dać możliwość sterowania DCC z Aplikacji ale tylko taborem, może coś więcej, czas pokaże.

Założeniem projektu jest aby system był niezależny od DCC, dzięki temu będzie miał tanie sterowniki, łatwo konfigurowalne, które dadzą możliwość sterowania infrastrukturą makiety i taki jest mój cel.

Niestety sterowniki DCC są drogie więc tego punktu z moich założeń nie spełniają, poza tym do pełnego sterowania DCC są już aplikacje. Więc po co robić kolejną

 

[Maxxc]

Dzień dobry,

Dodatkowe "podciąganie" magistrali I2C może pomóc, jednakże powoduje to zwiększenie prądu na liniach magistrali, co znów może poskutkować w skrajnym przypadku uszkodzeniem kluczy zwierających do masy w procesorze czy ekspanderach. Co prawda w praktyce nie spotkałem się z takim przypadkiem, ale nie bez powodu jest podawany zakres rezystancji dla rezystorów "podciągających" dla magistrali I2C. Zawsze może Kolega spróbować użyć repeatera magistrali (jest wiele układów tego typu).
Z kolei podpowiedź "z praktyki" - stosując magistralę I2C w środowisku mocno zakłóconym (i podczas badań kompatybilności elektromagnetycznej urządzeń, działających w oparciu o magistralę I2C) zawsze szeregowo na liniach SCL i SDA przy nóżkach układu scalonego stosowałem koraliki ferrytowe LCBC-601 lub LCAA-601 (dostępne np. w TME) i przewidywałem miejsce na opcjonalną zabudowę kondensatora SMD o pojemności kilku-kilkunastu pF (od strony układu scalonego) - do masy. Poprawiało to znacznie odporność tej magistrali na zakłócenia w.cz..
Z koralikami można również spróbować przy rejestrach przesuwnych.
A tak z dawnych czasów - magistrale na 5V pracowały bez zakłóceń nawet na dużych odległościach, póki były szeroko stosowane bipolarne układy scalone (TTL). Z nastaniem ery CMOS zaczęły się problemy.

Z poważaniem,
Maxxc

 

[microcity]

Dzień dobry,

Dodatkowe "podciąganie" magistrali I2C może pomóc, jednakże powoduje to zwiększenie prądu na liniach magistrali, co znów może poskutkować w skrajnym przypadku uszkodzeniem kluczy zwierających do masy w procesorze czy ekspanderach. Co prawda w praktyce nie spotkałem się z takim przypadkiem, ale nie bez powodu jest podawany zakres rezystancji dla rezystorów "podciągających" dla magistrali I2C. Zawsze może Kolega spróbować użyć repeatera magistrali (jest wiele układów tego typu).
Z kolei podpowiedź "z praktyki" - stosując magistralę I2C w środowisku mocno zakłóconym (i podczas badań kompatybilności elektromagnetycznej urządzeń, działających w oparciu o magistralę I2C) zawsze szeregowo na liniach SCL i SDA przy nóżkach układu scalonego stosowałem koraliki ferrytowe LCBC-601 lub LCAA-601 (dostępne np. w TME) i przewidywałem miejsce na opcjonalną zabudowę kondensatora SMD o pojemności kilku-kilkunastu pF (od strony układu scalonego) - do masy. Poprawiało to znacznie odporność tej magistrali na zakłócenia w.cz..
Z koralikami można również spróbować przy rejestrach przesuwnych.
A tak z dawnych czasów - magistrale na 5V pracowały bez zakłóceń nawet na dużych odległościach, póki były szeroko stosowane bipolarne układy scalone (TTL). Z nastaniem ery CMOS zaczęły się problemy.

Z poważaniem,
Maxxc

Super dzięki za podpowiedź, przetestuję

 

[Maxxc]

Dzień dobry,

Chciałbym jeszcze się odnieść do wpisu Kolegi.

Dodatkowo jest jeszcze opcja aby każda latarnia = dioda led = slot w PCA miał indywidualny efekt świetlny, np wł/wył, powolne zapalnie/gaszenie, stroboskop, jasność diody itd. A w niedalekiej przyszłości udostępnię moduł nad którym już pracuje do definiowania własnych efektów świetlnych, da to możliwość tworzenia iluminacji, czy efektów specjalnych takich jak zepsuta żarówka w latarni, spawarka, dyskoteka itd

W ekspanderze pracującym na magistrali I2C Kolega nie da rady zrobić bardziej rozbudowanego efektu świetlnego. Pracując np. w cyklu 100ms przesyłania danych po magistrali, będzie mógł Kolega zmienić wartość rejestru tylko 10 razy na sekundę. To nie będzie wyglądało naturalnie. Przesyłając dane częściej - będziemy się borykać z przepustowością i samą wydajnością Arduino.
Tutaj sugerowałbym użyć mikrokontroler jako slave na magistrali I2C z "zaszytymi" wszystkimi efektami wewnątrz. Wtedy po magistrali wysyłać można tylko przypisanie efektu do pinu i jego załączenie/wyłączenie.

Z poważaniem,
Maxxc

 

[microcity]

Dzień dobry,

Chciałbym jeszcze się odnieść do wpisu Kolegi.



W ekspanderze pracującym na magistrali I2C Kolega nie da rady zrobić bardziej rozbudowanego efektu świetlnego. Pracując np. w cyklu 100ms przesyłania danych po magistrali, będzie mógł Kolega zmienić wartość rejestru tylko 10 razy na sekundę. To nie będzie wyglądało naturalnie. Przesyłając dane częściej - będziemy się borykać z przepustowością i samą wydajnością Arduino.
Tutaj sugerowałbym użyć mikrokontroler jako slave na magistrali I2C z "zaszytymi" wszystkimi efektami wewnątrz. Wtedy po magistrali wysyłać można tylko przypisanie efektu do pinu i jego załączenie/wyłączenie.

Z poważaniem,
Maxxc

Dzięki za uwagę, zobaczymy co z tego wyjdzie

 

[Maxxc]

Dzień dobry,

A przy okazji kolejna sugestia. ale odnosząca się do wpisu Kolegi @Lucky :

Widzę natomiast twój system jako pośredniczący między pulpitem, czy to fizyczne guziki, czy to pulpit wirtualny - a makietą.

Pod ręką mam załóżmy 40 guzików i część twojego systemu. Od pulpitu do makiety biegną trzy przewody SDA, SCL i Gleba.

Na makiecie druga część twojego systemu z ekspanderami.

Tutaj bym sugerował zastosowanie magistrali RS232 czy raczej RS422/485.
Wtedy w pulpicie i na makiecie może być Arduino i podłączone do niego "lokalnie" ekspandery I2C. Z magistralą na poziomie 5V i to nie separowaną galwanicznie (szczególnie, że podłączoną bezpośrednio do procesora) bym za daleko "nie wychodził" z urządzeń na zewnątrz.
Ale może to moje "zboczenie zawodowe", bo zakładam zawsze dużą dowolność w podłączeniach stosowaną przez zwykle niezbyt wykwalifikowanych użytkowników.

Na teraz wystarczy, już nie spamuję wątku dalszymi przemyśleniami. W końcu to pomysł i projekt Kolegi @microcity , a nie mój.

Z poważaniem,
Maxxc

 

[microcity]

Dzień dobry,

A przy okazji kolejna sugestia. ale odnosząca się do wpisu Kolegi @Lucky :



Tutaj bym sugerował zastosowanie magistrali RS232 czy raczej RS422/485.
Wtedy w pulpicie i na makiecie może być Arduino i podłączone do niego "lokalnie" ekspandery I2C. Z magistralą na poziomie 5V i to nie separowaną galwanicznie (szczególnie, że podłączoną bezpośrednio do procesora) bym za daleko "nie wychodził" z urządzeń na zewnątrz.
Ale może to moje "zboczenie zawodowe", bo zakładam zawsze dużą dowolność w podłączeniach stosowaną przez zwykle niezbyt wykwalifikowanych użytkowników.

Na teraz wystarczy, już nie spamuję wątku dalszymi przemyśleniami. W końcu to pomysł i projekt Kolegi @microcity , a nie mój.

Z poważaniem,
Maxxc

Dziękuję za podpowiedzi, na pewno wszystkie przeanalizuję i przetestuję
Pomysłów w głowie mam mnóstwo, każde podpowiedzi zawsze bardzo cenię, jeszcze raz dzięki za poświęcony czas

 

[jezyzie]

... Dodatkowe "podciąganie" magistrali I2C może pomóc, jednakże powoduje to zwiększenie prądu na liniach magistrali, co znów może poskutkować w skrajnym przypadku uszkodzeniem kluczy zwierających do masy w procesorze czy ekspanderach. Co prawda w praktyce nie spotkałem się z takim przypadkiem, ale nie bez powodu jest podawany zakres rezystancji dla rezystorów "podciągających" dla magistrali I2C. ...

Jako potwierdzenie i uzupełnienie przedstawionych informacji, coś z moich zbiorów i dociekań:

Ponadto wszystkie niewykorzystane wejścia procesora i układów podciągamy opornikami do plusa.
Przewód masowy obowiązkowo lutujemy. Przewody sygnałowe prowadzimy kablami ekranowanymi, lecz ekran dołączony tylko z jednej strony do urządzenia głównego. Ekran nie może być przewodem masowym - nie zamykamy pętli mas.