Dopadl mnie badawczo-rozwojowy temat maksymalnie elastycznego mapowania
danych udostepnianych po protokolach typu RS, m-bus, modbus na struktury
xml'owe[1].

Zalozeniem jest stworzenie elastycznej, samoopisujacej sie struktury
przystosowanej do (*w*kolejnosci*):

1. Niskich (i bardzo niskich) predkosci danych - 9600 nalezy traktowac jako
predkosc zapewniajaca komfort.
2. Specyfiki protokolow, o ktorych w pierwszym akapicie.
3. Wydajnosci procesorow wykorzystywanych w sterownikach przemyslowych.
4. Przyzwyczajen programistow procesorow z pkt.3.
5. Minimalizowania narzutow na transmisje danych (pkt. 1.).
6. Minimalizowania narzutow na moc obliczeniowa zwiazana z *koniecznoscia*
wydalenia przez urzadzenie komunikatu xml [2].
7. Czytelnosci wydalanego xm'a.
8. Przetwarzalnosci otrzymanego xml'a.

Znaczy wymyslenie Swietego Grala ;>

Ze wstepnej analizy (wykonanej przy dobrej znajomosci modbusa oraz
pobiezniej RS'a i i m-bus'a) wyszlo mi, ze trzeba poklasyfikowac wartosci
[3]. Np. w ten sposob:

Pierwsze osiem bitow:

0x00 adres
0x01 znak: adres wzgledny/liczba ze znakiem
0x02 liczby (w tym wartosci logiczne)
0x04 data i czas
0x08 wartosc binarna
0x10 wartosc tekstowa
0x20 tablica
0x40 typ zlozony
0x80 typ wlasny

Wymyslam kolo, czy jest jakis standardard na "te rzeczy"?

Nastepne 8-ki rozwijalyby typy glowne, przykladowo:

0x00 0x.. -> wskazanie protokolu
0x01 0x.. -> adres wzgledny
0x02 0x00 -> wartosc logiczna (true== 0x01)
0x03 0x00 -> wartosc logiczna (true== 0xFF)
0x02 0x10 -> calkowita, bez znaku
0x03 0x11 -> staloprzecinkowa, ze znakiem

Sens rozwiniec - chwilowo - niewazny. Istotne jest czy pierwsze 8 bitow daje
szanse na wyprowadzenie wszystkich (rozsadnych) typow i czy nie ma na to
jakiegos standardu.

sz.

[1] Se ktos wymyslil, ze ma byc xml i juz. Na szczescie _jeszcze_ nie wie
jaki ;>
[2] *Koniecznoscia* (bo [1]). /Xml'izacja/ danych na serwerze akwizycyjnym
byla by prostsza i tansza. Ale ma byc w sterowniku [1].
[3] Przy cichym zalozeniu, ze nie dopuszczamy istnienia wartosci o
reprezenacji krotszej niz 8 bitow.

do góry

Drobiag, ale dla liczb, "dalej" na zasadzie /mniej wiecej/:

0x02 0x01 -> bez znaku, calkowita
0x03 0x11 -> ze znakiem, staloprzecinkowa.
...
0x02 0x41 -> bez znaku, zmiennoprzecinkowa
...
0x03 0x8. -> ze znakiem, wlasna ("." == rozmiar definicji)

sz.

do góry

szomiz wrote:

> Dopadl mnie badawczo-rozwojowy temat maksymalnie elastycznego mapowania
> danych udostepnianych po protokolach typu RS, m-bus, modbus na struktury
> xml'owe[1].

Dużo łatwiej wydobyć dane bezpośrednio ze strumienia bajtów idącego z
urządzenia, niż z jakiegoś dziwacznego XML-a.
XML jest słabo czytelny zarówno dla człowieka (mnóstwo nie niosących treści
a zajmujących miejsce znaczników, oraz &cośtam), jak i dla komputera (długo
go przetwarza).

