Avoimen lähdekoodin automaatiojärjestelmä

[Mika K]

Taas on ruotsalaisilla asiat vähän paremmin, noilla hannu hanhille on aivan mahtava ohjelmistopaketti Proviewr.

Itse törmäsin tuohon jo yli kymmenen vuotta sitten ja hiljattain olen toteuttanut sillä erään prosessin tiedonkeruu- ja visualisointiprojektin. Voin lämpimästi suositella, tuntuu taipuvan hyvin moneen.

Harmi, että proviewr.se foorumin päivityksen myötä tänä keväänä kaikki viestiketjut ja vinkit katosivat. Löytyy siis osoitteesta www.proviewr.se

 

[nelikolie]

Harmi, että proviewr.se foorumin päivityksen myötä tänä keväänä kaikki viestiketjut ja vinkit katosivat. Löytyy siis osoitteesta www.proviewr.se

Jos sinne vanhalle foorumille on tarpeeksi muualta linkkailtu, niin se saattaisi yhä löytyä archive.org:in waybackmachine:sta.

Ihan mielenkiintoinen aihe.

 

[alfred_j_kwak]

Autonomy – Open-source PLC Software

autonomylogic.com

Autonomy | Industrial Automation Platform

The future of industrial automation. Modern interface, cloud orchestration, and powerful features for programming virtual PLCs.

autonomylogic.com

 

[Yleisajattelija]

Taas on ruotsalaisilla asiat vähän paremmin, noilla hannu hanhille on aivan mahtava ohjelmistopaketti Proviewr.

Itse törmäsin tuohon jo yli kymmenen vuotta sitten ja hiljattain olen toteuttanut sillä erään prosessin tiedonkeruu- ja visualisointiprojektin. Voin lämpimästi suositella, tuntuu taipuvan hyvin moneen.

Harmi, että proviewr.se foorumin päivityksen myötä tänä keväänä kaikki viestiketjut ja vinkit katosivat. Löytyy siis osoitteesta www.proviewr.se

Nojaa, ruotsalaiset osaavat johtamisen ja diskuteerauksen paremmin kuin suomalaiset, mutta kovan tekemisen osalta hieman heikompaa.

Reaaliaikalinuxin värkkääminen on varsin hankala juttu, mutta toki tehdään mielellään yhteistyötä ruosalaisten kanssa .

 

[Yleisajattelija]

...meillä onkin kohta tulossa HAT-moduli + ajurit tuohon Piihin. Saisikohan ruotsalaiset kysyttyä briteiltä, että saataisiinko tarvittavat datat loaderin asentamiseksi tinycoreen? Barebootista ei vielä ole tietoa, että toimiiko aikuisoikeasti, mutta se tai U-boot pitäisi saada survottua tuohon...

 

[Yleisajattelija]

Barebox U-boot.v2 on perinyt joitain periaatteellisia ongelmia U-bootista, joista en ole erityisemmin pitänyt:

Barebox

www.barebox.org

...viksummat (alkuperäinen bareboot etc.) viritykset taitaa tosin olla kuolemassa.

 

[Yleisajattelija]

....ja susi on ihmiselle susi...

wolfSSL – Embedded SSL/TLS Library

www.wolfssl.com

 

[nelikolie]

Barebox U-boot.v2 on perinyt joitain periaatteellisia ongelmia U-bootista, joista en ole erityisemmin pitänyt:

Barebox

www.barebox.org

...viksummat (alkuperäinen bareboot etc.) viritykset taitaa tosin olla kuolemassa.

Avointa lähdekoodia, että senkus korjaat mieleisekses.

 

[Yleisajattelija]

Avointa lähdekoodia, että senkus korjaat mieleisekses.

Yritin joskus lueskella U-bootin lähdekoodia selvittääkseni yhden Armin SOC:n konffitiedostoa, mutta on sellaista sössökoodia, ettei siitä saa tolkkua.

