[ALG] reverse engineeren waarde vanuit binaire string.

[M4RTiN]

Ik wil graag lengtemeters en vierkante meter standen van een productie machine opvragen zodat we dit in een database gaan opslaan. We doen dit bijna met alle machines, vaak hebben ze wel een webinterface waar we deze data makkelijk kunnen opvragen. Dit merk leek het niet mogelijk, maar er is een lichtpuntje. De machine luistert op een tcp poort en als je connectie maakt spuugt hij een binaire string uit.

De fabrikant wil helaas geen documentatie verschaffen, maar gelukkig komen we zelf al een heel eind.

We hebben al diverse data zoals consumable data en de huidige status van de machine kunnen terugrekenen. Vaak probeer ik 2 strings te vergelijken zodra de machine iets heeft gedaan. De verschillen bekijk ik in een programma die de 2 verschillen van een file laat zien per regel.

Voorbeelden
1 veld geeft zonder omrekening een absolute waarde van 44 (klopt met bedieningspaneel 44 graden)
1 veld geeft voortgang opdracht in procenten, 0-255 is 0-100%

Inmiddels ben ik er achter welke waardes omhoog gaan wanneer er opdrachten zijn verwerkt, ik heb veranderingen geconstateerd bij 3 velden bij zowel de lengte meters als de vierkante meters.

Wanneer de vierkante meter stand 6914 is, geeft de data de volgende 3 waardes: 20, 7 en 3. Het lijkt een beetje op dat de volgende berekening klopt: (20*256)+(7*256)+3 = 6915. Je zou nog kunnen denken dat er misschien een afronding verschil is.

Maar bij de lengte meters gaat die berekening totaal niet op. Ik heb 2 verschillende waardes:

14/55/38 staat gelijk aan 6148
17/43/4 staat gelijk aan 6149

Ik heb diverse rekensommetjes gemaakt, maar ik kan er geen logica aan ontdekken. Misschien moet ik meer data verzamelen, of er ontgaat mij iets logisch...

[Freeaqingme]

M4RTiN schreef op vrijdag 3 juli 2020 @ 21:04:
14/55/38 staat gelijk aan 6148
17/43/4 staat gelijk aan 6149

Wat is de binaire representatie van deze velden?

[M4RTiN]

Ik kan alleen de laatste waarde nog ophalen, ik heb in dit stukje json nu een extra veld toegevoegd via een bin2hex functie. Ik weet niet zeker of dit de echte binaire waarde is trouwens, is bin2hex hiervoor bedoeld?

"957": {
"key": "unknown",
"value": 17,
"binary": "11"
},
"958": {
"key": "unknown",
"value": 43,
"binary": "2b"
},
"959": {
"key": "unknown",
"value": 4,
"binary": "04"
}

[ Voor 3% gewijzigd door M4RTiN op 03-07-2020 21:51 ]

[g0tanks]

M4RTiN schreef op vrijdag 3 juli 2020 @ 21:46:
Ik kan alleen de laatste waarde nog ophalen, ik heb in dit stukje json nu een extra veld toegevoegd via een bin2hex functie. Ik weet niet zeker of dit de echte binaire waarde is trouwens, is bin2hex hiervoor bedoeld?

"957": {
"key": "unknown",
"value": 17,
"binary": "11"
},
"958": {
"key": "unknown",
"value": 43,
"binary": "2b"
},
"959": {
"key": "unknown",
"value": 4,
"binary": "04"
}

Wat je nu binary noemt is eigenlijk de hexadecimale notatie van de waarde.

Wat voor machine (model) is het? Dan kunnen we gerichter zoeken en heeft iemand in de toekomst er ook wat aan mocht er een oplossing zijn.

Daarnaast zou ik om te beginnen eens kijken naar de waardes voor standen van 0, 1, 10, etc. Dat geeft waarschijnlijk meer inzicht dan willekeurige grote standen zoals 6914.

Is het trouwens niet zo dat die machine maar een maximale afstand kan meten die overeenkomt met 255?

[ Voor 22% gewijzigd door g0tanks op 03-07-2020 22:00 ]

[M4RTiN]

Ik merkte dat je binaire code niet in json kunt opslaan, ik heb nu een base_64 encoding gebruikt:

