Уважаемые, помогите разобраться, есть устройство с протоколом, описание расчета чексуммы такое

The data checksum is the 2s-complement value of the modulo-256 sum of all the bytes in
the message.The following example shows the data sent to the printer to populate a specific
remote field in a message using the command 1D. Assumes that the slave address is “00”.
1B 02 00 1D 01 01 0B 54 49 4A 20 50 72 69 6E 74 65 72 1B 03
Step 1
1B(ESC)
02(STX)
00
1D
01
01
0B
54
49
4A
20
50
72
69
6E
74
65
72
1B(ESC)
03(ETX)
______
Total value 450hex
Step 2
The Bitwise AND operation (modulo-256) is applied to the total value and 0FFh to give a
single byte value:
450h AND 0FFh = 50h
Step 3
The 2s-complement of 50h is then calculated as follows:
100h - 50h = B0h
Therefore the checksum for the above message is B0h.Add it to the end of the command.

1. сумма всех байтов команды = СуммаБайт
2. ПобитовоеИ(СуммаБайт, FF)
3. И дополнение (2's complement)

Как посчитать 3 и верно ли остальное?

конечно был  бы признателен за подробное объяснение, что бы можно было на бумаге посчитать
или укажите на ошибку
с суммой байт проблем нет, побитовоеИ тоже понимаю, в 8.3 она даже есть, а для ДвоичногоДополнения использовал калькулятор https://www.planetimming.com/checksum8.html

В мануале есть два примера с рассчитанной суммой, все сходится с тем как я делаю (получаю такую же сумму для этих примеров), оборудование принимает посылку, все ок. Но если меняю хотя бы один символ в сообщении, то уже отлуп от оборудования

вот пример корректного сообщения
1B 02 00 1D 02 01 0B 54 49 4A 20 50 72 69 6E 74 65 72 03 0A 30 34 2F 32 37 2F 32 30 31 39 1B 03 AB
Сумма: AB
Считаем калькулятором
Сумма байт = 1B + 02 + 00 + 1D + ... = 655 hex
Там же на калькуляторе(!, не самостоятельно) жмем And (виндовый калькулятор, вид программист) и вводим FF, получаем 55h
Идем в калькулятор по ссылке https://www.planetimming.com/checksum8.html, ставим там 55 и получаем AB, все всходится

теперь здесь, это передаваемый текст (все до - служебное) 54 49 4A 20 50 72 69 6E 74 65 65 меняем просто букву, считаем так же как и раньше, на выходе получаем B8, но есть это девайс отказывается, что не так, пжлст?

54 49 4A 20 50 72 69 6E 74 65

Его сумма будет 0x379

sum(54 49 4A 20 50 72 69 6E 74 65)=379h
379h and FFh = 79h
100h-79h=87h

(4) да, по бумаге я начитал, что сумма должна быть от всего сообщения и прибавлена в конец этого сообщения

1B 02 00 1D 02 01 0B 54 49 4A 20 50 72 69 6E 74 65 72 03 0A 30 34 2F 32 37 2F 32 30 31 39 1B 03 AB

(6) И? Вы плохо формулируете проблему.
Покажите полностью сообщение, без контрольной суммы, которое отправляете. И мы вычислим контрольную и сравним с вашей.

(5) 100h - это константа в этом "методе" преобразования? просто не понимаю смысла этой операции 2's comp, а со временем как всегда плохо

(7) это начальная команда
1B 02 00 1D 02 01 0B 54 49 4A 20 50 72 69 6E 74 65 72 03 0A 30 34 2F 32 37 2F 32 30 31 39 1B 03
для нее надо рассчитать сумму, в этом примере она AB, то есть отправлять надо
1B 02 00 1D 02 01 0B 54 49 4A 20 50 72 69 6E 74 65 72 03 0A 30 34 2F 32 37 2F 32 30 31 39 1B 03 AB

(8) 100h=256d  - это позволяет вычислить сколько не хватает до полного 1-х байтного значения..

(8) а, стоп
ну нет, все верно, калькулятор по ссылке так же считает

в (9) пример из документа, у меня получается такая же контрольная сумма, все ок
но отправлять мне надо разный текст, который в этом примере закодирован с 8го до 18го байта (с 21го 10 байт тоже текст), тут не получится один раз высчитать и все время отправлять, текст меняется от отправки к отправке
поэтому хотелось бы понимать как
(10) понял, можно использовать всегда 100h - полученное на шаге 2

(12) Пример полного сообщения для измененного текста напиши

полное из учебника, AB - сумма, девайс ест
1B 02 00 1D 02 01 0B 54 49 4A 20 50 72 69 6E 74 65 72 03 0A 30 34 2F 32 37 2F 32 30 31 39 1B 03 AB

1B 02 00 1D 02 01 0B 54 49 4A 20 50 72 69 6E 74 65 65 03 0A 30 34 2F 32 37 2F 32 30 31 39 1B 03 B8
меняем один символ 72(последняя "r", в слове Printer по ASCII) на 65 (буква "e" по ASCII, должно получиться Printee), B8 - сумма мной полученная, девайс сообщение не ест

sum(1B 02 00 1D 02 01 0B 54 49 4A 20 50 72 69 6E 74 65 65 03 0A 30 34 2F 32 37 2F 32 30 31 39 1B 03)=648h
648h and FFh = 48h
100h-48h = B8

Вроде верно.

(15) млааа, плохо, но все равно спасибо. на что думать теперь не понятно

Че хоть за устройство, задача.

(17) каплеструйный принтер, маркиратор. TIJ Printer называется, но так не гуглится. Да могу протокол кинуть куда-нибудь.
Серийные номера на гп наносить. Наносимое из 1с берется. Связь через сетевой интерфейс, но тут проблем нет
https://drive.google.com/file/d/15aJfrZb8fW_obdPF2F_-ifzvXMgLtFfO/view?usp=drive_link

1.суммируешь
2.Оставляешь младший байт
3.Вычитаешь его из FF.
4.Добавляешь 1
ну или (что то же самое)
3. инвертируешь побитно
4. добавляешь 1

а может там какая то защита стоит, типа пока не заплатишь, можешь отправлять только тот текст, который в примерах. но тоже как то на чепуху похоже..

(19) а, сейчас...

тут не понял
3.Вычитаешь его из FF.
4.Добавляешь 1
ну или (что то же самое)

или что
или ПобитовоеИли

может пример?
вот получили из этого
1B 02 00 1D 02 01 0B 54 49 4A 20 50 72 69 6E 74 65 72 03 0A 30 34 2F 32 37 2F 32 30 31 39 1B 03
655h, так, и

(22) Для своего примера попробуй не B8h а B7h

Походу в принтере пробудился ИИ и порабощает автора.

(24) ? да кто знает, что туда зашили. как еще объяснить, что малейшее изменение дает болт. сумму я для двух примеров из мануала сам считал - сходится с ними.

(25) Проверил (23) ?

(26) нет, ушел уже, завтра пробовать дальше. пока теоретически только прикидывать буду, что не так

(23) вот не нравится мне этот метод бинарного дополнения как написано в документе из (0)
The 2s-complement of 50h is then calculated as follows:
100h - 50h = B0h
Therefore the checksum for the above message is B0h

смотрел на яве как это считается в том калькуляторе по ссылке https://www.planetimming.com/checksum8.html

result = (~(result & 0xff) + 1) & 0xFF;
     // Convert result to string
     //strResult = new String(result.toString());
     strResult = strHex.charAt(Math.floor(result/16)) + strHex.charAt(result%16);

берется по модулю ("~" как понял) и +1. что означает в этом контексте "&"?

перебрал с полдесятка калькуляторов по двоичному дополнению где число hex на входе (у меня в примере 48h) берется в двоичном виде:
0000000001001000 реверсируется:
1111111110110111 к нему добавляется +1, получаем
1111111110111000 и это равно B8h
почему эта *** это не жрет?

(19)

4.Добавляешь 1
ну или (что то же самое)

интригует

(24) Давайте без этих вот...

Наука-техника должна сработать. Чудес не бывает.
Не в сфере электроники и программирования. Это область определённости.

(28) "&" - это "И", логическое умножение, коньюнкция. Побитовое, ессно...
"~" - это "НЕ", логическое отрицание, инверсия (тоже побитовое)
(~(result & 0xff) + 1) & 0xFF - это:
1. (result & 0xff) - накладываем на полученное число маску FF (т.е. оставляем от суммы один только младший байт).
2. ~(result & 0xff) - побитно инвертируем
3. (~(result & 0xff) + 1) - добавляем единицу
4. (~(result & 0xff) + 1) & 0xFF - опять маскируем, чтоб остался только 1 байт (а то вдруг в предыдущем сложениии получилось 100h)

(21) (30) чему тут интриговать? Ну давай напишу так:
1.суммируешь
2.Оставляешь младший байт
3.Вычитаешь его из FF.
4.Добавляешь 1
ну или (что то же самое)
1.суммируешь
2.Оставляешь младший байт
3.инвертируешь побитно
4.добавляешь 1
-------
интрига ушла? это ровно то же, что и  в формуле в (28), только я не отмаскировал результат, ибо подразумевал в силу своей испорченности, что если работаем с байтом, то это и так подразумевается.

(24) меня поглотила тихая пичаль
отправляю строку "TIJ Printer" таким образом
Сообщение =
Символ(27)
+ Символ(2)
+ Символ(0)
+ Символ(29)
+ Символ(1)
+ Символ(1)
+ Символ(11) //служебные, их сумма 71dec

+ "TIJ Printer" //посылаемый текст, сумма 1003d

+ Символ(27)
+ Символ(3); //служебные, сумма 30d

Сумма всего сообщения 1104 десятичная. 1104 and 255 = 80. 256 - 80 = 176. Это контрольная сумма, отпраляем:

Сокет.SendData(Сообщение + Символ(176));

Получаем в ответ:
27
6   //принято
0
18
29
27
3
146 // контрольная сумма ответа, сформированного оборудованием

Все работает, ответ есть, сообщение принято, девайс это отображает на экране

дальше меняем отправляемую строку и пересчитываем сумму:
служебные остаются
+ "TIJ Printep" //сумма 1001dec
+ служебные остаются

Сумма всего сообщения 1102 десятичная. 1102 and 255 = 78. 256 - 78 = 178. Это контрольная сумма, отправляем иии получаем отказ. В от в таком виде:

27
21 //непринято
0
8  //статус - неверная сумма
29
27
3
141 //контрольная сумма ответа, сформированного оборудованием

при этом, если считать сумму в ответах, хоть принятых хоть отказанных, то все правильно, как должно быть.

теперь собственно пичаль:
отправляем "TIJ Printer" - ок (35)
отправляем "TIJ Printeq" - ок (не описывал, но ок)
отправляем "TIJ Printep" - не ок (36)

так я перепробовал от латинских маленьких "о" до "v" в конце посылаемого текста. это какой то рандом - одно принимается, другое нет "о" или "р" нет, "q" "r" да, "s" нет, "t" да. бред какой то

перебором выяснилось, что корректная сумма это символ(1030) для
"TIJ Printep"

перебором выяснилось, что корректная сумма символ(1110) для
"TIJ Printeo"

еще есть такой момент в мануале, в общем описании передачи данных
If character is beyond ASCII, it requires using UTF-8 to encode and decode.

(33)(34) спасибо за разъяснение, тоже самое, да

убрал многа букав в описании, совсем нечитабельно

ладно, наверно не самое подходящее время работу думать
(23) да пробовал, тоже самое

(37) а остальная часть строки - ASCIIшная, и только заменяемый символ - UTFный? Треш какой-то.

(40) полностью текст касательно передачи
All the visible characters in format are transmitted in form of ASCII:
“A1#” → 43 31 23.
Values representing length and quantity (length of string bytes, number of modules, etc.)
are transmitted with hexadecimal values:
10 → A0.
If character is beyond ASCII, it requires using UTF-8 to encode and decode.

вот хз, на всякий пробовал и всю посылку в ютф и отдельно не поместившееся в ASCII, обычно это контрольная сумма. Конкатенация Символ(29) + тратата + сумма в ютф. Через запись текста в файл, потом отправка получившегося. Не работает ни так ни так

(41) для начала научись отправлять чисто аскиишные строки. А уж потом берись за ютф.

(42) всмысле байтами?
+ мои посылки не выходят за аски FF, что они называют ascii. до 127 - аски, до 255 расширенная аски, после 127 в ютф 2 байта, добавляется с2/с3 и до 256. и потом, расчет суммы для того и есть, что бы один байт остался, гарантированно не выше 255 и не ноль соответственно
что и сказано
single byte value:
450h AND 0FFh = 50h
и в мануале где расписано сколько байт занимает та или иная позиция в посылке написано ChekSumm 1byte
Так же, или нет?

(43) а при отправке строки через SendData ничего лишнего отправляться не может? Может, лучше посимвольно?

Я поясню, чего я боюсь. Стандартный способ работы со строками в виндовых приложениях - это utf16 le. Поэтому когда вы отправляете строку, нужно бы посмотреть, что именно отправляется. Возможно там слева от каждого вашего ascii символа еще нулевой байт стоит. Хотя это неточно.

(44) да, это могло бы быть, если бы все посылки отбрасывались, но нет же, эта хрень только на определенных сумму как то по-другому высчитывает и мою не принимает, а на других принимает, вот смотрите

отправляем "TIJ Printer" - ок (35)
отправляем "TIJ Printeq" - ок (не описывал, но ок)
отправляем "TIJ Printep" - не ок (36)

так я перепробовал от латинских маленьких "о" до "v" в конце посылаемого текста.
это какой то рандом - одно принимается, другое нет "о" или "р" нет, "q" "r" да, "s" нет, "t" да
перебором выяснилось, что корректная сумма это символ(1030) для
"TIJ Printep" 

если бы не этот "факт", то согласен, был бы смысл поснифить, что там такое. даже на СОМ порт коммутацию переделал бы, его проще мониторить, чем ethernet, через него все время что то передается
хотя за попробовать посимвольно денег не берут, сейчас..

вот это

отправляем "TIJ Printep"

по-символьно так?

Для Н = 1 По СтрДлина(Сообщение) Цикл
Сокет.SendData(Сред(Сообщение, Н, 1));
КонецЦикла;

получилось тоже самое. Для суммы Символ(178) нет приема, для суммы Символ(1030) есть

(42) все так, залил из шарпа

new byte[] { 0x1B, 0x02, 0x00, 0x1D, 0x01, 0x01, 0x0B, 0x54, 0x49, 0x4A, 0x20, 0x50, 0x72, 0x69, 0x6E, 0x74, 0x65, 0x70, 0x1B, 0x03, 0xB2 }

отработала, зараза. Так и собирался попробовать, соблазн не делать СОМ компонент, а напрямую из 1С слать только останавливал (и работает же, но через раз), но ваших советов это нисколько не умаляет, премного благодарю уважаемых!! полетело..

(48) то есть выходит, что сокетовая компонента 1С все же отправляет не совсем то?

Немного OFF...
Как-то пришлось реализовывать такое, на 7.7:



там расчет контрольной суммы проще, чем в (0), но на 7.7 сделал, и работает :-)

(50) 7.7 приложение неюникодное, поэтому там со строками все более однозначно - если вы отправляете строку, именно та последовательность байт, что в строке, скорее всего и отправляется. А вот чего и как отправляет восьмерка - это надо снифферить и смотреть, я подозреваю, что мусорит она там чем-то, потому и такие странные косяки - то потухнет, то погаснет. В этом смысле, конечно, ВК надежнее, потому что в языках общего назначения все эти байтовые кишки более-менее понятны.

(49) я думаю, что не в компоненте дело, а во всеми нами уважаемой программе

(50) я отправлял на 8ке, было что то несложное, работало. ну как работало, через mscomm конечно)

(51) угу...
но тут конечно возможны варианты - с двоичными данными, baseX и остальным. они то (1с) дали некоторые инструменты, но какой из них будет работать определенно сказать трудно, только перебором, оченна не хочется

Как вариант,писать в файл через двоичные данные,а потом копировать в порт