Tuota bareboxia en ole (vielä) yrittänyt härkkiä, mutta pitäisi just nyt aloitella, ja sitä varten tarvittaisiin briteiltä Piin samaiset konffitiedostot, joita viime kerralla eivät suostuneet antamaan....

 

[Yleisajattelija]

Noissa Rasperry Pi:ssä on käytössä jonkinsorttinen DTB:

How to customize the dtb (device tree binary) on the Raspberry Pi

Every so often, when you're debugging weird hardware issues on SBCs like the Raspberry Pi, it's useful to get way down into the guts of how the Pi represents its hardware to Linux. And the Linux kernel uses a method called Device Tree overlays to do it. On the Pi 5 (and other Pis), these...

www.jeffgeerling.com

Armelissa nuo vaan ovat tunnetusti ongelmallisia:

Linux and the Devicetree — The Linux Kernel documentation

Piissä on vakiomuistit ja vakio SOC, joten periaatteessa jos tuo on oikein toteutettu, HAT-ajurit PITÄISI voida liittää ajoaikaisesti systeemiin, mutta käytännössä taitaa tulla ongelmia:

HAT EEPROM DTB and RTC on I2C0

I'm having a problem creating a DTB for a HAT auto-configuration. I have a DS3231 RTC module attached on I2C0 (GPIO0 and GPIO1). It incorporates an AT24C32 EEPROM at address 0x50. To get it working,

raspberrypi.stackexchange.com

Jos tuo nyt tehdään silleen kunnolla, pitäisi olla SOC:ista joku R&D versio, jossa on JTAG-debuggeriportti ja muistit auki, mutta käytännössä sellaista voi olla mahdoton saada. Lisäksi käytännössä em. debuggeriliitännän käyttöön pitää olla ARM:in tuki, speksejä tuohon ei ole yleisessä jaossa. Noiden debuggaus on sitäpaitsi pelkkää painajaista, ja pitää olla varsin kovan luokan koodaaja, joka ylipäätään osaa noita hommia, joten taidamme unohtaa sen tässä vaiheessa.

Lähinnä kysymys on siitä, mikä on Rasberryn käytäntö että onko vakio-dtb.llä (tai voiko dtb:hen tehdä tarvittavat muutokset) mahdollista saada ajurille esim. muistia ja I/O-avaruutta allokoitua oman HAT-moduilin ja ajurin tekemiseksi tinycoreen?

 

[Yleisajattelija]

Tuo Proviewr käyttää mm. Profibus:ia I/O-liikenteeseen:

Profibus - Wikipedia

en.wikipedia.org

Noissa kaikissa nykyisissä reaaliaikalinuxeissa (mm. Yocto) on pari systeemistä ongelmaa, jotka periytyvät Unixista saakka. Torvalds osasi kernelin osalta varsin hyvin kierrellä noita ongelmia, mutta mm. Unixin filesystemin ja HW-rajapinnan osalta ne ovat jääneet (lähes) kaikkiin distroihin.

Distrot käyttävät vaihtelevasti standardia:

Filesystem Hierarchy Standard - Wikipedia

en.wikipedia.org

Tuo unix -ajatelu "kaikki on tiedostoja ja hakemistoja" ei istu mitenkään HW:n kanssa ja on yksi juurisyy mm. Proviewr ongelmiin.

Tuon ongelma on havaittu, ja rakenteellista korjausta yrietään tässä distrossa:

https://en.wikipedia.org/wiki/GoboLinux

Muutos on kuitenkin liian suuri, tuo vanhoihin ROM/RAM muistien ominaisuuksiin perustuva tiedostojako määrittelee pysyvästi kaikkien Unix-pohjaisten järjestelmien rakenteen, ja jos se korjataan silloin kaikki Unix/Linux softa pitäisi tehdä uudestaan.

Tinycoressakin on suuria yhteensopivuusvaikeuksia ramdisk:in käytön takia, mutta ne on jotenkin vielä hoidettavissa ja ratkaisee turvallisuusongelmat varsin hyvin. Unixin hakemistorakenne on ikuinen turvallisuusongelmien lähde ilman jotain Tinycoren ramddisk-tyyppistä ratkaisua.

