Tolka oregelbunden data - Klient och Server
Re: Tolka oregelbunden data - Klient och Server
Nu är jag tydligen nybörjare - men jag har fått det att fungera genom alla år, något som den "erfarna" Al tydligen inte klarar.
En länk till Al: Läs detta, Al, fastän jag vet att du inte förstår det.
Jag har genom "alla" år kört med STX (0x02)<Data><Checksum>ETX (0x03).
Data i ASCII (värdet 123 blir alltså '1', '2', '3' osv.) Checksum blir då en hexadecimal utskrift.
Datacheck: Om alla värden är inom 'A'-'F' eller '0'-'9' är saken biff. Då ska checksum kollas och om allt är bra plockar jag ut data.
Ibland behövs det fler värden, då separerar jag med t.ex.'|' eller ',' - lite beroende på vad som behövs.
Och tänk sig - det har fungerat riktigt bra under alla åren...
En länk till Al: Läs detta, Al, fastän jag vet att du inte förstår det.
Jag har genom "alla" år kört med STX (0x02)<Data><Checksum>ETX (0x03).
Data i ASCII (värdet 123 blir alltså '1', '2', '3' osv.) Checksum blir då en hexadecimal utskrift.
Datacheck: Om alla värden är inom 'A'-'F' eller '0'-'9' är saken biff. Då ska checksum kollas och om allt är bra plockar jag ut data.
Ibland behövs det fler värden, då separerar jag med t.ex.'|' eller ',' - lite beroende på vad som behövs.
Och tänk sig - det har fungerat riktigt bra under alla åren...
Re: Tolka oregelbunden data - Klient och Server
Vi har traditionellt (då all kommunikation hade en RS232 del någonstans, oftast i den
sista länken mot produktionsutrustningen) använt STX/ETX för att avgränsa meddelanden.
Sedan ett år tillbaka (idag kör vi inte RS232 mot nya utrustningar längre, alla PLCer och
liknande har LAN port inbyggt) gått över till att inte ha något speciellt starttecken och
bara avsluta alla meddelanden med en enkel CR.
Så idag är allt ASCII, utom terminatorn (CR) som terminal drivern använder för att
avsluta läsningen så att vi alltid får ett komplett meddelande oavsett om TCPIP har
valt att dela det på flera packet på nätet.
Vi har nog 50-60 PLCer i olika utrustningar med var sin kommunikations process.
Fungerar väldigt stabilt och bra...
sista länken mot produktionsutrustningen) använt STX/ETX för att avgränsa meddelanden.
Sedan ett år tillbaka (idag kör vi inte RS232 mot nya utrustningar längre, alla PLCer och
liknande har LAN port inbyggt) gått över till att inte ha något speciellt starttecken och
bara avsluta alla meddelanden med en enkel CR.
Så idag är allt ASCII, utom terminatorn (CR) som terminal drivern använder för att
avsluta läsningen så att vi alltid får ett komplett meddelande oavsett om TCPIP har
valt att dela det på flera packet på nätet.
Vi har nog 50-60 PLCer i olika utrustningar med var sin kommunikations process.
Fungerar väldigt stabilt och bra...
Re: Tolka oregelbunden data - Klient och Server
Så du menar att om jag har A, B, C, D att skicka så skickar jag:lillahuset skrev:Al: Tja, jag har programmerat för försörjning i snart fyrtio år och har lärt mig att strängar brukar vara väldigt användbara.
Hur brukar du lösa "big endian" och "little endian" i binära dataströmmar? Med strängar blir det trivialt.
Hur debuggar du binärdata på väg mellan två system? Jo du använder något verktyg som kan tolka protokollet. Inget konstigt.
Debugga ASCII-data? Det lämnar jag till dig att lista ut.
A-B-C-D
Och sedan så delar jag på strängen grundat på "-" ? Det är normal teknik? Min programmeringslärare sade att man ska helst undvika strängar så gått som det går. Det har med att det finns alltid effektivare sätt.
Men stämmer det?
Re: Tolka oregelbunden data - Klient och Server
Trots att jag ska bara kommunicera via localhost? Det är alltså två program som ska tala med varandra.mrfrenzy skrev:Varför uppfinna hjulet på nytt?
Använd ett befintligt protokoll tex mqtt, modbus, canbus.
- Lennart Aspenryd
- Tidigare Lasp
- Inlägg: 12607
- Blev medlem: 1 juli 2011, 19:09:09
- Ort: Helsingborg
Re: Tolka oregelbunden data - Klient och Server
Nu måste jag lägga mig i detta!
Så länge man har kontroll över både sändandet och mottageriet så kan man språka hur som helst.
Bara man själv kommer ihåg regelverket.
Det verkar som om du Al_Bundy vill trolla upp olika åsikter istället för att lösa och klargöra en funktion.
Hur svårt kan det va?
Så länge man har kontroll över både sändandet och mottageriet så kan man språka hur som helst.
Bara man själv kommer ihåg regelverket.
Det verkar som om du Al_Bundy vill trolla upp olika åsikter istället för att lösa och klargöra en funktion.
Hur svårt kan det va?
Re: Tolka oregelbunden data - Klient och Server
Det är väldigt enkelt att skicka en sträng och sedan dela upp den. Men jag hörde från min erfarna lärare, som tycks nu inte vara så erfaren, att strängar ska man försöka undvika så mycket som det går då det finns bättre och effektivare sätt att skicka data.
Re: Tolka oregelbunden data - Klient och Server
Och varför skall man undvika textsträngar?
jag tror du har missuppfattat det hela rätt ordentligt.
Ja, naturligtvis finns det bättre och effektivare sätt att skicka data, du kan alltid skicka som int8, sint8, int16, sint16, int32 sint32, real, osv (i all oändlighet).Men det förutsätter ju alltid att moottagaren vet vad som skickas.
jag tror du har missuppfattat det hela rätt ordentligt.
Ja, naturligtvis finns det bättre och effektivare sätt att skicka data, du kan alltid skicka som int8, sint8, int16, sint16, int32 sint32, real, osv (i all oändlighet).Men det förutsätter ju alltid att moottagaren vet vad som skickas.
Re: Tolka oregelbunden data - Klient och Server
PLC är riktigt fint. Kör TTC control med Codesys 2.3 för att programmera mikroprocessorer och det är kul faktiskt. Men i detta fall så använder jag Python och Java för att tala med varandra.sodjan skrev:Vi har traditionellt (då all kommunikation hade en RS232 del någonstans, oftast i den
sista länken mot produktionsutrustningen) använt STX/ETX för att avgränsa meddelanden.
Sedan ett år tillbaka (idag kör vi inte RS232 mot nya utrustningar längre, alla PLCer och
liknande har LAN port inbyggt) gått över till att inte ha något speciellt starttecken och
bara avsluta alla meddelanden med en enkel CR.
Så idag är allt ASCII, utom terminatorn (CR) som terminal drivern använder för att
avsluta läsningen så att vi alltid får ett komplett meddelande oavsett om TCPIP har
valt att dela det på flera packet på nätet.
Vi har nog 50-60 PLCer i olika utrustningar med var sin kommunikations process.
Fungerar väldigt stabilt och bra...
Så ska jag satsa och köra på strängar?
Re: Tolka oregelbunden data - Klient och Server
I detta fall vet mottagaren vilken ordning data skickas, men problemet är att datan läses in oregelbundet. Det förhindrar ibland vilken ordning datan har skickats, men inte alltid. Så det blir osäkert för mig att läsa utav datan.TomasL skrev:Och varför skall man undvika textsträngar?
jag tror du har missuppfattat det hela rätt ordentligt.
Ja, naturligtvis finns det bättre och effektivare sätt att skicka data, du kan alltid skicka som int8, sint8, int16, sint16, int32 sint32, real, osv (i all oändlighet).Men det förutsätter ju alltid att moottagaren vet vad som skickas.
Re: Tolka oregelbunden data - Klient och Server
När du läser socket'en i python så kan du inte vara säker på att du får hela meddelandet, särskilt om du inte skickar hela på en gång, så antingen måste du läsa av socketen och räkna antalet bytes, och avsluta när du tagit emot så många bytes du vill ha, eller skicka med en "avslutnings-byte", en markör som indikerar att meddelandet är slut.
observera som jag skrev sist, varje Java int (som är 4 byte) kommer att i mottagande python ända bli 4 byte, dvs du kommer att ha tre "nollor" innan. Hur stora tal ska du skicka? Du kan ju tex ändra i java så du skickar Java byte istället, då slipper du "nollorna"
edit:
nåt liknande detta borde lösa det, (hittat på nätet, är dålig på python):
edit2:
koden ovan läser tills socket.recv(1) returnerar 0, skickar du med ojämna mellanrum kommer du inte få hela meddelande utan då behöver du en markör som meddelar avslut
observera som jag skrev sist, varje Java int (som är 4 byte) kommer att i mottagande python ända bli 4 byte, dvs du kommer att ha tre "nollor" innan. Hur stora tal ska du skicka? Du kan ju tex ändra i java så du skickar Java byte istället, då slipper du "nollorna"
edit:
nåt liknande detta borde lösa det, (hittat på nätet, är dålig på python):
Kod: Markera allt
def read_socket():
return socket.recv(1)
data = b''.join(iter(read_socket, b''))
koden ovan läser tills socket.recv(1) returnerar 0, skickar du med ojämna mellanrum kommer du inte få hela meddelande utan då behöver du en markör som meddelar avslut
Re: Tolka oregelbunden data - Klient och Server
Får man fråga vad det var för programmeringsutbildning du gick och var? Endera har du missuppfattat läraren grovt eller så lever personen i fråga i någon sluten bubbla. Går väl inte att kategoriskt säga att strängar är dåligt.... beror ju helt på hur man tillämpar det helaAl_Bundy skrev:Det är väldigt enkelt att skicka en sträng och sedan dela upp den. Men jag hörde från min erfarna lärare, som tycks nu inte vara så erfaren, att strängar ska man försöka undvika så mycket som det går då det finns bättre och effektivare sätt att skicka data.
Re: Tolka oregelbunden data - Klient och Server
Gick ingen programmeringsutbildning. Jag är en industrimekaniker som har tagit masterexamen då jag insåg att jag ville inte vara en industriarbetare, utan, utvecklare utav mina egna idéer.
Jag är renodlad praktiker och jag läst mycket reglerteknik och systemidentifiering. Jag är mycket intresserad utav kalmanfilter. Jag har nog tagit för mycket på allvar vad läraren har sagt. Normalt brukar jag med en nypa salt vad läraren säger.
Jag är renodlad praktiker och jag läst mycket reglerteknik och systemidentifiering. Jag är mycket intresserad utav kalmanfilter. Jag har nog tagit för mycket på allvar vad läraren har sagt. Normalt brukar jag med en nypa salt vad läraren säger.
Re: Tolka oregelbunden data - Klient och Server
Visserligen är OSI-modellen av nätverkstackar lite väl akademisk/överdriven/föråldrad/osv men om du läser på lite med en nypa salt så kommer du nog få ett antal insikter. Lästips: Computer Networks av Andrew S Tanenbaum.
Re: Tolka oregelbunden data - Klient och Server
> ...Men i detta fall så använder jag Python och Java...
Det som diskuteras här är komplett oberoende av vilka verktyg/språk
man använder så länge som man ligger och kör på socket-nivån. Då
har man alltid samma problem att tackla. D.v.s. att trafiken över själva
nätverkat inte alltid motsvarar det som man sänder, det kan delas upp
i olika paket så som TCPIP finner lämpligt.
Antingen har man ett lager mellan nätverket och applikationen som
hanterar det, eller så får man hantera det själv i applikationen.
Sen, när det gäller "strängar" (definitionen av en "sträng" är lite otydlig)
så handlar det mest om att hitta ett format som har lägst sannolikhet för
att misstolkas mellan sändare och mottagare. Binära numeriska format
(speciellt om man börjar blanda in float i det hela) kräver att man har mer
koll än om man skickar numeriska värden som teckensträngar, "123" o.s.v.
Det som diskuteras här är komplett oberoende av vilka verktyg/språk
man använder så länge som man ligger och kör på socket-nivån. Då
har man alltid samma problem att tackla. D.v.s. att trafiken över själva
nätverkat inte alltid motsvarar det som man sänder, det kan delas upp
i olika paket så som TCPIP finner lämpligt.
Antingen har man ett lager mellan nätverket och applikationen som
hanterar det, eller så får man hantera det själv i applikationen.
Sen, när det gäller "strängar" (definitionen av en "sträng" är lite otydlig)
så handlar det mest om att hitta ett format som har lägst sannolikhet för
att misstolkas mellan sändare och mottagare. Binära numeriska format
(speciellt om man börjar blanda in float i det hela) kräver att man har mer
koll än om man skickar numeriska värden som teckensträngar, "123" o.s.v.