Użytkownik "Adam Przybyla" <a...@g...pl> napisał w wiadomości
news:gt1no3$fd8$1@polsl.pl...

> ... chcesz weryfikowac dane poprzez weryfikacje XML, tak?

To tez. Tyle, ze nie bezposrednio.

Od tej strony istotne jest, zeby miec mozliwosc przechodzenia:
1. _od_ schem wygenerowanych przez analitykow i konsultantow wyposazonych w
spaja
2. _przez_ zwiezly/lakoniczny xml z wartosciami przyjaznymi dla (wcale nie)
hobbystow pracujacych na wspomianych protokolach
3. _do_ binarnego (ok, w hex'ach) zrzutu obszaru/obszarow pamieci urzadzen
embeded.
4. _i_z_powrotem_

Przy czym 3. ma byc xml'em (bo tak :/) a wiec koszernie bylo by, zeby 2.
chodzilo w tym samym standardzie, a calosc zawierala maksymalnie malo,
maksymalnie prostego xml'a (znaczy wysoka zawartosc cukru w cukrze ;).

Zeby bylo weselej, zamyslem jest, zeby maksymalna ilosc "xml'owatosci
jako-takiej" blizej komunikacji niz danych. Cos na wzor xLinka (jako-takiego
nie chce, za duzy szum to wygeneruje).

sz.

do góry

Użytkownik "Sebastian Biały" <h...@p...onet.pl> napisał w wiadomości
news:gt14o5$a7t$1@achot.icm.edu.pl...

> Nawet na modbus nie ma standardu. Głównie ze względu na kretynizm

Oficjalnie jest ;>

> 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

A to nie jest kwestia standardu jako-takiego, tylko "standardu
powielaczowego" ;>

> 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 ) :/

Ale dziala! I to na skale, o ktorej malo kto ma pojecie. I mi sie w tym
najbardziej podoba ;>

> 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

Jak uslyszalem (przez telefon) o co chodzi moim pierwszym komentarzem bylo:
"po...lo ich ?!?!"
W odpowiedzi uslyszalem, ze rozmowca w pierwszym odruchu pomyslal tak samo.

Tutaj trzeba myslec jak taksowkarz ;>

> 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 ...

Masz racje.

W ten sposob bylo by tak bez sensu, ze nawet posiadajac mentalnosc slupka
niekorporacyjnych taksiarzy nie dalo by sie nawet o temacie pomyslec.

Dlatego mysle o dodaniu (po /cienszej stronie/) warstwy "rozdlubywania"
xml'a, ktorego bebechy beda *wprost* obrazami obszarow pamieci w formie
wysylalnej/odbieranej bezposrednio.

Hardcorow nie bedzie - nie ma wymagania pakowania modbusa w modbusa. Jest
wymaganie posredniczenia xml'em (z /jeszcze/ dowolnoscia "wciecia" sie w
warstwy protokolow). A ja chce wymyslec to tak, zeby ominac etap analitykow
i konsultantow wyposazonych w spaja.

Kurde, moglem o tym napisac od razu. Operowalem na innym poziomie abstrakcji
:/

sz.

do góry

szomiz wrote:
>>Nawet na modbus nie ma standardu. G?ównie ze wzgledu na kretynizm
> Oficjalnie jest ;>

"Oficjalnie" to nawet nie wiadomo jaki wielomian CRC stosować. Pewnie ze
można powiedziec "to nie modbus" ale niestety i takie kfiatki trafilem
już u niektórych pseudo programistow firmware którzy pisali na obudowie
"modbus".

> Ale dziala!