code:

    "954": {
        "key": "unknown",
        "value": 20,
        "binary": "FA=="
    },
    "955": {
        "key": "unknown",
        "value": 7,
        "binary": "Bw=="
    },
    "956": {
        "key": "unknown",
        "value": 3,
        "binary": "Aw=="
    },

Het is een japanse printer (Mimaki)

Het is niet zo makkelijk om zomaar een veld van een 1 of een 0 te pakken, ik weet van de meeste velden niet wat ze betekenen.

Het is een meterstand van een machine, die moeten wel tot 100.000 meters kunnen maken.

Verder merkten we dit op, dus misschien zijn niet alle drie velden direct betrokken met het getal die wij op het scherm zien.

code:

6914 / 256 = 27, dus <veld 1> + <veld 2> * 256 = uitkomst

Maar dit lijkt ook niet op te gaan voor die andere meterstand.

[ Voor 17% gewijzigd door M4RTiN op 03-07-2020 22:16 ]

[g0tanks]

M4RTiN schreef op vrijdag 3 juli 2020 @ 22:12:
Ik merkte dat je binaire code niet in json kunt opslaan, ik heb nu een base_64 encoding gebruikt:

code:

    "954": {
        "key": "unknown",
        "value": 20,
        "binary": "FA=="
    },
    "955": {
        "key": "unknown",
        "value": 7,
        "binary": "Bw=="
    },
    "956": {
        "key": "unknown",
        "value": 3,
        "binary": "Aw=="
    },

Het is een japanse printer (Mimaki)

Het is niet zo makkelijk om zomaar een veld van een 1 of een 0 te pakken, ik weet van de meeste velden niet wat ze betekenen.

Het is een meterstand van een machine, die moeten wel tot 100.000 meters kunnen maken.

Het is dus een apparaat dat hier op lijkt?


Wat stelt de 'vierkante meter stand' voor? Slaat het op het oppervlak aan papier dat er doorheen is gegaan ofzo? Met andere woorden, hoe verander jij de waarde van 6914 naar 6149?

[M4RTiN]

Dat klopt, wanneer wij een afdruk maken verandert dit de vierkante meterstand en de lengte meter stand.

[Josk79]

Die base64 heb je niet zoveel aan. Hoe lang is de volledige tcp message? Zou je de volledige string als hex kunnen pasten (e.g. 0E 37 26 ... )?

Heb je meer samples met meer waardes om te vegelijken?

[M4RTiN]

Het is nogal veel data, en heb op dit moment niet veel bruikbare data wat betreft verschillende meterstanden. Misschien moet ik inderdaad maar meer productie draaien en geeft dit een beter beeld hoe de getallen veranderen.

Wat ik wel zeker weet is dat wanneer de vierkante meter stand wijzigt en / of de lengte meter stand, dat precies die drie velden veranderen. Er zijn dus in totaal 6 velden die hiermee te maken heeft.

[Josk79]

Zit er niet toevallig nog een byte voor of achter die van belang kan zijn? Zou je bijv. een stuk van 20 bytes kunnen plakken met daarin de 3 wijzigende bytes?

[g0tanks]

M4RTiN schreef op vrijdag 3 juli 2020 @ 21:04:
Wanneer de vierkante meter stand 6914 is, geeft de data de volgende 3 waardes: 20, 7 en 3. Het lijkt een beetje op dat de volgende berekening klopt: (20*256)+(7*256)+3 = 6915. Je zou nog kunnen denken dat er misschien een afronding verschil is.

Maar bij de lengte meters gaat die berekening totaal niet op. Ik heb 2 verschillende waardes:

14/55/38 staat gelijk aan 6148
17/43/4 staat gelijk aan 6149

Begrijp ik het trouwens goed dat 6914 het oppervlak (vierkante meters) betreft en 6148 en 6149 de lengte? Dan is het toch logisch dat die formule niet opgaat als je naar een totaal andere fysische grootheid gaat kijken? Wat voor oppervlak hoort bij de waardes 14/55/38 en 17/43/4?

[Josk79]

Het kan natuurlijk zijn dat de printer andere units gebruikt, e.g. inch of points of whatever.

[M4RTiN]

Dat klopt g0tanks;

14/55/38 staat gelijk aan 6148 (lengtemeters)
17/43/4 staat gelijk aan 6149 (lengtemeters)

20/7/3 staat gelijk aan 6914 (vierkante meters)
en de berekening lijkt te zijn: 20+7 = 27*256 = 6914 (maar eigenlijk is het 27,0078125, want anders kom je op 6912 uit)

