Łódzkie Forum Komunikacyjne

Wiecie czemu na przednich wyświetlaczach nowych Merców (na pewno tych z 13 roku, nie wiem jak te pożyczone z 14 roku) dość często gaśnie nr linii i zostaje sam kierunek. Może to być nieco mylące, bo ostatnio spotkałem taki na Pojezierskiej w kierunku cm. i nie wiedziałem czy to 81 czy 87.

To chyba wina sterownika lub programu. Możliwe, że wada fabryczna, a może wynik kombinowania elektryków. Sytuacja ma miejsce właściwie od samego początku, również w Mercach z 2014 i nie tylko na przednich wyświetlaczach, ale na tych bocznych też. Wydaję mi się, że widziałem nawet raz, jak gaśnie także ten z tyłu. Zazwyczaj tak jak napisałeś, gaśnie nr linii i zostaje kierunek, choć czasami bywa odwrotnie. Najczęściej trwa to kilka lub kilkanaście sekund. Ja jeszcze tłumaczyłem to sobie czymś innym. Dzieje się to często w obrębie przystanku. Może ma to związek z zapowiedziami głosowymi. W chwili, gdy przeskakuje w sterowniku następna zapowiedź coś się dzieje i jest taki efekt.

Hah, no proszę. Nowe autobusy a już takie rzeczy się z nimi dzieją

W nich było tak od nowości.

Intermodalny pisze:Hah, no proszę. Nowe autobusy a już takie rzeczy się z nimi dzieją

Za mało różnych API zapakowano do prostej rzeczy jak tablica....
Proponuje .NET, Mono, Jave, PanTalk, jeszcze jakieś VMWare .....

To właśnie jest ta część systemu, która działa na starych protokołach (tablice i kasowniki łączą się ze sterownikiem przez mostek Ethernet-RS485 i działają na protokole identycznym, jak ten w starych sterownikach).
Problemem nie są warstwy protokołów (które pozwalają szybciej zrobić lepszy produkt, im niżej schodzimy tym programista ma większą szansę na popełnienie błędów), problemem jest raczej ogólna jakość kodu i przede wszystkim olewactwo MPK, które nie jest w stanie wymusić, żeby system był w pełni sprawny.
O ile w przypadku LCD, które sypią błędami, czy nawet tablicy, która przez minutę nie pokazuje numeru to nie jest jakiś wielki problem (chociaż aktualizacja i tak powinna się pojawić w ciągu miesiąca), o tyle w Woltanach przez co najmniej pół roku program sterownika wywalał się dosłownie co 10 minut. Pewnie dałoby radę naprawić to własnymi siłami, ale system za 150 tysięcy za komplet nie powinien mieć takich błędów, a już na pewno nie przez pół roku

Raczej ciężko naprawić program własnymi siłami jeśli nie ma się dostępu do kodu źródłowego.

px33 pisze:Problemem nie są warstwy protokołów (które pozwalają szybciej zrobić lepszy produkt, im niżej schodzimy tym programista ma większą szansę na popełnienie błędów),

Każde komplikowanie systemu prowadzi do większego prawdopodobieństwa wystąpienia błędu. Co do szybciej to nie zawsze tak jest jak w reklamówkach wszelkich produktów typu RAD. Potem się okazuje ze trzeba szukać obejść na różne błędy. Wbrew pozorom tworząc od podstaw własną warstwę komunikacyjną ma się przewagę że ma się kontrolę nad błędami. B w gotowym API może być tak że nagle upierdliwy błąd nie ma nadanego odpowiedniego prioryteu dla przygotowywania poprawki.
Inaczej pisząc może i ma większe szanse popełnić ale ma tez szanse poprawić. Zaś korzystając z gotowej warstwy API szans ma mniej aby popełnić błąd ale niestety nie ma szans na poprawienie istniejącego błędu....


Przykład że można unikać dodawania kolejnego produktu, zmiany motoru itd... Ileś lat temu , motor bazy i brak sortowanie wg języka polskiego. Rozwiązanie było banalnie proste, szybkie. Po prostu tylko na etapie wprowadzania czy wyświetlania danych polskie literki były podmieniane na kolejne znaki z tablicy ASCII. Motor sortując po angielsku nie widział że sortuje polskie słowa wg polskich reguł. Tylko dwie procedury jedna do wyświetlania tekstu a druga to filtrowania danych wprowadzanych. Jedna tablica. Proste funkcje w których trudno popełnić błąd. Ba, nowy język to tylko zdefiniowanie tablicy.

Różne kodowanie polskiego alfabetu? Rozwiązanie autodetekcji jest równie banalnie proste.

Koniec OT.

