А причем здесь ПЛК-слейв ?
А причем здесь ПЛК-слейв ?
Последний раз редактировалось Вольд; 15.02.2014 в 20:20.
Ну так на это и capzap намекает достаточно толсто
За шайбу незасчитанную волнуемсяА нам волноваться особо не стоит
Последний раз редактировалось Валенок; 15.02.2014 в 20:23.
В общем, получается такая штука. В моменты, когда в ответе из ПЛК в КС стоят нули, сама КС равна 256 в децималах или 100 в хексах (должно ли быть такое вообще?). Т.е. получается, что в КС,в положенные два символа,, при значении равном 100 в хексах, записываются второй и третий символ (нули), а единица куда-то теряется.
Был проведён эксперимент: "ловить" содержимое ответа ПЛК при условии:
1. если в КС стоят два нуля, как хексовские символы;
2. если в КС стоит один ноль, как хексовский символ;
3. если в КС пусто
4. если превышен таймаут ожидания.
При этом в строку текстового файла записывалось:
1. Адрес ПЛК;
2. Время записи;
3. количество повторных запросов к ПЛК;
4. содержимое буфера;
5. отдельно вычисленная КС в децималах;
6. перевод вычисленной КС в хексы;
7. реальные символы из КС;
8. длина буфера;
9. флаг функции вычисления КС (1, если вычисленная КС совпадает с реальной, 0 - если не совпадает)
10. флаг таймаута ожидания (1 - если время превысило уставку, 0 - если нет.)
Результат такой: везде, где в месте КС стоят нули вычисленная КС = 256 в децималах.
Переведённая подсчитанная КС в хексы показывает 0, поскольку функция расчитана на перевод двух символов.
Вырезанная - показывает то, что есть - "00"
При этом длина буфера равна требуемой - 75, ну и флаг по КС равен логическому нулю, да, и флаг по таймауту тоже в нулях.
Пример:
содержимое буфера:
:23 03 20 (0058 0000) (007Е 0000) (00А3 0000) (0006 0000) (0000 0000) (0038 0000) (0003 0000) (0000 0000) 00 ||
, вроде перепечатал без ошибок. В скобках - подсчитанные импульсы на 8-ми входах ПЛК (Hex), жирным шрифтом - содержимое КС
Вычисленная КС = 256(Dec)
Количество повторных запросов - 20 (такая уставка)
длина буфера = 75 - видимо, приём ответа от ПЛК полный и нет записей содержимого буфера в другой файл по событию, если длина буфера меньше 75.
Что получается, ПЛК теряет "1" - первый символ из 100(Hex) и пишет в КС два нуля?
Последний раз редактировалось Василий_S; 24.02.2014 в 15:58.
Вот пока в пути и не рядом с компом, появилось несколько вопросов
Модбас аскии чем определяется конец посылки?
Сколько байт занимает контрольная сумма и сколько это в количественном формате отображается в консоли
пока все, на телефоне не вижу текст поэтому мысль потерял
Посылка по модбасу в ASCII-режиме заканчивается последовательностью "возврат каретки-перевод строки".
Перед ней КС занимает 2 символа, насколько понимаю.
Приёмное устройство - MOXA CP-114IS/DB9M V1.3 на 4 порта. Может не стыкуется мокса с овеном в "отдельные моменты"?
Блин вроде всё правильно, а при расчете кс инверсия и прибавление единицы делается
И самое главное не вставляется ли высчитанная кс на клиенте в приемный буффер,а потом уже логинится в файл
Может так и задумано в ПЛК Овен, что 256(Dec) представляется двумя нулями и надо иметь ввиду, что это 100(Hex), следующая цифра после FF? Интересно, почему овеновцы молчат?
Вы не катите на овен, есть те же орс серверы модбас, ставим их и смотрим логи, появятся ли там подобные ошибки, поймите алгоритм lrc достаточно прлст, чтоб программист его не смог соблюсти. И чем мусолить эту тему, прлтестируйте свою программу на комп.эмуляторе слейва. Тем более когда у Вас известен весь пакет с нулевой кс, Вы знаете какое/кие числа там находятся и заполнить эмулятор проблем нет и в случае если в течении n-ного времени ошибок не будет,тогда предъявляйте документированную претензию