[M4RTiN]

Josk79 schreef op vrijdag 3 juli 2020 @ 22:24:
Het kan natuurlijk zijn dat de printer andere units gebruikt, e.g. inch of points of whatever.

Klopt, daar moeten we zeker rekening mee houden. Het is in elk geval een Japans merk, daar gebruiken ze wel het metrische stelsel. Maar in de grafische wereld (PDF standaard) wordt ook vaak Pt gebruikt.

[Josk79]

(20+7)*256 is geen logische manier om data op te slaan.

[Creepy]

Ik heb toch het idee dat dit toeval is. Want die 20 en 7 bij elkaar optellen en dan pas met 256 vermenigvuldigen lijkt niet heel logisch. De waardes die je zegt te krijgen zijn in elk geval al verbouwd. Kan je de ruwe TCP stream eens posten? Want dan hebben we echt beter inzicht.

[M4RTiN]

Creepy schreef op vrijdag 3 juli 2020 @ 22:32:
Ik heb toch het idee dat dit toeval is. Want die 20 en 7 bij elkaar optellen en dan pas met 256 vermenigvuldigen lijkt niet heel logisch. De waardes die je zegt te krijgen zijn in elk geval al verbouwd. Kkan je de ruwe TCP stream eens posten? Want dan hebben we echt beter inzicht.

Zeker ga ik proberen, hoe kan ik dit met PHP het beste doen? Ik heb niet veel ervaring met binaire data. Toch omzetten naar een hex string?

[Creepy]

Niks omzetten. Dump dat eens direct in een file (geen text file!) en open dan die file eens met een hex viewer oid (geen text editor dus). Wat zie je dan?

[Josk79]

Zoiets:

code:

$bytes = [ 0x12, 0x13, 0x14 ];
// Of als je een string hebt, gebruik: $bytes = unpack('C*', $de_message_string);

foreach($bytes as $byte) {
    echo substr("0" . dechex($byte), -2) . ' ';
}

[M4RTiN]

Creepy schreef op vrijdag 3 juli 2020 @ 22:37:
Niks omzetten. Dump dat eens direct in een file (geen text file!) en open dan die file eens met een hex viewer oid (geen text editor dus). Wat zie je dan?

Ah gelukkig stond de machine nog aan, en verdorie als ik dat bestand in een hexviewer open zie ik direct de naam van de printer en serienummer gewoon leesbaar. Er is dus direct wat meer data duidelijk!

[Josk79]

...ehm dit had een goede eerste stap geweest.

[M4RTiN]

Josk79 schreef op vrijdag 3 juli 2020 @ 22:43:
...ehm dit had een goede eerste stap geweest.

Inderdaad, geeft aan dat ik geen integere waardes hoef te verwachten waar ik nu leesbare tekst zie.

Stukje vanuit de hexviewer waar het om gaat

code:

00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 4d 47 4c 2d 49 49 63 32 31 2e 38 30
06 06 02 02 02 02 02 02 00 00 00 00 00 00 00 00
00 00 00 01 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 14 07 03 11 2b 04
00 01 39 01 00 09 00 00 54 34 34 41 42 30 36 37
00 00 00 00 00 00 00 00 05 a2 00 3c 00 90 00 73
00 90 00 90 00 00 00 00 00 00 00 00 01 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

en dan gaat het om dit stukje

code:

14 07 03 11 2b 04

En dat zou het zo moeten zijn

code:

14 07 03 = 6914
11 2b 04 = 6149

[ Voor 3% gewijzigd door M4RTiN op 03-07-2020 22:58 ]

[emnich]

Waarom ben je er zo zeker van dat het dit stuk is? Is er verder niets veranderd in het hele bestand?

[Josk79]

... en van 6418?

[M4RTiN]

emnich schreef op vrijdag 3 juli 2020 @ 22:58:
Waarom ben je er zo zeker van dat het dit stuk is? Is er verder niets veranderd in het hele bestand?

Klopt, ik heb continue met winmerge de data vergeleken, van alle waardes die er waren waren dit de enige velden waar een verschil in zat. ik heb direct files gemaakt voor en na een afdruk.

[M4RTiN]

Josk79 schreef op vrijdag 3 juli 2020 @ 22:58:
... en van 6418?

Op dit precies moment kan ik alleen van de huidige staat van de machine een dump opslaan helaas.

