Górka

[Domiss]

Przez 3 bitowe adresowanie w PCA9552 musiałem korzystać z tylu wyjść ile było niezbędne dla semafora o określonej ilości komór zamiast zrobić uniwersalne sterowanie 5 wyjść na semafor.

Arduino można programować obiektowo z c++ i nawet używać przy tym dziedziczenia obiektów (normalnie w środowisku arduino). Da się więc upiec dwie pieczenie przy jednym ogniu, robiąc jedną (abstrakcyjną) klasę bazową SwiatloSemafora i odziedziczyć z niej dwie klasy pochodne: jedną, która rzeczywiście zapala lub gasi jakieś światło i ma pin, i drugą fałszywą, która nie ma dowiązanego pinu i coś tam niby zapala i niby gasi, a potem użyć tych klas w konstruktorze semafora pięciokomorowego - tam gdzie mamy światła: pierwszej, a tam gdzie nie: drugiej (może nawet wystarczy jedna klasa z adresem ekspandera ustawionym na NULL dla fałszywych świateł i odpowiednie sprawdzenia przy zapaleniu/gaszeniu światła).
Ja na razie mam zamiar robić całe sterowanie nie istniejącej jeszcze infrastruktury przy pomocy DCC (osobna magistrala dla sterowania, niezależna elektrycznie od magistrali torów) i wykorzystać dekoder akcesoriów oparty na arduino (pro mini) udostępniony przez Geoffa Bunza'ę (http://model-railroad-hobbyist.com/node/19070), który już przetestowałem i działa (aktualnie będę próbował dorobić do niego potwierdzenie podczas programowania przez dcc, tylko ciągle nie mam na to dość czasu, a nie chcę w pośpiechu czegoś spalić). Potem będzie kolejny problem: jak dorobić możliwość przesyłania wykrywania zajętości odcinków poprzez DCC bez nadmiernych inwestycji finansowych, ale ... to też powinno się udać .

[Borczy]

Hahahahaha, no
Ja czytam rozmowy Panów bez kompletnego zrozumienia ale z szacunkiem

[womo]

Powiem tylko tyle.
Ta rozmowa brzmi dla mnie jakbyście się opili sokiem z gumijagód
Mam tylko nadzieję, że się tam tym szyfrem nie obrażacie nawzajem ?

[Wicio]

Nie dopatrzyłem się w PCA9685 sprzętowego blinku, PWM jak ktoś chce może się przydać, cena zbliżona do PCA9552, bardziej upierdliwa obudowa (0,635mm rozstaw pinów), słaba dostępność w PL, zaleta ogromna - adresowanie na 6 bitach co daje możliwość sterowania 64 układami.
Przez 3 bitowe adresowanie w PCA9552 musiałem korzystać z tylu wyjść ile było niezbędne dla semafora o określonej ilości komór zamiast zrobić uniwersalne sterowanie 5 wyjść na semafor.

[wicy]

Zależy jakich expanderów się używa. Do sterowania LED jest PCA 9552, 16 bitowy z programowo ustawianym miganiem (2 rodzaje).

Przeglądając jeszcze różne układy driverów LED wpadłem na PCA9685, który wydaje się być lepszy bo ma nie tylko prosty blink, ale sterowanie PWM dla każdego z wyjść LED z osobna. No i w przeciwieństwie do PCA9552 ma dwie zalety: bywa w postaci gotowych modułów i to w bardzo niskiej cenie!

[gemol]

Nie wiem, czy Grzesiek mnie wpuści....

No nie wiem. Muszę to przemyśleć. Zajrzyj.

[Wicio]

W PCA steruje się każdym wyjściem niezależnie, żadnego przesuwania bitów itp. Trzeba wykorzystać gotowe biblioteki Arduino.

[mareks]

obudowa smd

E tam ,obudowa SO-24 ,raster 1,27 mm

[wicy]

Wpadnij do Radomia w ten weekend to zobaczysz na żywo.

Nie wiem, czy Grzesiek mnie wpuści....

Zastosowanie migającej komory jest może ograniczone w Twoim przypadku, ale w przypadku semaforów wjazdowych i uzależnieniu wskazań już się przyda. A poza tym w PCF dostajemy to wbudowane.

Ten PCA wydaje się być idealny do sterowania semaforami, ale ma dwie malutkie wady:
- wyjścia podzielone są na 4 grupy po 4 diody. Komplikuje to nieco sterowanie, zapalenie 5-komorowego semafora wymaga przesuwania bitów i podwójnego zapisu.
- obudowa smd

[Wicio]

Wpadnij do Radomia w ten weekend to zobaczysz na żywo. Zastosowanie migającej komory jest może ograniczone w Twoim przypadku, ale w przypadku semaforów wjazdowych i uzależnieniu wskazań już się przyda. A poza tym w PCF dostajemy to wbudowane.

[wicy]