Tylko Ci się wydaje. Na około 8 urządzen które musiałem zaprogramować
tylko dwa działaly. Reszta miała bugi w firmware które należalo
obchodzić. Ciekawostki typu "cos fi=64.15" bo jakiś pokemon źle liczył
swój magiczny algorytm szyfrowania integerów czy tez wesołe utrzymywanie
RS485 w stanie "0" w sposób randomiczny ("bo wie pan, nasze urzadzenie
musi być na dedykowanym konwerterze") tudzież mapa pamięci modbusa która
inaczej wyglądala w zależności od ilości czytanych rejestrow (i pogody w
Słupsku). IMHO skoro nawet tak trywialnego pomysłu jak modbus banda
ignorantów nie potrafi prawidłowo zaprogramować to co dopiero gdy pojawi
się cos bardziej wypasionego jak xml. Ach zapomnialem dodać ze
urzadzenia automatyki mają niepoprawialne firmware. Prawdopodobnie
makefile natychmiast po kompilacji kasuje wszystkie źrodla albo
repozytorium svn detonuje dysk po checkoucie. Przynajmniej tak mi wynika
z zapytań mailowych czy nie mogli by tych bugow poprawić.

> I to na skale, o ktorej malo kto ma pojecie. I mi sie w tym
> najbardziej podoba ;>

Mi w ogole. Modbus to nastepny standard w informatyce który powstal
"przypadkiem". Absolutnie kretyński w każdym calu. Jak wszystkie inne
przypadkowe standardy.

> Dlatego mysle o dodaniu (po /cienszej stronie/) warstwy "rozdlubywania"
> xml'a, ktorego bebechy beda *wprost* obrazami obszarow pamieci w formie
> wysylalnej/odbieranej bezposrednio.

Wymysliłeś modbusa w innym opakowaniu. Modbus to tez (prawie) obraz
pamięci w prost zapakowany w trywialna ramkę. Dwa problemy:

a) co jesli xml będzie poprawny, ale zmodyfikowany (np kolejnośc tagów)?
Wysypiesz się czy obsłużysz? Ktoś mi zabroni wysłać xmla o długości 4MB
gdzie 3.99MB zajmują komentarze?

b) Co z notacją little/big endian i zapisywaniem floatów? Wysyłanie
floatów w postaci binarnej to kupa. Tak czy inaczej musisz pasować. Bez
dodatkowego RAMu w uC chyba się nie obejdze. Może to argument dla
marketoida który to wymyślił: będzie za drogie.

> Hardcorow nie bedzie - nie ma wymagania pakowania modbusa w modbusa. Jest
> wymaganie posredniczenia xml'em (z /jeszcze/ dowolnoscia "wciecia" sie w
> warstwy protokolow). A ja chce wymyslec to tak, zeby ominac etap analitykow
> i konsultantow wyposazonych w spaja.

IMHO wydzie Ci na zdrowie jesli normalne urzadzenie Modbus przepuścisz
przez opakowywacz do xmla Bedzie działać prawie po staremu a marketoid
bedzie mogł sobie oglądać ramki xmla latajace po sieci za które
zapłacił. Zaimplementujesz język zapytac xml->modbus->xml i bedzie
banglać z dowolnym urzadzeniem/urzadzeniami modbus (buhahaha :/).

> Kurde, moglem o tym napisac od razu. Operowalem na innym poziomie abstrakcji
> :/

To jest _za wysoki_ poziom abstrakcji pakowac xmla tam gdzie w ogole
chodzi o coś kompletnie innego niz czytelnośc komunikatow latających po
kablu RS485.

do góry

Użytkownik "Sebastian Biały" <h...@p...onet.pl> napisał w wiadomości
news:gt2ior$6q2$1@achot.icm.edu.pl...

>> Dlatego mysle o dodaniu (po /cienszej stronie/) warstwy "rozdlubywania"
>> xml'a, ktorego bebechy beda *wprost* obrazami obszarow pamieci w formie
>> wysylalnej/odbieranej bezposrednio.
>
> Wymysliłeś modbusa w innym opakowaniu. Modbus to tez (prawie) obraz
> pamięci w prost zapakowany w trywialna ramkę. Dwa problemy:

Tyle, ze modbus jest jednym z kilku protokolow ktore trzeba wziac pod uwage.
To czego szukam (co usiluje wymyslic) to taki sposob
klasyfikowania/grupowania typow wartosci, ktory pozwoli na (w miare) proste
wykonywanie obrazow pamieci po "grubszej" stronie.