[Josk79]

ok, maar als ik bovenstaande lees zouden alleen die 3 bytes veranderen.

[M4RTiN]

Josk79 schreef op vrijdag 3 juli 2020 @ 23:01:
ok, maar als ik bovenstaande lees zouden alleen die 3 bytes veranderen.

Klopt, dit is een screenshot van vanmiddag, let op de drie gele regels en de bestandsnaam waar ik de meterstanden heb genoteerd:

https://pasteboard.co/JfZwayQ.png

[emnich]

Wat is die lengte 6149, is dat meter, cm, mm?
Is het niet raar dat de lengte wel wijzigt maar de oppervlakte niet?

En ik zie bovenin ook nog twee wijzigingen?

[ Voor 27% gewijzigd door emnich op 03-07-2020 23:09 ]

[M4RTiN]

Lengte is in meters en het verschil die je daarboven ziet is de heatertemperatuur (3 verschillende waardes) of het verschil in resterende inkt-niveau. Dat waren overigens hele makkelijke waardes.

[g0tanks]

Tja twee waardes om te vergelijken is niet veel. Ik zou proberen er nog een stuk of tien te achterhalen. Daarnaast blijf ik erbij dat het makkelijker is om bij 0 te beginnen. Kan je niet de stand resetten?

[Josk79]

Ook interessant: kun je waarden achter de komma meegeven, e.g. 6148,5 ?

[M4RTiN]

g0tanks schreef op vrijdag 3 juli 2020 @ 23:16:
Tja twee waardes om te vergelijken is niet veel. Ik zou proberen er nog een stuk of tien te achterhalen. Daarnaast blijf ik erbij dat het makkelijker is om bij 0 te beginnen. Kan je niet de stand resetten?

Mee eens, ik dacht eerst dat ik hier uit zou komen met wat rekensommetjes maar kennelijk heb ik meer data nodig om een patroon te herkennen.

Het is geen resetable counter, vergelijk het met de kilometerteller van je auto.

[Josk79]

Heb je ergens anders wel meters gezien in de data?

[M4RTiN]

Josk79 schreef op vrijdag 3 juli 2020 @ 23:17:
Ook interessant: kun je waarden achter de komma meegeven, e.g. 6148,5 ?

Het bedieningspaneel laat dit niet zien maar ik durf te wedden dat het systeem wel data achter de komma bewaard. Als wij printen kunnen wij natuurlijk ook hele kleine formaten printen, dus het systeem moet wel in een eenheid meten die kleiner is dan een meter. Terwijl ik dit type bedenk ik me dat ik van hetzelfde merk wel een developers PDF'je heb van een andere machine. Daar hebben ze het over 1 mm nauwkeurigheid. Dus omdat we die drie velden hebben zal dat er wel mee te maken hebben.

[M4RTiN]

Josk79 schreef op vrijdag 3 juli 2020 @ 23:28:
Heb je ergens anders wel meters gezien in de data?

Voor zover mij bekend is er verder geen enkele waarde wat in meters zou kunnen worden uitgedrukt op deze machine.

[Freeaqingme]

M4RTiN schreef op vrijdag 3 juli 2020 @ 22:55:
[...]


en dan gaat het om dit stukje

code:

14 07 03 11 2b 04

En dat zou het zo moeten zijn

code:

14 07 03 = 6914
11 2b 04 = 6149

Ik denk dat die 11 2b 04 niets is. Binair is dat: 0001000100101011 0000010000000000

Gooi ik dat hier in dan krijg je 67113259 als je het decode naar 'mid-little endian'. Deel je dat door 1024, dan kom je uit op 65540, wat toevallig bijna gelijk aan 2^16 is. Wellicht dat het wel wat is, maar frapant is het wel.

[M4RTiN]

Freeaqingme schreef op vrijdag 3 juli 2020 @ 23:35:
[...]


Ik denk dat die 11 2b 04 niets is. Binair is dat: 0001000100101011 0000010000000000

Gooi ik dat hier in dan krijg je 67113259 als je het decode naar 'mid-little endian'. Deel je dat door 1024, dan kom je uit op 65540, wat toevallig bijna gelijk aan 2^16 is. Wellicht dat het wel wat is, maar frapant is het wel.

