Expertos en Checksum,Crc,Etc.
 

Holaaaaa, ¿se puede pasar?

Gracias:)

Si es que solo me acuerdo de vosotros cuanto me encuentro "solo:("

Esta vez la cosa va de checksum, crc.
El caso es que tengo que implementar un protocolo de comunicaciones con unas máquinas viejecillas por el puerto serie, hasta aquí bien, el caso, es que al capturar el protocolo que usan me parece que no soy capaz de averiguar que tipo de crc o checksum están utilizando.
El protocolo se llama Indatal (industrial data link) por si a alguien le facilita las cosas.

Seguro que entre nosotros tenemos algún experto en estos temas.

Vamos al ejemplo de pedir directorio por parte de la maquina al ordenador (resumido)

maquina #144#130#0#1#58#49#144#3#245#239
ordenador #144#130#0#0#144#3#248#91
ordenador #144#130#1#5"45 "#0#0#0#0"COP "#0#0#0#11"COPY "#0#0#4#176"JON "#0#0#0#0"ORIGTP10"#0#0#3#252" "#9#107#4#0#144#3#150#213
maquina #144#130#2#6#144#3#248#83
ordenador #144#130#0#1#58#50#144#3#245#238
maquina #144#130#0#255#6#144#3#246#86

En la tercera línea que envía directorio y en 32bits su tamaño he escrito los nombres de fichero entre comillas para facilitar su lectura.
Parece claro que comienza las líneas con la secuencia #144#130 y las termina con #144#3 a lo que le añade un crc de 16 bits.
Con la funciones que uso habitualmente no lo consigo, y usando un programa para ver checksum, tampoco (archivo adjunto)

¿Se os ocurre como calcularlo?

Gracias por mirarlo y si le dedicais un rato a ayudarme os invito a unas||-||

PD: He puesto la imagen en pdf para que al abrir se vea grande el calculo sobre la cuarta línea que debería ser F8 53
PD2: Ahora que estoy aquí, leo algunos post p'aydar.;)

Por lo que entiendo de tu consulta, se envían mensajes cuyos últimos dos bytes corresponden a un crc de 16 bits.

En la cuarta línea:
En el PDF no he visto que estás calculando sobre ninguno de estos valores, por lo que no sé de dónde sacas que debería ser F8 53.
Además, parece que muestras los mensajes codificando los bytes en base decimal y el checksum en hexadecimal.

Fíjate si debes calcular sobre la parte útil o solo sobre la información, sin tener en cuenta la cabecera y la cola.

En el pdf se hace sobre toda la línea #144#130#2#6#144#3 pero en exa 90 82 02 06 90 03 y el crc16 da F6 A8 (#246#168) pero el checksum de la cuarta línea es #248 #83 (F8 53 en exa)
Ya he probado a excluir la cabecera #2#6#144#130 y no me da #248#83, solo datos #2#6 y no sale y datos + cola #144#3 y tampoco....por eso estamos aqui:confused:

A ver si va a ser la suma de todos en 16 bit....pues no suma 429 (0x1AD)
El valor decimal en 16 bit del crc seria (248*256)+83=63571 ¿sirve de algo? Todos los checksum tienen valores muy altos

Seguimos mirando ¿ok?

Uy,uy lo que he visto

el checksum da 429
y crc16 da 63144
si sumo los dos = 63573 en exa F8 55 (diferencia de 2 para F8 53 = 63571)

voy a seguir mirando por esa línea

PD: se aceptan mas sugerencias

nada, por ahí no van los tiros.

¿Alguna sugerencia?

Podría tratarse también de un check de paridad como explican aquí: https://en.wikipedia.org/wiki/Longit...dundancy_check
Ten en cuenta que parece que al ser dos bytes de paridad deberías trabajar con WORDs y si el último byte del mensaje queda sin su par para generar un word habrá que resolverlo agregándole otro (por delante o por detrás) con valor 0.

Hola de nuevo:D
Muchisimas gracias, ya te has ganado unas ||-|| el ultimo byte es LRC
Ya tenemos la mitad resuelta, ya solo falta la otra mitad, el byte anterior.

Pongo este código (por si lo quereis copiar) que incluye la función LRC en Delphi

Código Delphi [-]
procedure TPCVP.Button1Click(Sender: TObject);
var
  s: ansistring;
  // Longitudinal Redundancy Check
  function CalculaLRC(cadena: ansistring): word;
  var
    i: word;
  begin
    Result := 0;
    for i := 1 to Length(cadena) do
      Result := (Result + Ord(cadena[i])) and 255;
    Result := ((Result xor 255) + 1) and 255;
  end;
  // Longitudinal Redundancy Check
