Mercedes
-
- Stały bywalec
- Posty: 460
- Rejestracja: sob 18:10, 06 cze 2015
Mercedes
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.
„Działamy dla dobra naszych pasażerów a ich zadowolenie ze świadczonych usług jest dla nas najwyższą wartością” – Tramwaje Podmiejskie
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.
Ostatnio zmieniony ndz 07:28, 07 lut 2106 przez Mat, łącznie zmieniany 2 razy.
Mateusz
EA-1
EA-1
-
- Stały bywalec
- Posty: 460
- Rejestracja: sob 18:10, 06 cze 2015
W nich było tak od nowości.
PcForum.eu - Bo IT to nasza pasja!
format c: - najlepszy sposób na wszelkie problemy z Windowsem...
Bykom Stop (i ImageShackowi też)
format c: - najlepszy sposób na wszelkie problemy z Windowsem...
Bykom Stop (i ImageShackowi też)
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
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.
PcForum.eu - Bo IT to nasza pasja!
format c: - najlepszy sposób na wszelkie problemy z Windowsem...
Bykom Stop (i ImageShackowi też)
format c: - najlepszy sposób na wszelkie problemy z Windowsem...
Bykom Stop (i ImageShackowi też)
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.
Ustawianie przetargów (powiedzmy tak lekko licząc co trzeci to ustawka ....) prowadzi m.in. do tego typu patologii.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
Ostatnio zmieniony ndz 07:28, 07 lut 2106 przez STUDI, łącznie zmieniany 3 razy.
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 skomplikowaneRaczej ciężko naprawić program własnymi siłami jeśli nie ma się dostępu do kodu źródłowego.
Ostatnio zmieniony ndz 07:28, 07 lut 2106 przez px33, łącznie zmieniany 1 raz.
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.
PcForum.eu - Bo IT to nasza pasja!
format c: - najlepszy sposób na wszelkie problemy z Windowsem...
Bykom Stop (i ImageShackowi też)
format c: - najlepszy sposób na wszelkie problemy z Windowsem...
Bykom Stop (i ImageShackowi też)
Na to zwracam uwagę. Struktura programu może być bezbłędna ale program glebnie bo w którymś z dll'i i jest bug.px33 pisze: Problem niekoniecznie musi się brać z samego programu, to mógł równie dobrze być problem ze środowiskiem
Gorzej jak poprawa akurat tego konkretnego bug'a co nam "zglebia" produk nie ma najwyższego priorytetu o producenta.
Najbardziej rozbudowana i skomplikowana cześć jak .NET nie jest otwarta. To nie alternatywa o nazwie Mono.px33 pisze:środowisko w tych sterownikach jest dość otwarte i skomplikowane
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?
Ostatnio zmieniony ndz 07:28, 07 lut 2106 przez STUDI, łącznie zmieniany 1 raz.
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.
PcForum.eu - Bo IT to nasza pasja!
format c: - najlepszy sposób na wszelkie problemy z Windowsem...
Bykom Stop (i ImageShackowi też)
format c: - najlepszy sposób na wszelkie problemy z Windowsem...
Bykom Stop (i ImageShackowi też)
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.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.
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?
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.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?
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.