Het zal toch *iets* zijn denk ik, er zal hoe dan ook meer data moeten komen willen we er iets van kunnen zeggen begrijp ik. Het kan allemaal toeval zijn maar het verandert wel na het printen.

Edit:

Zat nog even in excel te pielen, dit vond ik wel een leuke:

(20+7+((3*256)/10000))*256=6914

(dan is dat laatste veld dus inderdaad bedoeld voor achter komma.)

[ Voor 10% gewijzigd door M4RTiN op 04-07-2020 00:09 ]

[Josk79]

Dit is toeval, volgens mij. 20 en 7 bij elkaar optellen is onlogisch.

[Josk79]

is die m2 waarde ook iets wat doortelt na iedere print, net als de meters?

[M4RTiN]

Ik ga misschien morgen wel even wat simpele banen printen en meer data verzamelen, bijvoorbeeld een rechthoek vierkante meter en een smalle strook van een meter. Kijken wat er gebeurt.

Dat hierboven zal inderdaad toeval zijn, want de berekening klopt niet bij de andere getallen.

[g0tanks]

M4RTiN schreef op vrijdag 3 juli 2020 @ 23:42:
(20+7+((3*256)/10000))*256=6914

Uit die formule komt geen 6914 rollen hoor.

[M4RTiN]

(20+7+((3*256)/100000))*256=6913,96608

Was een 0 vergeten

[KabouterSuper]

Als je kijkt naar de lengtemeters, dan ga je van 6148 naar 6149. Dat betekent afgerond 1 meter erbij.
Je bijbehorende stand gaat van 14/55/38 naar 17/43/4. De eerste van deze waarden gaat omhoog (met 3), maar de tweede en derde omlaag. De getallen zijn ook vrij groot maar kleiner dan 256.
Als ik moet gokken dan is het een representatie in een 256-getallenstelsel (maar 64 zou ook kunnen, al is dat erg ongebruikelijk).
Het verschil tussen 14/55/38 en 17/43/4 is in het 256-getallenstelsel gelijk aan 2/243/222. Dit moet een getal in de buurt van 1 voorstellen qua meters. Met wat knutselwerk zie ik dat 2/256+243/256^2+222/245^3 gelijk is aan 0.011543 ofwel ongeveer 1/100.
Kortom, ik denk dat de formule het volgende is:
6148=afgeronde versie van [100*(waarde die nog niet is veranderd + 14/256+55/256^2+38/256^3)]
6149=afgeronde versie van [100*(waarde die nog niet is veranderd + 17/256+43/256^2+3/256^3)]

Ik denk ook dat de formule voor vierkante meters praktisch hetzelfde is. Mijn vraag is of we de waarde die nog niet veranderd is kunnen terugvinden. Die waarde is overigens 6142=23*256+254, dus 0/23/254.
Ik denk dus dat je binnen een paar honderd meter andere bits ziet veranderen. Update: vergeten door honderd te delen.

Zijgedachte: weet je zeker dat dit de meters zijn en niet de vierkante meters? Zou het ook andersom kunnen zijn?

[M4RTiN]

Ik ga zometeen even naar de machine toe en ga ik weer standen noteren en data loggen. Ik hou het dan even puur bij feiten en geen aannames wat wat is. Puur de data die wijzigt zet ik hier neer. Ik kan natuurlijk een fout hebben gemaakt met mijn schatting welke waarde bij welke data hoort. :-)

[Jerrythafast]

Oké, dit hangt natuurlijk helemaal aan elkaar met aannames, maar stel nou dat het één van deze printers is:
https://mimaki.com/produc...series/specification.html

Uit de HEX dump blijkt dat we met "MGL-IIc" te maken hebben (4D 47 4C 2D 49 49 63). De commandoresolutie is dus 25 µm of 10 µm, oftewel het is 0.025 of 0.01 mm. De mechanische resolutie in de lengterichting is 5 µm (0.005 mm)

In de HEX dump zijn geen 32-bit IEEE-754 floats te herkennen. Vermoedelijk zitten we dus naar integers te kijken met bovengenoemde resolutie.

De specificaties geven een idee van de schaal: de breedte is ongeveer een meter, de lengte tot zo'n 51 meter. De door @M4RTiN genoemde lengtes (6148 m, 6149 m) en oppervlakte (6419 m²) zijn waarschijnlijk afgerond - de werkelijke breedte kan zodoende liggen tussen de 1124.23 en 1124.77 mm. Het lengteverschil is maximaal 2000.00 mm.