px33 pisze:Pewnie dałoby radę naprawić to własnymi siłami, ale system za 150 tysięcy za komplet nie powinien mieć takich błędów, a już na pewno nie przez pół roku

Ustawianie przetargów (powiedzmy tak lekko licząc co trzeci to ustawka ....) prowadzi m.in. do tego typu patologii.

Raczej ciężko naprawić program własnymi siłami jeśli nie ma się dostępu do kodu źródłowego.

Problem niekoniecznie musi się brać z samego programu, to mógł równie dobrze być problem ze środowiskiem (nowsza biblioteka, przepełniony dysk czy cokolwiek zbliżonego), środowisko w tych sterownikach jest dość otwarte i skomplikowane

Ale jeśli mówimy o przetargach, stworzenie programu w "nowoczesnym" środowisku może być tańsze od napisania go w języku niższego poziomu, bo wymaga to dużo mniej ze strony programisty. Droższe jest jego wdrożenie, bo ma on dużo większe wymagania ze strony sprzętu, ale podejście do technologii w naszym kraju jest jakie jest. "Informatyk" to magik, który ma zrobić wszystko, nie ważne jak.

px33 pisze: Problem niekoniecznie musi się brać z samego programu, to mógł równie dobrze być problem ze środowiskiem

Na to zwracam uwagę. Struktura programu może być bezbłędna ale program glebnie bo w którymś z dll'i i jest bug.
Gorzej jak poprawa akurat tego konkretnego bug'a co nam "zglebia" produk nie ma najwyższego priorytetu o producenta.

px33 pisze:środowisko w tych sterownikach jest dość otwarte i skomplikowane

Najbardziej rozbudowana i skomplikowana cześć jak .NET nie jest otwarta. To nie alternatywa o nazwie Mono.

Na siłę zmuszanie do pseudokodu w imię różnych procesorów jest praktycznie śmieszne jak od iluś lat znikają konkurenci platformy x86.
Wystarczy olać ten zarządzany kod i kompilować co najwyżej na dwie platformy - Intel i ARM. docelowy kod byłby bardziej zwarty i miałby mniejsze zapotrzebowania na zasoby. Po co tworzyć wirtualny procesor i go emulować jak można to samo zrobić w natywnym kodzie?

Strzelanie z armaty do muchy. Widać uczelnie zachęcają do wytwarzania nieefektywnego kodu wynikowego. W imię czego?

Akurat programowania uczelnie praktycznie nie uczą (a jeśli już - to raczej właśnie bardziej niskopoziomowego typu C, przynajmniej na polibudzie na elektrycznym), to jest branża w której 99% ludzi do umiejętności dochodzi samodzielnie.

Na to zwracam uwagę. Struktura programu może być bezbłędna ale program glebnie bo w którymś z dll'i i jest bug.
Gorzej jak poprawa akurat tego konkretnego bug'a co nam "zglebia" produk nie ma najwyższego priorytetu o producenta.

To wystarczy użyć otwartych bibliotek, tego jest od groma. Wtedy w przypadku błędu firma może go poprawić i oddać społeczności.
Swoją drogą, nie wydaje mi się, żeby w grupie najpopularniejszych bibliotek istniały jakiekolwiek z potężnymi błędami w podstawowej funkcjonalności (tzn. czyniącymi cały program bezużytecznym), co najwyżej może są jakieś luki w bezpieczeństwie, z którymi da się żyć (i tak bez użycia biblioteki programista zrobiłby tych błędów więcej).
Skoro cały świat korzysta z wysokopoziomowych bibliotek itp. i wszystko działa, to może to jednak nie jest problem bibliotek tylko użytkownika (i zamawiającego), a gdyby pisali to od zera to nie działałoby nigdy?

Na siłę zmuszanie do pseudokodu w imię różnych procesorów jest praktycznie śmieszne jak od iluś lat znikają konkurenci platformy x86.
Wystarczy olać ten zarządzany kod i kompilować co najwyżej na dwie platformy - Intel i ARM. docelowy kod byłby bardziej zwarty i miałby mniejsze zapotrzebowania na zasoby. Po co tworzyć wirtualny procesor i go emulować jak można to samo zrobić w natywnym kodzie?

W interpreterach i VM nie chodzi tylko o przenośność, ale też o dodatkowe funkcje (garbage collector, zmiana klas na bieżąco, ...), w skompilowanym programie to dość trudne i nieefektywne. A i tak obecnie trendem jest JIT czyli kompilacja w trakcie działania.
Co do procesorów, to nie do końca tak, architektur w użyciu jest trochę więcej (np. różne MIPS-y z chipów dla routerów, bardzo wdzięczna zabawka do tanich urządzeń), a VM/interpreter może dodatkowo przeprowadzić optymalizację pod konkretny sprzęt.