Vastaava ongelma tulee laitteistoajurien kanssa, teolisuusautomaatio vaatii IBM-XT ja/tai HAT-tyyppisen laajennnusväylän ja dynaamisen ajurilatauksen. Se taas vaatii aika hyvä DTO:n toimiakseen, ja sitä on erittäin vaikea ympätä linuxiin (tai ylipäätään mihinkään käyttöjärjestelmään) ilman turvallisuusongelmia.

Ruotsalaisten voi olla ehkä vaikea hyväksyä asiaa, mutta ilman perusrakenteen muutosta joka korjaa nuo kaksi em. systeemistä ongelmaa tuo Proviewr ei tule koskaan pelaamaan kovin hyvin, eikä varsinkaan ole "kyberturvallinen".

 

[Mika K]

Sanottakoon, että suurin osa tuosta edellä mainitusta meni aivan yli hilseen. Mutta olisin kiinnostunut kuulemaan minkälaisiin käytännön ongelmiin olet törmännyt Proviewrn kanssa?

Profibus alkaa jäädä historiaan ja omakohtaisia kokemuksia sen käytöstä Proviewrn kanssa ei ole. Projektissani kommunikointi ulkoisten laitteiden kanssa hoituu ModbusTCP:llä. Sen suhteen ei ole ongelmia eteen tullut.

 

[alfred_j_kwak]

Modbus on kyllä siitä hieno protokolla että se on varmasti toiminnassa vielä täysmittaisen ydinsodankin jälkeen.
Profibus joutaa kyllä jäämäänkin pois.

 

[Yleisajattelija]

Sanottakoon, että suurin osa tuosta edellä mainitusta meni aivan yli hilseen. Mutta olisin kiinnostunut kuulemaan minkälaisiin käytännön ongelmiin olet törmännyt Proviewrn kanssa?

Profibus alkaa jäädä historiaan ja omakohtaisia kokemuksia sen käytöstä Proviewrn kanssa ei ole. Projektissani kommunikointi ulkoisten laitteiden kanssa hoituu ModbusTCP:llä. Sen suhteen ei ole ongelmia eteen tullut.

En tunne Proviewir ollenkaan, mutta tunnen reaaliaikalinuxin ongelmat, ja niitä varmuudella tulee jos joitain asioita ei tehdä oikein.

Ruotsalaiset ovat hyviä tekemään asioita joten epäilemättä Proviewr markkinoiden parhaita noissa asioissa, ja varmaan toimiikin käytännössä niissä sovelluksissa mitä sillä tehdään. Siitä huolimatta em- systeemivirheet olisi syytä korjata, jos aikoo tehdä softasta luotettavaa ja suorituskykyistä.

 

[Yleisajattelija]

Modbus on kyllä siitä hieno protokolla että se on varmasti toiminnassa vielä täysmittaisen ydinsodankin jälkeen.
Profibus joutaa kyllä jäämäänkin pois.

Modbus ei ole väylä vaan TCP/IP sovellus ja ARPANET on itse asiassa tehtykin juuri ydinsotaa varten:

ARPANET – Wikipedia

fi.wikipedia.org

...tosin ei käytännössä kyllä toimi ydinsodassa, kuten ei (todennnäköisesti) Modbus:kaan samoista syistä,,,

Modbus - Wikipedia

en.wikipedia.org

Nykyään USB/CAT-nopeudet ovat niin suuria, että useimmat teollisuussovellusten reaaliaikatarpeet hoituu sillä. Nuo "rugged industry-PC" ovat niin halpoja projektikustannuksiin ja erityisesti softauskuluihin verrattuja, että varsinaiset lisäkortit ovat jäämässä pois.

Jos meinaat ydinsotaa käydä, niin kannattaa korjata ensin em. pari ongelmaa....

 

[alfred_j_kwak]

 

[Jammu]

