On 30/04/2021 14:09, J.F wrote:
>> Kryterium pamieci czy długości kodu jest czynnikiem, ale raczej nie
>> decydującym, o możliwosciach stwierdzenia czy kod jest czy nie "dobry".
> Ale zweryfikowac kod o milionie linii jest zdecydowanie trudniej

Nie. Wszystko zależy od stylu pisania.

> i
> drozej :-)

Nie wiadomo.

>> Dalej nie wydaje mi się aby crunching miał miejsce w firmie zajmującej
>> się produkcją poduszek powietrznych czy autopilotów. To nie kolejny
>> zegarek szkolny.
> no, 737MAX troche Boeingowi nie wyszedl.

Boening nie jest doskonały i ogólnie nie ma takich firm. Balansujemy.

>> Po to jest weryfikacja formalna aby przewidzieć *wszystkie*.
> Ale to jest obok testow. Jak myslisz, ze testy nalepsze i wszystko
> wylapia ...

Nie wyłapią. Zakłądamy pewien poziomy ryzyka. Jesli to safety,
poprzeczka jest wysoko.

> Z drugiej strony - jak sie mozna pomylic przy algorytmie, przy pisaniu
> programu - tak mozna i przy weryfikacji.
> A test na symulatorze ... moze wylapie blad.

Lepsze to, niż licznie na brak błedów.

>> Do tej konwersji? Na pęczki. Np. imagemagick.
> Ale jak to wszystko w windows - najlepiej obsluguje sie myszka :-)

Nie najlepiej ani najszybciej. *Zależy*.

> W tym przykladzie to IMO niekoniecznie - Heniek z niechecia przerobil
> te 100 plikow ... ale tak bylo najprosciej.

Nie było najprościej. Nie było najwygodniej. Było tak, jak potrafi.
Podobnie z EDA: będzie dziobał te swoje pliki na dyskietkach bez
konstroli wersji, bo nie potrafi i uznaje że tak jest najlepiej.

do góry

On 30/04/2021 15:42, J.F wrote:
> A PS dobrze sobie radzi, przynajmniej prawie wszyscy zawodowcy tak
> uwazaja :-P

A ci zawodowcy to troche nie są jak audiofile?

do góry

On Fri, 30 Apr 2021 16:21:14 +0200, heby wrote:
> On 30/04/2021 15:42, J.F wrote:
>> A PS dobrze sobie radzi, przynajmniej prawie wszyscy zawodowcy tak
>> uwazaja :-P
>
> A ci zawodowcy to troche nie są jak audiofile?

Chyba mniej - bo jednak efekty ich pracy co chwila ogladasz.
Wiec musi byc w miare dobrze.

Ale moze i oni maja dyskusje o wyzszosci czy przekonanie, ze najlepszy
program ... no przeciez nie convert z linuxa :-)

J.

do góry

On 2021-04-30 10:08, J.F wrote:

>
> Akurat mialem na mysli to, ze oni uzywaja starego komputera.
> Moze nie 8051, ale starocia. I wymaga starych informatykow :-)
>
> Zastapienie moze nie byc takie latwe, jesli to jakis odporniejszy
> procesor, mozna gdzies wyczytac ze "formally verified", i jeszcze
> sprawdzony przez 25 lat ... chcesz cos nowoczesnego wstawic?

swego czasu słyszałem od godnych zaufania osób, że do zastosowań w
lotnictwie nie wolno stosować rozwiązań bazujących na technologii
bodajże 22nm i poniżej - kwestia niezawodności, odporności na
promieniowanie i trwałości.

--
Pozdr.
Michał

do góry

>> A w automatyce ... czy nie kolejne utrudnienie?
>> Bo np odpytujesz czujnik1. Czytasz czujnik2. Podejmujesz decyzje.
>> No ale przyszla odpowiedz od 2, a od 1 ciagle nie.
>> W pewnym moemencie przychodzi. Takie przerwanie dostajesz.
>> Ale nie wiadomo, z ktorego momentu ta odpowiedz...

Jak jest potrzeba wiedzieć kiedy ta zmiana na czujniku nastąpiła, to
trzeba zmienić magistralę na inną.

> Ogarniamy to od 50 lat, w programowaniu. Automatycy też sobie poradzą.

Automatycy dostają gotowe rozwiązanie. Nie wiem czy ktokolwiek
zastanawia się nad problemem typu jeden czujnik mi się nie zgłasza. Mam
problem z czujnikiem na magistrali, to robię obsługę braku komunikacji,
a nie braku czujnika.


>> Albo taki np STOP. Wciskasz przycisk, maszyna ma sie zatrzymac, ale
>> pakiet sie gdzies zgubil - jak dlugo czekamy na wyslanie ponowne?
>
> Ten problem występuje we *WSZYSTKICH* magistralach. Bez wyjątku. I mam
> zawsze tą sama rade: pociągnij do tego drut.

No to poczytaj o TwinSAFE Beckhoff-a. Jest spora szansa, ze Ci się
spodoba koncepcyjnie, szczególnie zastosowana magistrala.
EtherCAT nie jest niestety tak popularny, jak modbus. Mało tego, opcje
EC do sprzętu potrafią sporo kosztować.

>> Projektowali pewnie adekwatnie do czasu powstania.
> Tak, w zeszłym wieku.