do góry

Użytkownik "Wojciech Jaczewski" <w...@o...pl> napisał w wiadomości
news:gsutq1$1br$1@inews.gazeta.pl...
> szomiz wrote:
>
>> Dopadl mnie badawczo-rozwojowy temat maksymalnie elastycznego mapowania
>> danych udostepnianych po protokolach typu RS, m-bus, modbus na struktury
>> xml'owe[1].
>
> Dużo łatwiej wydobyć dane bezpośrednio ze strumienia bajtów idącego z
> urządzenia, niż z jakiegoś dziwacznego XML-a.
> XML jest słabo czytelny zarówno dla człowieka (mnóstwo nie niosących
> treści
> a zajmujących miejsce znaczników, oraz &cośtam), jak i dla komputera
> (długo
> go przetwarza).

No ale popatrz na [1] :(

Ja wiem, ze latwiej. Ja zyje z sekwencyjnego czytania modbusow. I nie widze
_zadnego_ merytorycznego_ uzasadnienia, zeby robic to inaczej.

Poza jednym: _klient_chce_miec_. A za stary jestem, zeby tracic minuty z
abonamentu i prad, zeby tlumaczyc, ze to nie ma sensu.

Nie chce rznac glupa i zaproponowac standardu pt:

<data type="modbus" addres="1" start="20" length="13" encoding="hexBinary"
xmlns="jakies-uri"><!--i tutaj to co biali ludzie czytaja obecnie--></data>

Ewnetualnie pojsc w druga strone i wygenerowac standardowego koszmaszka by
xmlspaj, ktory 16 bitow uzytecznej wartosci opakuje w 2 kB
pseudo-analitycznego belkotu.

Mam pomysl na "podstawy zalozen wstepnej propozycji" i pytam, czy istnieje
sensowny/popuralny standard okielznujacy kodowanie typow danych operujace na
bitach....

sz.

do góry

szomiz wrote:

> No ale popatrz na [1] :(

Nawet widziałem ten dopisek, ale jakoś nie zinterpretowałem go od razu
poprawnie.

> Ja wiem, ze latwiej. Ja zyje z sekwencyjnego czytania modbusow. I nie
> widze _zadnego_ merytorycznego_ uzasadnienia, zeby robic to inaczej.
>
> Poza jednym: _klient_chce_miec_. A za stary jestem, zeby tracic minuty z
> abonamentu i prad, zeby tlumaczyc, ze to nie ma sensu.
>
> Nie chce rznac glupa i zaproponowac standardu pt:
>
> <data type="modbus" addres="1" start="20" length="13" encoding="hexBinary"
> xmlns="jakies-uri"><!--i tutaj to co biali ludzie czytaja
> obecnie--></data>

Myślę, że warto trochę przeformułować temat, by nawiązać do tematyki i
spróbować udać się z nim na pl.comp.lang.java. Tam powinno być trochę
miłośników XML-a. Może któryś będzie miał dobry pomysł...

do góry

Użytkownik "Wojciech Jaczewski" <w...@o...pl> napisał w wiadomości
news:gsv8ur$krv$1@inews.gazeta.pl...

> Myślę, że warto trochę przeformułować temat, by nawiązać do tematyki i
> spróbować udać się z nim na pl.comp.lang.java. Tam powinno być trochę
> miłośników XML-a. Może któryś będzie miał dobry pomysł...

A dlaczego nie na pl.comp.xml? ;)

Temat - na tym etapie - nie ma wiele wspolnego z xml'em. Mnie chodzi, o to,
zeby procesor, ktory bedzie zmuszony do przyswojenia/wydalenia informacji
jak najmniej sie spocil, a programisci jak najmniej bluzgali. Jak temat
dostanie "milosnik", to wymysli taka kobyle, ze do najprostszego kamstrupa
bedzie trzeba dostawic dwurdzeniowy procesor...

Xml ma z tego wyjsc na koncu (i nie sadze, zebym mial z tym jakies problemy
;).

sz.

do góry

szomiz pisze:
> Drobiag, ale dla liczb, "dalej" na zasadzie /mniej wiecej/:
>
> 0x02 0x01 -> bez znaku, calkowita
> 0x03 0x11 -> ze znakiem, staloprzecinkowa.
> ....
> 0x02 0x41 -> bez znaku, zmiennoprzecinkowa
> ....
> 0x03 0x8. -> ze znakiem, wlasna ("." == rozmiar definicji)
>
> sz.

Coś się wydaje, że przelotny romans z XML-RPC by był przyjemny. A może
nawet coś się urodzi.

do góry

Użytkownik "Jacek Czerwinski" <...@...z.pl> napisał w wiadomości
news:gsvcmf$frv$1@news.onet.pl...

>> 0x03 0x8. -> ze znakiem, wlasna ("." == rozmiar definicji)
>>
>> sz.
>
> Coś się wydaje, że przelotny romans z XML-RPC by był przyjemny. A może
> nawet coś się urodzi.

Nie o to chodzi. Chodzi o to, ze skoro wartosc 13 (traktowana jako 8-mio
bitowy int) da sie wraz informacja o type zakodowac na 16 bitach, to ma byc
wyslane 16 bitow. I chodzi standard "wygladu" tych pierwszych bitow.

Ja potrzebuje duze ilosci danych, ktore - *jezeli*musza* - potrafia sie
same opisac. Po malych predkosciach.

Niepotrzebnie pisalem o tym xml'u :/

Przyblize. Zalozenie, jest takie, ze najlepszym przypadku urzadzenie
faktycznie wysyla/odbiera cos w stylu:

<data ref="cos-tam"><!--spora paczka danych--></data> [1]

Jezeli nie zna/nie rozumie podanego ref moze poinformowac o tym bez
koniecznosci wysylania/odbierania calosci niezozumialej tresci.

Wtedy dostanie, na przyklad:

<data def="cos-tam" refs="inne-cos-1 inne-cos-2">
<data ref="inne-cos-1"/>
<!---->
<data ref="inne-cos-2"/>
...

Gdzie, inne-cos'ie beda wskazaniami na definicje struktury ktora
najprawdopodobniej zna; w miejscu komentarza - informacje o strukturze,
ktora sie ma "naumiec" obslugiwac.

Jezeli inne-cos'ie beda niezrozumiale - sie o nie dopyta.

Chodzi - generalnie - o uzyskanie jak najlepszego ratio dane/metadane przy
nowych i powtarzalnych komunikatach.

Mnie na prawde nie chodzi o gadanie z lodowka przy pomocy SOAP po wifaju ;>

sz.

do góry

szomiz wrote:
> Dopadl mnie badawczo-rozwojowy temat maksymalnie elastycznego mapowania
> danych udostepnianych po protokolach typu RS, m-bus, modbus na struktury
> xml'owe[1].

Przyznam że kompletnie nie rozumiem, poniewaz z dalszego tekstu wynika
jakoby miało by to być wypluwane przez urzadzenie. Specyfika modbusa
wymaga żeby był krótki bo urzadzenia pracują na jednym kablu i
tragicznie powolnie (zazwyczaj 9600) oraz implementuja to na jakis
mizernej mocy obliczeniowej cpu. Dlaczego ten XML nie wiem, ale może coś
pośredniego: binarnie i elastycznie?

Właśnie z powodu zauwazenia że Modbus to kupa zrobilem wlasny protokół
binarny który jest zdecydowanie bardziej elastyczny i samoopisujacy, nie
tracąc czasu na parsowanie. No dobra, tylko jak go używam, ale
zredukował mi czas developingu firmware o pare rzedów, podobnie z softem
sterującym. A modbusa opakowuje tym moim i koniec problemów.

> i czy nie ma na to
> jakiegos standardu.

Nawet na modbus nie ma standardu. Głównie ze względu na kretynizm
developerów firmware którzy nie potrafią liczyc crc, psują sie jak za
szybko pytasz, mają nieco inne pojęcie 1ms niż reszta swiata, kupuja
troche inne kwarce do RS niz powinni, generują zapis liczb typu integer
mozliwie najbardziej przypominający szyfrowanie, itd. W automatyce
przemysłowej nic nie jest dobrze zrobione, przynajmniej pod kątem
firmware i komunikacji ( taki mocno subiektywnty wniosek wynikający z
walki z paroma urządzeniami modbus ) :/

> [1] Se ktos wymyslil, ze ma byc xml i juz. Na szczescie _jeszcze_ nie wie
> jaki ;>
> [2] *Koniecznoscia* (bo [1]). /Xml'izacja/ danych na serwerze akwizycyjnym
> byla by prostsza i tansza. Ale ma byc w sterowniku [1].

Przyznam, że jak ktoś chce jechać z Krakowa do Warszawy przez Wrocław to
się nie dyskutuje bo sensu brak. IMHO xml da tylko jedno - przy
mizernych predkościach komunikacja wzrośnie do ogromych rozmiarów i
prawdopodobieństwo błędu skoczy gwałtownie w góre. W dodatku jak sobie
wyobrażasz liczenie crc xmla żeby to crc było zgodne z zapisem xml? Da
się, ale po co ...

do góry

szomiz <s...@k...dostawac.reklamy.przez.net> wrote:
> U?ytkownik "Jacek Czerwinski" <...@...z.pl> napisa? w wiadomo?ci
> news:gsvcmf$frv$1@news.onet.pl...
>
>>> 0x03 0x8. -> ze znakiem, wlasna ("." == rozmiar definicji)
>>>
>>> sz.
>>
>> Co? si? wydaje, ?e przelotny romans z XML-RPC by by? przyjemny. A mo?e
>> nawet co? si? urodzi.
>
> Nie o to chodzi. Chodzi o to, ze skoro wartosc 13 (traktowana jako 8-mio
> bitowy int) da sie wraz informacja o type zakodowac na 16 bitach, to ma byc
> wyslane 16 bitow. I chodzi standard "wygladu" tych pierwszych bitow.
>
> Ja potrzebuje duze ilosci danych, ktore - *jezeli*musza* - potrafia sie
> same opisac. Po malych predkosciach.
>
> Niepotrzebnie pisalem o tym xml'u :/
>
> Przyblize. Zalozenie, jest takie, ze najlepszym przypadku urzadzenie
> faktycznie wysyla/odbiera cos w stylu:
>
> <data ref="cos-tam"><!--spora paczka danych--></data> [1]
>
> Jezeli nie zna/nie rozumie podanego ref moze poinformowac o tym bez
> koniecznosci wysylania/odbierania calosci niezozumialej tresci.
>
> Wtedy dostanie, na przyklad:
>
> <data def="cos-tam" refs="inne-cos-1 inne-cos-2">
> <data ref="inne-cos-1"/>
> <!---->
> <data ref="inne-cos-2"/>
> ...
>
> Gdzie, inne-cos'ie beda wskazaniami na definicje struktury ktora
> najprawdopodobniej zna; w miejscu komentarza - informacje o strukturze,
> ktora sie ma "naumiec" obslugiwac.
>
> Jezeli inne-cos'ie beda niezrozumiale - sie o nie dopyta.
>
> Chodzi - generalnie - o uzyskanie jak najlepszego ratio dane/metadane przy
> nowych i powtarzalnych komunikatach.
>
> Mnie na prawde nie chodzi o gadanie z lodowka przy pomocy SOAP po wifaju ;>
... chcesz weryfikowac dane poprzez weryfikacje XML, tak?
Z powazaniem
Adam Przybyla

do góry