Asiahan ei tietysti minulle kuulu, mutta ajattelen lähinnä, miksi Raspberryä edes ajateltaisiin käytettäväksi semmoiseen liki reaaliaikatouhuun mihin se ei ole alunperinkään ajateltu - käsittääkseni alkuajatus Raspberrylle oli kaikkien ulottuville ja rahallisessti mahdolliseksi tehty korttitietokone ohjelmoinniin yms harjoitteluun joka tullessaan määriteltuin n 20 dollarin hintaiseksi ja rakennettiin broadcomin järjestelmäpiirin ympärille.

Tuo järjestelmäpiiri eri versioissaan ollut vielä siitä tyypillinen, että io nastojenkaan speksit ei ole kerrottu erityisen tarkkaan ja siellä on valmistajan dedikoimia nastoja jolloin ei ole siis kaikki io:t yhtä samaa.

Terveempää on lähteä projekti sellaisesta mikä on likellä oikeaa plc rautaa eli mikrokontrolleripohjalta.

Varmaan meni paljonkin pieleen lonkalta ja ulkomuistista äkkiseltään, mutta.. kunhan nyt sohaisin tätäkin aihetta

 

[nelikolie]

En tunne Proviewir ollenkaan,

Aiemmin kuitenkin;

on yksi juurisyy mm. Proviewr ongelmiin.

Tästä vois päätellä, että ehkä tämä ongelma on sulla, eikä Proviewr:illä.

Luokittellaan usein ulinaksi tuommoinen aloitus kehityskeskustelulle, jos ei liitetiedostoista edes .diff:iä löydy viemään oikeaan suuntaan.

 

[Yleisajattelija]

Aiemmin kuitenkin;

Tästä vois päätellä, että ehkä tämä ongelma on sulla, eikä Proviewr:illä.

Luokittellaan usein ulinaksi tuommoinen aloitus kehityskeskustelulle, jos ei liitetiedostoista edes .diff:iä löydy viemään oikeaan suuntaan.

Kuten sanoin, näissä on tiettyjä systeemisiä ongelmia ja kun näitä aikansa värkkää niin huomaa yritetäänkö niitä ratkoa vai ei. Nopealla selauksella Proviewr:stä ei löydy avainteemoja, joista voi päätellä yritetäänkö.

 

[Yleisajattelija]

Asiahan ei tietysti minulle kuulu, mutta ajattelen lähinnä, miksi Raspberryä edes ajateltaisiin käytettäväksi semmoiseen liki reaaliaikatouhuun mihin se ei ole alunperinkään ajateltu - käsittääkseni alkuajatus Raspberrylle oli kaikkien ulottuville ja rahallisessti mahdolliseksi tehty korttitietokone ohjelmoinniin yms harjoitteluun joka tullessaan määriteltuin n 20 dollarin hintaiseksi ja rakennettiin broadcomin järjestelmäpiirin ympärille.

Tuo järjestelmäpiiri eri versioissaan ollut vielä siitä tyypillinen, että io nastojenkaan speksit ei ole kerrottu erityisen tarkkaan ja siellä on valmistajan dedikoimia nastoja jolloin ei ole siis kaikki io:t yhtä samaa.

Terveempää on lähteä projekti sellaisesta mikä on likellä oikeaa plc rautaa eli mikrokontrolleripohjalta.

Varmaan meni paljonkin pieleen lonkalta ja ulkomuistista äkkiseltään, mutta.. kunhan nyt sohaisin tätäkin aihetta

Rasperryssä käytetyt ARM-SOC:it ovat sinällään hyvin suorituskykyisiä sekä uP:n että I/O:n suhteen. HW-keskeytykset ovat myös hyvin nopeita, tuolla peruskortilla tekee HW:n reaaliaikavasteen puolesta 95-99% prosenttia automaatiohommista. Pitää olla jo aika erikoinen juttu jos muisti/teho/aika ei riitä ja silloinkin kupeeseen voi juottaa jonkun signaaliprosessorin tai ASIC:in. Tai paras lienee nykyään USB-3 tai 1-10Gb Cat.