begin
  s := #144#130#0#1#58#49#144#3; //#245#239
  showmessage(IntToStr(CalculaLRC(s))); // = #239
  s := #144#130#0#0#144#3; //#248#91
  showmessage(IntToStr(CalculaLRC(s))); // = #91
  s := #144#130#2#6#144#3; //#248#83
  showmessage(IntToStr(CalculaLRC(s))); // = #83
  s := #144#130#0#1#58#50#144#3; //#245#238
  showmessage(IntToStr(CalculaLRC(s))); // = #238
  s := #144#130#0#255#6#144#3; //#246#86
  showmessage(IntToStr(CalculaLRC(s))); // = #86
  s := #144#130#1#5 +
       '45      ' + #0#0#0#0 +
       'COP     ' + #0#0#0#11 +
       'COPY    ' + #0#0#4#176 +
       'JON     ' + #0#0#0#0 +
       'ORIGTP10' + #0#0#0#0 +
       'TALATP10' + #0#0#3#252 +
       '        ' + #9#107#4#0 +
       #144#3; //#150#213
  showmessage(IntToStr(CalculaLRC(s))); // = #213
  s := #144#130#1#5 +
       '[**********PUNTA********' + #13#10 +
       'N1[ Pro/TOOLMAKER v9.0.030 ]' + #13#10 +
       'N2[ lunes, 31 de marzo de 2014 20:41:15 ]' + #13#10 +
       'N3[ V:\266\266ma01p.pun ]' + #13#10 +
       'N4[ Z:\08266\200\08266A_2002_P200_MACHO_1.dca ]' + #13#10 +
       'N5[ Eduardo Gutierrez ]' + #13#10 +
       'N6[ Trayectoria de herramienta sobre plano' +
       #144#3; //#195#140
  showmessage(IntToStr(Length(s) - 6) + ' ' + IntToStr(CalculaLRC(s))); // = #140
  s := #144#130#2#5 +
       ' de corte en Z 2 [35x6, 0.5] ]' + #13#10 +
       'N7[ Trayectoria de herramienta sobre plano de corte en Z ]' + #13#10 +
       'N8[ Thickness in XY is: 0.500 ]' + #13#10 +
       'N9[ Thickness in Z is: 0.500 ]' + #13#10 +
       'N10[ Cutter: 35.000x6.000 ]' + #13#10 +
       'N11[ Note: Cutter tip output ]' + #13#10 +
       'N12[ WARNING: Feedrate c' +
       #144#3; //#190#64
  showmessage(IntToStr(Length(s) - 6) + ' ' + IntToStr(CalculaLRC(s))); // = #64
  s := #144#130#3#5 +
       'ontrol cannot be used with Override Standard Feedrates - feedrate control disabled. ]' + #13#10 +
       'N13F P1' + #13#10 +
       'N14G0Z166.000' + #13#10 +
       'N15G0X308.605Y-103.414' + #13#10 +
       'N16G1Z144.827' + #13#10 +
       'N17F P2' + #13#10 +
       'N18X308.615Y-103.375Z144.430' + #13#10 +
       'N19X308.643Y-103.261Z144.050' + #13#10 +
       'N20X308.688Y-103.076Z14' +
       #144#3; //#199#137
  showmessage(IntToStr(Length(s) - 6) + ' ' + IntToStr(CalculaLRC(s))); // = #137
  s := #144#130#4#5 +
       '3.700' + #13#10 +
       'N21X308.749Y-102.827Z143.395' + #13#10 +
       'N22X308.823Y-102.525Z143.146' + #13#10 +
       'N23X308.907Y-102.181Z142.965' + #13#10 +
       'N24X308.998Y-101.808Z142.857' + #13#10 +
       'N25X309.178Y-100.910Z142.695' + #13#10 +
       'N26X309.283Y-100.000Z142.534' + #13#10 +
       'N27X309.310Y-99.085Z142.372' + #13#10 +
       'N28X309.261Y-98.170Z142.21' +
       #144#3; //#212#122
  showmessage(IntToStr(Length(s) - 6) + ' ' + IntToStr(CalculaLRC(s))); // = #122
end;

Lo único que no son 2 bytes, así que con un byte es suficiente.

También en visto que el programa se manda en cadenas de 242 bytes + los 4 de cabecera y cola y su secuencia #1#5#2#5#3#5...#256#5
entonces...¿Sera el byte anterior al LRC algún tipo de secuencia? Son valores muy parecidos en comandos, no asi en el programa o directorios (Datos)

Comandos
s := #144#130#0#1#58#49#144#3#245#239; // MAQUINA -> pedir directorio
s := #144#130#0#0#144#3#248#91; // ORDENADOR -> orden recibida
s := #144#130#2#6#144#3#248#83; // ORDENADOR -> fin de directorio
s := #144#130#0#1#58#50#144#3#245#238; // MAQUINA -> directorio recibido
s := #144#130#0#255#6#144#3#246#86; // ORDENDOR -> fin de comunicación

Datos
Directorio
s := #144#130#1#5 +
'45 ' + #0#0#0#0 +
'COP ' + #0#0#0#11 +
'COPY ' + #0#0#4#176 +
'JON ' + #0#0#0#0 +
'ORIGTP10' + #0#0#0#0 +
'TALATP10' + #0#0#3#252 +
' ' + #9#107#4#0 +
#144#3#150#213;
Programa
s := #144#130#1#5 + ( 242 bytes) +#144#3#195#140
s := #144#130#2#5 + ( 242 bytes) +#144#3#190#64
s := #144#130#3#5 + ( 242 bytes) +#144#3#199#137
s := #144#130#4#5 + ( 242 bytes) +#144#3#212#122

¿O será otro tipo de control?

Seguimos mirando