Laten we om te beginnen eens kijken naar de drie bytes die veranderden. Stel dat deze de lengte voorstellen. Dan moet het verschil in deze waardes dus een lengte van maximaal 2000.00 mm voorstellen.
0x0E3726 = 931622
0x112B04 = 1125124
Het verschil hiertussen is 193502. Dat zou 1935.02 mm kunnen betekenen. Maar in dat geval betekenen deze waardes dus 9316.22 mm en 11251.24 mm. Let wel: die komma kan ook één of meerdere posities naar links liggen, we weten immers niet hoeveel lengte @M4RTiN exact heeft geprint tussenbeide - alleen dat het niet meer is dan 2 meter.

Het is in mijn ervaring niet waarschijnlijk dat er een waarde van drie bytes wordt gerapporteerd, normaliter zou dit een 32-bit en dus 4-byte integer zijn. In dat geval hoort de 03 byte ernaast hier ook nog bij. De getallen worden dan als volgt:
0x030E3726 = 51263270
0x03112B04 = 51456772
Het verschil is natuurlijk nog steeds 193502. Maar die 51 triggert mij wel, omdat dat een getal is dat ook in de specificaties terugkwam. Betekent dit soms 51.263270 en 51.456772 meter? Dan is er dus 0.193502 meter oftewel 193.502 mm geprint tussen beide dumps.

Need more info

[ Voor 0% gewijzigd door Jerrythafast op 04-07-2020 11:25 . Reden: 3 ipv 4 ]

[KabouterSuper]

Jerrythafast schreef op zaterdag 4 juli 2020 @ 11:11:
Oké, dit hangt natuurlijk helemaal aan elkaar met aannames, maar stel nou dat het één van deze printers is:
https://mimaki.com/produc...series/specification.html

Uit de HEX dump blijkt dat we met "MGL-IIc" te maken hebben (4D 47 4C 2D 49 49 63). De commandoresolutie is dus 25 µm of 10 µm, oftewel het is 0.025 of 0.01 mm. De mechanische resolutie in de lengterichting is 5 µm (0.005 mm)

In de HEX dump zijn geen 32-bit IEEE-754 floats te herkennen. Vermoedelijk zitten we dus naar integers te kijken met bovengenoemde resolutie.

De specificaties geven een idee van de schaal: de breedte is ongeveer een meter, de lengte tot zo'n 51 meter. De door @M4RTiN genoemde lengtes (6148m, 6149m) en oppervlakte (6419m²) zijn waarschijnlijk afgerond - de werkelijke breedte kan zodoende liggen tussen de 1124.23 en 1124.77 mm. Het lengteverschil is maximaal 2000.00 mm.

Laten we om te beginnen eens kijken naar de drie bytes die veranderden. Stel dat deze de lengte voorstellen. Dan moet het verschil in deze waardes dus een lengte van maximaal 2000.00 mm voorstellen.
0x0E3726 = 931622
0x112B04 = 1125124
Het verschil hiertussen is 193502. Dat zou 1935.02 mm kunnen betekenen. Maar in dat geval betekenen deze waardes dus 9316.22 mm en 11251.24 mm. Let wel: die komma kan ook één of meerdere posities naar links liggen, we weten immers niet hoeveel lengte @M4RTiN exact heeft geprint tussenbeide - alleen dat het niet meer is dan 2 meter.

Het is in mijn ervaring niet waarschijnlijk dat er een waarde van drie bytes wordt gerapporteerd, normaliter zou dit een 32-bit en dus 4-byte integer zijn. In dat geval hoort de 04 byte ernaast hier ook nog bij. De getallen worden dan als volgt:
0x040E3726 = 51263270
0x04112B04 = 51456772
Het verschil is natuurlijk nog steeds 193502. Maar die 51 triggert mij wel, omdat dat een getal is dat ook in de specificaties terugkwam. Betekent dit soms 51.263270 en 51.456772 meter? Dan is er dus 0.193502 meter oftewel 193.502 mm geprint tussen beide dumps.

Need more info

Die 25 µm is interessant. In mijn formule moet ik vermenigvuldigen met 100 wat niet logisch is. Maar als je alles omrekent met een eenheid van 25 µm, dan kom je wellicht op een mooiere factor uit. Immers, 256/1024*100=25, waarmee de vreemde factor 100 verdwijnt.