> a) co jesli xml będzie poprawny, ale zmodyfikowany (np kolejnośc tagów)?

A co to jest "kolejnosc tagow" w xml'u? I jak sie stwierdza, czy _ten_ xml
rozni sie pod tym wzgledem od _poprzedniego_? Zostawmy zagadnienie
XML'owatosci jako-takiej... Prosze...

> Wysypiesz się czy obsłużysz? Ktoś mi zabroni wysłać xmla o długości 4MB

Obsluze (wysypie sie co najwyzej urzadzenie ;). Nikt nie zabroni wyslania.
Wypracowywana koncepcja polega na tym, zeby nie zmuszac do wysylania 4 MB w
sytuacjach, w ktorych wystarczajace bedzie spytne poinformowanie urzadzenia,
ze wartosci od komorki x do komorki y nalezy zastapic tym co pomiedzy ">" a
"<" (i jak sie zachowac, jezeli rozmiar nowych wartosci jest inny niz
rozmiar starych...).

4 MB mnie nie przeraza. Od okolo roku dosc skutecznie wysylam po GPRS'ie
(EDGE tylko jezeli ktos nie zapomni wystawic anteny przez lufcik) pelny
zestaw ulic DC i czesci okolicznych wiosek do modbusa wlasnie.

> gdzie 3.99MB zajmują komentarze?

Jest drobna roznica pomiedzy "odebrac" a "przetworzyc"...

> b) Co z notacją little/big endian i zapisywaniem floatów? Wysyłanie
> floatów w postaci binarnej to kupa. Tak czy inaczej musisz pasować. Bez
> dodatkowego RAMu w uC chyba się nie obejdze. Może to argument dla
> marketoida który to wymyślił: będzie za drogie.

I o tym miedzy innymi chialem porozmawiac...

Do jakiego momentu warto sie przejmowac rzeczami typu "zakres w kontekscie
bitowego rozmiaru adresowalnej jednoski konkretnego protokolu", a od jakiego
nie pieprzyc sie w drobne, tylko ciagnac/wysylac jak leci a niuansami
zajmowac sie tam, gdzie nie ma problemow z moca obliczeniowa.

> To jest _za wysoki_ poziom abstrakcji pakowac xmla tam gdzie w ogole
> chodzi o coś kompletnie innego niz czytelnośc komunikatow latających po
> kablu RS485.

No to wytlumacz to nawiedzonym urzednikom decydujacym o tym co bedzie trzeba
obsluzyc, zeby nie wypasc z rynku.

Moja prospoleczna aktywnosc skupia sie na edukacji zapobiegajacej
wykluczeniu informatycznemu w srodowiskach wiejskich, a nie na zwalczaniu
sekciarstwa utrzymujacego sie z moich podatkow...

Jest szansa na wypracowanie regul (standardu) niewymagajacego zaglebiania
sie w pieciopoziomowe schemowe includy. Wyjdze - dobrze. Nie wyjdzie - tez
dobrze.

sz.

do góry