Ale tak jest ze wszystkim. Pierdylion razy dostaję pytanie czy napisałem
to w drabinkach. Ludziska tylko to znają, to tego wymagają. No i
standard się trzyma.

Czy na uczelniach dalej drabinek uczą?

Miłego.
Irek.N.

do góry

On 03/05/2021 09:31, Irek.N. wrote:
> Czy na uczelniach dalej drabinek uczą?

Skoro w latach 90tych uczono, to trzeba obliczyć średnią długość życia
asystenta, obecnie pewnie już habilitowanego ze dwa razy. Mi wychodzi że
przestaniemy koło 2040. Obym się mylił.

do góry

On Mon, 3 May 2021 09:31:49 +0200, Irek.N. wrote:
>>> A w automatyce ... czy nie kolejne utrudnienie?
>>> Bo np odpytujesz czujnik1. Czytasz czujnik2. Podejmujesz decyzje.
>>> No ale przyszla odpowiedz od 2, a od 1 ciagle nie.
>>> W pewnym moemencie przychodzi. Takie przerwanie dostajesz.
>>> Ale nie wiadomo, z ktorego momentu ta odpowiedz...
>
> Jak jest potrzeba wiedzieć kiedy ta zmiana na czujniku nastąpiła, to
> trzeba zmienić magistralę na inną.

Albo protokol - niech wysyla czas zmiany.

Ale tu nie tylko o chwile zmiany chodzi, tylko o to ze wysylasz
zapytanie, a do czasu odpowiedzi ... zatrzymujesz proces sterujacy,
czy poslugujesz sie poprzednia wartoscia?
Wiec trzeba kiedys rozpoznac "urzadzenie od xxx sekund nie odpowiada".

>> Ogarniamy to od 50 lat, w programowaniu. Automatycy też sobie poradzą.
>
> Automatycy dostają gotowe rozwiązanie. Nie wiem czy ktokolwiek
> zastanawia się nad problemem typu jeden czujnik mi się nie zgłasza. Mam
> problem z czujnikiem na magistrali, to robię obsługę braku komunikacji,
> a nie braku czujnika.

A jak sie termopara od modulu odepnie?
>
>>> Projektowali pewnie adekwatnie do czasu powstania.
>> Tak, w zeszłym wieku.
>
> Ale tak jest ze wszystkim. Pierdylion razy dostaję pytanie czy napisałem
> to w drabinkach. Ludziska tylko to znają, to tego wymagają. No i
> standard się trzyma.
> Czy na uczelniach dalej drabinek uczą?


ale np te
https://www.unitronicsplc.com/

drabinki umieja .... a czy cos innego umieja?

J.

do góry

> Ale tu nie tylko o chwile zmiany chodzi, tylko o to ze wysylasz
> zapytanie, a do czasu odpowiedzi ... zatrzymujesz proces sterujacy,
> czy poslugujesz sie poprzednia wartoscia?
> Wiec trzeba kiedys rozpoznac "urzadzenie od xxx sekund nie odpowiada".

Jak przez pewien czas nie masz wiarygodnych informacji, to musisz
wdrożyć obsługę takiej sytuacji. Przykładowo, jeżeli 3 kolejne ramki
będą uszkodzone lub nie wrócą (master wysyła i oczekuje powrotu - w
EtherCat przykładowo), to urządzenia podłączone do takiej magistrali
mogą zmienić status z opercyjnego na synclost, a co się wtedy stanie,
czy magistrala się podniesie i będzie można kontynuować, to już inna
bajka i mocno zależna od konkretnej sytuacji i podłączonych urządzeń.
O ile nie widzę problemu w automagicznym podniesieniu się modułu I/O, o
tyle nie bardzo wiedzę możliwość takiego podniesienia serwa czy
chociażby obwodów safety.

> A jak sie termopara od modulu odepnie?

To po pierwsze moduł powinien zmienić statut dla czujnika, a po drugie
odczyt będzie z czapki. O ile statut można czasami pominąć, o tyle
widząc 850C na przykładowo PT100 można chyba założyć, że coś jest nie
teges? ;)

> ale np te
> https://www.unitronicsplc.com/
>
> drabinki umieja .... a czy cos innego umieja?

Nie wiem, otwiera mi się strona z której nie wynika dla mnie nic.
Dokumentacji nie czytałem.
Co do umiejętności, to czasami mam wrażenie, że ST jest znacznie
łatwiejszy niż drabinki, przy założeniu że robimy coś więcej niż miganie
diodą.

Miłego.
Irek.N.

do góry

Statut...ale mi się napisało. Przepraszam, status.

Irek.N.

do góry

Piotr Wyderski napisał(a):
> Marek wrote:
>
> > Ile razy spotkałeś się z czymś takim?
> Kilkukrotnie w przypadku pendrive i kart pamięci,

Ale to to badziewie konsumenckie, do tego wiele razy macane, wyginane
i ogólnie 2/4 bity w jednej komórce pamięci, wręcz przewidziane do "sypniecia"
pamięci ... i nic się niestanie.
Porównujesz pan nieporównywalne.


> z MCU nie przypominam
> sobie.

A widział kum.



OT. Ja nie w temacie STM`ów, być może kiedyś do nich podejdę.
Co to za cudo te "Safety: Up to ASIL-D"

https://www.st.com/en/automotive-microcontrollers/sp
c5-32-bit-automotive-mcus.html

do góry