[Jerrythafast]

KabouterSuper schreef op zaterdag 4 juli 2020 @ 11:16:
[...]

Die 25 µm is interessant. In mijn formule moet ik vermenigvuldigen met 100 wat niet logisch is. Maar als je alles omrekent met een eenheid van 25 µm, dan kom je wellicht op een mooiere factor uit. Immers, 256/1024*100=25, waarmee de vreemde factor 100 verdwijnt.

Inderdaad! De "waarde die nog niet is veranderd" in jouw formule zou mijns inziens 3 moeten zijn.

[ Voor 0% gewijzigd door Jerrythafast op 04-07-2020 11:25 . Reden: 3 ipv 4 ]

[M4RTiN]

code:

LM           M2           954  955  956  957  958  959      
6149    6914    20  7   3   17  43  4       beginstand
6150    6915    20  7   4   10  46  42      1 M2 geprint
6151    6917    20  7   4   10  50  49      1 meter strook van 1 cm breed
6151    6917    20  7   4   10  52  55      0.25x0.25 vierkant geprint
6151    6917    20  7   4   11  11  12      1m breed 1 cm hoog
6151    6918    20  7   4   11  14  4       0.5x0.5 geprint
6152    6919    20  7   4   11  17  4       1 cm breed x 1 meter hoog
6153    6920    20  7   4   11  22  14      1 m2 geprint
6154    6922    20  7   4   11  26  38      1 m2 geprint

Zoals ik er nu naar kijk kan het wel eens zo zijn dat alle velden bij elkaar horen, dus niet 2 getallen, maar 1 tellerstand. Elke keer als 1 getal zijn max heeft bereikt, gaat de volgende weer 1 omhoog.

Heb eventueel binaire dumpfiles beschikbaar.

[ Voor 5% gewijzigd door M4RTiN op 04-07-2020 11:36 ]

[Jerrythafast]

M4RTiN schreef op zaterdag 4 juli 2020 @ 11:29:

code:

LM           M2           954  955  956  957  958  959      
6149    6914    20  7   3   17  43  4       beginstand
6150    6915    20  7   4   10  46  42      1 M2 geprint
6151    6917    20  7   4   10  50  49      1 meter strook van 1 cm breed
6151    6917    20  7   4   10  52  55      0.25x0.25 vierkant geprint
6151    6917    20  7   4   11  11  12      1m breed 1 cm hoog
6151    6918    20  7   4   11  14  4       0.5x0.5 geprint
6152    6919    20  7   4   11  17  4       1 cm breed x 1 meter hoog
6153    6920    20  7   4   11  22  14      1 m2 geprint
6154    6922    20  7   4   11  26  38      1 m2 geprint

Zoals ik er nu naar kijk kan het wel eens zo zijn dat alle velden bij elkaar horen, dus niet 2 getallen, maar 1 tellerstand. Elke keer als 1 getal zijn max heeft bereikt, gaat de volgende weer 1 omhoog.

Dat is inderdaad hoe computers werken. Je hebt bytes die 0-255 als waarde kunnen aannemen (00 - FF in hexadecimale notatie) en meerdere bytes samen vormen een groter getal. Lees je even in in 32-bit integers

[Jerrythafast]

De waardes in jouw tabel:

code:

03 17 43 04 = 51856132
04 10 46 42 = 68175426 ([phone] x 1000 mm geprint
04 10 50 49 = 68177993 ([phone] x 10 mm (lengte maal breedte)
04 10 52 55 = 68178517 (+524) 250 x 250 mm
04 11 11 12 = 68227346 (+48829) 10 x 1000 mm
04 11 14 04 = 68228100 (+754) 500 x 500 mm
04 11 17 04 = 68228868 (+768) 1000 x 10 mm
04 11 22 14 = 68231700 ([phone] x 1000 mm
04 11 26 38 = 68232760 ([phone] x 1000 mm

Die tweede byte is wel een speciale, misschien dat hij van 03 17 xx xx naar 04 10 xx xx springt ipv 03 18 xx xx.
Ik denk daarom nu toch niet meer dat het één 32-bit integer is.

[ Voor 16% gewijzigd door Jerrythafast op 04-07-2020 11:48 ]

[M4RTiN]

Ik las je antwoord verkeerd, ik dacht dat je het met die berekening al had uitgevonden

[ Voor 74% gewijzigd door M4RTiN op 04-07-2020 11:54 ]

[user109731]

Zijn die waardes niet gewoon de datum/tijd van verandering?

code:

20  7   3   17  43   4 => 3 juli 2020, 17:43:04
20  7   4   10  46  42 => 4 juli 2020, 10:46:42  => TS experimenteert vandaag
...

[M4RTiN]

Shit je hebt helaas gelijk. Gevalletje wishfull thinking ben ik bang. Verklaart direct waarom de getallen versprongen rond de 60.

[Illusion]

Wel raar dat er nooit een een getal hoger dan 63 staat. Terwijl de max (FF=) 255 zou moeten zijn. Hoe groot is die kans als het een normale uint32 zou zijn.

[Jerrythafast]

user109731 schreef op zaterdag 4 juli 2020 @ 12:35:
Zijn die waardes niet gewoon de datum/tijd van verandering?

code:

20  7   3   17  43   4 => 3 juli 2020, 17:43:04
20  7   4   10  46  42 => 4 juli 2020, 10:46:42  => TS experimenteert vandaag
...

I can see it so clearly now

Maar als dit het enige is dat veranderde, dan staat de gewenste data er dus niet tussen... "gewoon" verbinden met TCP is dus niet genoeg, vervolgens zal er vermoedelijk ook nog wat bidirectionele communicatie moeten plaatsvinden dan?

[ Voor 24% gewijzigd door Jerrythafast op 04-07-2020 13:33 ]

[M4RTiN]

Ik ben bang dat er geen bidirectionele communicatie mogelijk is, er is in elk geval geen documentatie. Dus wat ik wil zal voorlopig nog steeds niet mogelijk zijn. Sorry voor de wild goose chase jongens.

[Illusion]

M4RTiN schreef op zaterdag 4 juli 2020 @ 13:43:
Ik ben bang dat er geen bidirectionele communicatie mogelijk is, er is in elk geval geen documentatie. Dus wat ik wil zal voorlopig nog steeds niet mogelijk zijn. Sorry voor de wild goose chase jongens.

Maar voorzover ik zie kan dat ding gewoon een statusmailtje sturen na elke printopdracht. Kan je daar niks mee?

[Reptile209]

Zit er ook geen eigen software van de fabrikant bij, die allerlei info uitleest? Dan zou je dat netwerkverkeer kunnen afluisteren en ontleden. Best kans idd dat je een bepaald commando moet sturen om de gewenste reactie (data) te krijgen.

[Jerrythafast]

Inderdaad, aangezien de software die je nu gebruikt deze cijfers heeft gaan ze over het kabeltje. De TCP-verbinding van die software kun je aftappen om daarin te kunnen grasduinen. Goede kans dat er dan wél allerlei leuke informatie voorbij komt Wordt wel een next level klus dan, maar is ook leuk om ervaring op te doen natuurlijk

[M4RTiN]

Illusion schreef op zaterdag 4 juli 2020 @ 14:16:
[...]

Maar voorzover ik zie kan dat ding gewoon een statusmailtje sturen na elke printopdracht. Kan je daar niks mee?

Helaas zijn dit hele simpele mailtjes, waarvan ik de status nu al beter kan verwerken via de binaire data van het TCP poort waar ik nu mee aan het experimenteren was.

Dat mail systeem is voor dit type ook de enige reden waarvoor de ethernet kabel officiëel ondersteund wordt. De echte data wordt verzonden via de USB kabel. De opvolger van deze machine kan wel volledig via ethernet aangestuurd worden.

Hooguit als ik monteurs software krijg zou ik misschien meterstanden via USB kunnen opvragen, maar ik denk niet dat ze dit mogen doen.

Wel heel tof dat jullie zo meedenken.

Uiteraard heb ik verder nog op open poorten gescanned zoals snmp, maar hij zit potdicht verder.

[PrisonerOfPain]

Houd er rekening mee dat een duizendste van een inch ongeveer 25.4 μm is, dus het zou goed kunnen dat je waarden niet metrisch zijn.

Misschien is het ook handig om te kijken naar de CPU en wat voor encodings daar gangbaar op zijn; normale fixed point representatives, bdc, IEEE floats etc.

[Matis]

Vroeger gebruikte ik vaak minicom om dit soort dingen te debuggen of te dumpen.

Misschien kun je met wireshark een keer een dump maken van het TCP verkeer en dat delen.