TYPE "szomiz":
> Do jakiego momentu warto sie przejmowac rzeczami typu "zakres w
> kontekscie bitowego rozmiaru adresowalnej jednoski konkretnego
> protokolu", a od jakiego nie pieprzyc sie w drobne, tylko
> ciagnac/wysylac jak leci a niuansami zajmowac sie tam, gdzie nie ma
> problemow z moca obliczeniowa.
na chory rozum wystarczy obliczyć rozmiar struktury opisującej szczegół zmiany i
porównać do rozmiaru struktury opisującej zmianę.
f(x) < g1(x) + g2(x) + ..., gdzie f(x) to rozmiar opisu zmiany, a g(x) to rozmiar
opisu szczegółu zmiany.
--
qo |) CPL: cs[0..1] (ss[0..1]) p lvl of curr code!
_x/ , RPL: seg_sel[0..1] privilege lvl of seg_sel!
| ng __ -- __ -- __ -- __ -- __ -- __ -- __ -x86-,
,__ -- __ -- DPL: 2._word_of_seg_desc[13..14]:`f seg_desc ,

do góry

szomiz wrote:
> Tyle, ze modbus jest jednym z kilku protokolow ktore trzeba wziac pod uwage.
> To czego szukam (co usiluje wymyslic) to taki sposob
> klasyfikowania/grupowania typow wartosci, ktory pozwoli na (w miare) proste
> wykonywanie obrazow pamieci po "grubszej" stronie.

Inne protokoły nie sa obrazami pamięci. Mogą być zorientowane
zdarzeniowo, wymagają rygorów czasowych, mają dodatkowe ficzery (np.
priorytety ramek), kolizyjnośc etc. Nie widze za dużego sensu unifikowania.

>>a) co jesli xml bedzie poprawny, ale zmodyfikowany (np kolejno?c tagów)?
> A co to jest "kolejnosc tagow" w xml'u? I jak sie stwierdza, czy _ten_ xml
> rozni sie pod tym wzgledem od _poprzedniego_? Zostawmy zagadnienie
> XML'owatosci jako-takiej... Prosze...

Nie mogę tego zostawić xmlowi bo sam pisaleś o upchnięciu tego w
urzadzeniu na jakims kontrolerze. Wtedy te trywialne problemy które
zwyczajowo same się załatwiają mogą okazać się nie do przeskoczenia w
8kB pamięci.

>>Wysypiesz sie czy obs?u?ysz? Kto? mi zabroni wys?aae xmla o d?ugo?ci 4MB

> Obsluze (wysypie sie co najwyzej urzadzenie ;). Nikt nie zabroni wyslania.

Więc mogę poslać dowolny xml po RS485 który trzeba przeparsować? Choćby
po to żeby wiedziec gdzie zaczyna sie nastepny xml do parsowania (np dla
innego urzadzenia). Trudno mi sobie wyobrazić programistow firmware nie
potrafiących zrobić działającego modbusa żeby dali radę zrobic praser
xmla. I to bez wymiany hardware bo to koszty.

> Wypracowywana koncepcja polega na tym, zeby nie zmuszac do wysylania 4 MB w
> sytuacjach, w ktorych wystarczajace bedzie spytne poinformowanie urzadzenia,
> ze wartosci od komorki x do komorki y nalezy zastapic tym co pomiedzy ">" a
> "<" (i jak sie zachowac, jezeli rozmiar nowych wartosci jest inny niz
> rozmiar starych...).

To już nie będzie xml. Ja sobie mogę w xml wstawic <!-- -->. Nie ma tu
mowy o sprycie, tylko parsowanie. Urzadzenie powinno sprasować kazdy
xml, nawet z niepoprawna zawartością ale poprawna skladnia, bo może nie
jest adresowany do niego. przypominam że na kablach RS485 wisi więcej
niż 1 urzadzenie.

> 4 MB mnie nie przeraza. Od okolo roku dosc skutecznie wysylam po GPRS'ie
> (EDGE tylko jezeli ktos nie zapomni wystawic anteny przez lufcik) pelny
> zestaw ulic DC i czesci okolicznych wiosek do modbusa wlasnie.

I obsługujesz tego GPRSa w 8kB pamięci RAM procesora ~16MHz? To teraz
zastanow się ile miejsca zajmie parsowanie xmla i dlaczego nie ma to
sensu. na marginesie: większośc urzadzen modbusowych jakie widzialem
uważała by za luksus AŻ 8kB SRAM.

>>gdzie 3.99MB zajmuj? komentarze?
> Jest drobna roznica pomiedzy "odebrac" a "przetworzyc"...

Na paru kB pamięci nie ma to znaczenia - i tak musisz gdzieś gromadzić
drzewo przetwarzania żeby pilnować zamykania tagów/komentarzy.

> Do jakiego momentu warto sie przejmowac rzeczami typu "zakres w kontekscie
> bitowego rozmiaru adresowalnej jednoski konkretnego protokolu", a od jakiego
> nie pieprzyc sie w drobne, tylko ciagnac/wysylac jak leci a niuansami
> zajmowac sie tam, gdzie nie ma problemow z moca obliczeniowa.

Skoro masz mieć xmla to uważałbym za kretyńskie korzystac z niego jak
opakowania do pamięci uC. Niestety podejście niekretyńskie jest bardzo
cieżko realizowalne na małych uC. Sens xmla w tym momencie znika. Bo to
takie samo tępe opakowanie jak modbus. Żadnych plusów same minusy.

>>To jest _za wysoki_ poziom abstrakcji pakowac xmla tam gdzie w ogole
>>chodzi o co? kompletnie innego niz czytelno?c komunikatow lataj?cych po
>>kablu RS485.

> No to wytlumacz to nawiedzonym urzednikom decydujacym o tym co bedzie trzeba
> obsluzyc, zeby nie wypasc z rynku.

Jest zawsze tylko jeden argument: za drogie w implementacji i 0
ficzerow. Kasa tępego urzednika przekona najbardziej.

> Jest szansa na wypracowanie regul (standardu) niewymagajacego zaglebiania
> sie w pieciopoziomowe schemowe includy. Wyjdze - dobrze. Nie wyjdzie - tez
> dobrze.

Nie ma szansy. Chyba że utopisz 10x większą kase na procesory potrafiace
swobodnie parsować xmla "gdyż xml jest cool". Wtedy można sklecic
stronkę firmy "future automation protocols" i czekać na zlecenia ... :D

Z chęcią bym się dowiedział jaki byl proces decyzyjny do momentu wyboru
xmla. Kiedyś wśród automatykow nawet istniał taki żart, ze przychodzi na
hale javowiec i programuje czujnik położenia Springiem z xmlem. Ja widze
wlasnie ze to żaden żart i ktos naprawde o tym pomyślal ignorując
parenaście problemów jake xml generuje nie dając zbsolutnie _nic_ w zamian.

do góry

Użytkownik "Sebastian Biały" <h...@p...onet.pl> napisał w wiadomości
news:gta8ef$art$1@achot.icm.edu.pl...

> Z chęcią bym się dowiedział jaki byl proces decyzyjny do momentu wyboru
> xmla. Kiedyś wśród automatykow nawet istniał taki żart, ze przychodzi na
> hale javowiec i programuje czujnik położenia Springiem z xmlem. Ja widze
> wlasnie ze to żaden żart i ktos naprawde o tym pomyślal ignorując
> parenaście problemów jake xml generuje nie dając zbsolutnie _nic_ w
> zamian.

Jak sie wszystko poprzedawnia to moze napisze o tym ksiazke :P

Poki co jest jak jest. A- z technicznego punktu widzenia - moge miec w dupie
wyglad xml'i. Nawet w najnowszym formacie MS Worda moge pluc danymi.

Bo wszystko co obsuguje i tak chodzi w APN'ach, wiec nikt nie zauwazy, ile i
jakich procesorow zrobilo z prostych ramek po 502 slicznie powcinane xml'e.

Wiec odpuszcze temat - bo skoro nie mozna wymyslec nic, to bedzie sie trzeba
pieprzyc z dowolna bzdura, ktora wymysla fachowcy po 300 PLN/h znajacy
(przykladowego) modbusa z notki w Wikipedii :/

No offence.

EOT.

sz.

do góry

Użytkownik "czas dOSa" <u...@i...sk> napisał w wiadomości
news:gta780$e9e$1@news.mixmin.net...

> na chory rozum wystarczy obliczyć rozmiar struktury opisującej szczegół
> zmiany i porównać do rozmiaru struktury opisującej zmianę.
> f(x) < g1(x) + g2(x) + ..., gdzie f(x) to rozmiar opisu zmiany, a g(x) to
> rozmiar opisu szczegółu zmiany.

I wszystko sie pieknie wypieprzy jezeli nowy rozmiar bedzie wiekszy niz
stary.

Chyba, ze chcesz zapoponowac przesuwanie wartosci w pamieciach obslugiwanych
przez /watle/ procesory ...

sz.

do góry