Owszem, miganie to jedno a uzależnienie co innego.
Uzależnienie będzie, ale z ograniczoną ilością sygnałów. Czy widzisz tu gdzieś możliwość zastosowania sygnałów pulsujących? Ja nie bardzo. Jeśli W1-W2 to tor przelotowy i na Sem2 podany jest:
- sygnał S10 (jazda 40km) to wtedy na Sem1 mógłby być podany sygnał S4 lub S12 - i jest to chyba jedyny wypadek, gdy mógłby być wykorzystany sygnał pulsujący.
- sygnał S1 (stój) to na Sem1 sygnał S5 (następny stój)
- sygnał S2 (jazda max) to na sem1 sygnał S10 (wolno przez zwrotnicę, potem max)
Zjazd w perony implikuje na Sem1 sygnał S5 (następny stój) albo S13 (powoli, następny stój) - oba bez pulsacji. Tak więc nie wiem, czy jest sens babrać się w programie tylko dla jednego przypadku zastosowania pulsacji....

Jeśli uda mi się ogarnąć czujniki i zostanie miejsce to spróbuję się tym pobawić w programie.

Ekspandery PCF obadam. Przerwa między sygnałami mówicie? A nie płynne przejście jak tu - https://youtu.be/BhsMm5nI1X4

[Wicio]

Zależy jakich expanderów się używa. Do sterowania LED jest PCA 9552, 16 bitowy z programowo ustawianym miganiem (2 rodzaje).
Sterowanie semafora z wykorzystaniem PCA 9552 jest bardzo proste, podaje się jaki sygnał ma być ustawiony na wyjściu expandera: 0, 1, Blink1 lub Blink2 i po sprawie. Ustawiony stan jest trzymany przez zatrzask do momentu ustawienia nowego stanu.
Są do tego gotowe biblioteki np. od układu CAT 9552 (odpowiednik). Można jednym poleceniem zapalać lub gasić wszystkie podłączone diody jednocześnie.
Nie ma potrzeby pchać na siłę sterowania PWM, wystarczy przerwa około 300ms między zgaszeniem jednej a zapaleniem drugiej komory, efekt jest bardzo dobry.

[Niejeden]

Miganie to jedno ale uzależnienie sygnału od następnego semafora miałoby w tym układzie uzasadnienie, chociażby S1-->S2 i S4-->S3

Płynne wygaszanie PWM na i2c raczej odpada

Tym bym się nie przejmował. Dla mnie to płynne wygaszanie PWMem jest mocno przereklamowane (tzw. sztuka dla sztuki). Wystarczy, że pomiędzy zmianą sygnałów będzie krótki moment pełnego wygaszenia i to już daje bardzo fajny efekt. Whoshoo w Wajchowni zrobił wygaszanie PWM na SPI - ładował rejestry przesuwne kilkanaście razy na sekundę. Ja stwierdziłem, że szkoda zachodu, chociaż też tak mam zrobione sterowanie semaforów.

[wicy]

A propos cytatu z innego tematu:

Pisz bezpośrednio PW do Rangera.
Nie kombinuję z sygnałami informującymi o stanie semafora następnego, nie przewiduję sygnałów "migających".

Szkoda, bo to jest coś, gdzie najlepiej widać przewagę sterowania elektronicznego nad analogowym (gdzie teoretycznie też jest to wykonalne ale poziom komplikacji dąży do nieskończoności). Ja na Twoim miejscu bym to przemyślał. W Twoim przypadku to tylko kwestia programu.

żeby już nie śmiecić w nieswoim temacie, odpowiem tutaj.

Przy tego typu planowanym układzie torów i semaforów:

Pulpit PC.jpg

nie bardzo jest gdzie używać sygnałów pulsujących. Jedyne takie miejsce to ewentualnie Sem1 w połączeniu z Sem2 (i Sem4 z Sem3). Wydaje mi się, że przy założeniu, że Sem2 może wskazywać w zasadzie tylko sygnały S1 lub S2, Sem1 nie ma jak wskazywać sygnałów "migających" S3, S4, S7, S8, S11, S12. Rozróżnianie prędkości jazdy na odcinku od W1 do W2 na "z największą dozwoloną" a "100 km", czy wprowadzanie na siłę ograniczenia 40km lub 60km jest chyba bez sensu i powoduje dodatkowe komplikacje dla maszynisty/ów.
To jedno, a drugie to problem natury technicznej. Semafory nie są sterowane bezpośrednio przez procesor, ale stoją za kilkoma expanderami na i2c. O ile podanie na semafor prostego stanu to żaden problem (nawet z programowym zapaleniem dwóch diod w czasie zmiany z jednej na drugą. Płynne wygaszanie PWM na i2c raczej odpada ) to wprowadzenie migania jednej wybranej diody spośród kilku portów expandera, to już jest ekwilibrystyka i wyzwanie programistyczne.

Póki co semafory działają, ale walczę któryś dzień z rzędu nad opanowaniem odczytu stanów czujników. Właściwie dwóch czujników na czujnik, gdyż kombinuję z ustalaniem kierunku w danym punkcie - czarne kropki na obrazku.

[wicy]

A było sobie przetestować. Właśnie po to jest Arduino i płytki stykowe Dowolny układ I2C, czy SPI to kwestia kilku złotych.
Zainwestowałem dziś niepotrzebnie w układy SPI. Szczęście, że nie w ilościach hurtowych, może z czasem przydadzą się w testach innych projektów.

Obecnie testuję przerwania od czujników na expanderach. Program opracowany, wkrótce dokładniejsze testy czujników, również na większe odległości.