| Автор |
Повідомлення |
|
Повідомлення створено: 14. 03. 2011 [16:56]
|
|
roman
Roman Savochenko
Moderator Contributor Developer
Зареєстрован(а) с: 12.12.2007
Повідомлення: 3750
|
Код жуткий! Но раз я его включил в репозиторий то пришлось всё переписать.
Проверяйте. Не исключаю, что с ходу не заработает ибо слишком много изменений, а тестировать не на чем.
Learn, learn and learn better than work, work and work.
|
|
Повідомлення створено: 15. 03. 2011 [11:13]
|
|
almaz
Almaz Karimov
Contributor
Автор теми
Зареєстрован(а) с: 25.09.2008
Повідомлення: 516
|
Мощно оптимизировали! Сразу подключил блок I-7051 - метод 16DI (@AA) работает. Просмотрев код - обнаружил некоторые неполадки.
Обработка ошибок вынесена из процедуры Task в DCONReq, но картину портит нестандартность протокола DCON у различных блоков. Подробнее:
1) Расположение CRC почти во всех устройствах в конце ответа, перед символом "\r". Исключение из этого правила составляют ответы блоков I-7080, I-7083, NL-2C при чтении счётных входов (методы 2CI (#AA), 3CI (#AA)). Контрольная сумма расположена 2 и 3 байтом перед счётными данными. Устранял эту нестандартность коррекцией ответа модулей pdu = pdu.substr(0,1) + pdu.substr(3,8) + pdu.substr(1,2).
2) Первый в ответе символ ">" не для всех блоков означает корректный ответ. Для методов 1DI (@AADI), 2DO (@AADO), 4DO (@AADO), 6DO (@AADODD), 2DO (@AADO0D), 4DO (@(^)AADO0D) корректный ответ означает первый символ "!".
3) Первый в ответе символ "!" для некоторых блоков означает корректный ответ (пункт 2), а для некоторых - ошибку (вроде для разных блоков может означать разные ошибки).
4) Первый в ответе символ "?" означает ошибку "24:Module out of range" только для аналогового вывода (AO). Для некоторых других блоков "?" - это "22:Invalid module response".
Очевидно, что многие устройства теперь работать не будут или будут работать некорректно.
Как быть? Или вернуть анализ ошибок в процедуру Task, или протащить "индивидуальность" методов в процедуру DCONReq? По-моему, проще вернуть в Task, так как мало ли ещё какие нестандартные методы обмена будут... Было бы проще в дальнейшем добавлять новые методы обмена...
[Повідомлення редагувалось 2 раз(ів), останній раз 15.03.2011 в 12:27.]
21 век - век повсеместной автоматизации. Главное - во благо всем людям.
|
|
Повідомлення створено: 15. 03. 2011 [12:52]
|
|
roman
Roman Savochenko
Moderator Contributor Developer
Зареєстрован(а) с: 12.12.2007
Повідомлення: 3750
|
"almaz" wrote:
Обработка ошибок вынесена из процедуры Task в DCONReq, но картину портит нестандартность протокола DCON у различных блоков. Подробнее:
...
Как быть? Или вернуть анализ ошибок в процедуру Task, или протащить "индивидуальность" методов в процедуру DCONReq? По-моему, проще вернуть в Task, так как мало ли ещё какие нестандартные методы обмена будут... Было бы проще в дальнейшем добавлять новые методы обмена...
Давайте так. Вы скажите, что для многих модулей типично и оно будет реализовано прямо в DCONReq(). Что не типично будет отключаться указанием не проверять CRC и нулевой ожидаемой длиной сообщения, этой функции, с отдельной проверкой прямо в коде запроса.
Указанные исключения я учёл. Проверяйте!
Learn, learn and learn better than work, work and work.
|
|
Повідомлення створено: 15. 03. 2011 [14:35]
|
|
almaz
Almaz Karimov
Contributor
Автор теми
Зареєстрован(а) с: 25.09.2008
Повідомлення: 516
|
Принцип понял:
1. Контроль CRC нужно отключить в процедуре DCONReq для методов 2CI (#AA), 3CI (#AA) и выполнить этот контроль в Task.
2. Проверку первого символа в процедуре DCONReq оставить только для ">" ("!" и "?" убрать как специфичные). Большинство ответов содержат символ ">" при корректном обмене. Нужно отключить проверку первого символа вообще для методов, имеющих специфичный первый символ (даже при корректном обмене он иногда сигнализирует о внутренней ошибке блока), и выполнить эту проверку в Task. Вот список этих методов обмена: все методы AO, 1DI (@AADI), все методы DO. Получается, что типично работают только все AI блоки и почти все DI, кроме одного.
Нахожу ещё неполадки:
- после проверки диапазонов AO иногда требуется строка с передаваемым числом со знаками ("+", "-"), иногда без знаков (Engeneer (00.000 20.000), Engeneer (+00.000 +20.000)). В обоих случаях используется одна и та же команда str = TSYS::strMess("%+07.3f",vmax(0,vmin(20,cntr.p_hd[i_p].at().AO[i])));
- некорректно выполнена установка атрибутов при разборе ответов блоков по методу 1DI (@AADI) и 8DI (@AA,FF00).
- нет проверки соответствия длины пакета ожидаемому acq_len. При разборе с помощью substr выход за пределы строки приводил к вылету скады.
[Повідомлення редагувалось 1 раз(ів), останній раз 15.03.2011 в 15:58.]
21 век - век повсеместной автоматизации. Главное - во благо всем людям.
|
|
Повідомлення створено: 15. 03. 2011 [16:28]
|
|
roman
Roman Savochenko
Moderator Contributor Developer
Зареєстрован(а) с: 12.12.2007
Повідомлення: 3750
|
"almaz" wrote:
- некорректно выполнена установка атрибутов при разборе ответов блоков по методу 1DI (@AADI) и 8DI (@AA,FF00).
Что не корректного?
"almaz" wrote:
- нет проверки соответствия длины пакета ожидаемому acq_len. При разборе с помощью substr выход за пределы строки приводил к вылету скады.
Где? Есть везде.
Обновитесь!
P.S. Эти ошибки можете уже и сами править. А мне шлите патч.
Learn, learn and learn better than work, work and work.
|
|
Повідомлення створено: 16. 03. 2011 [08:01]
|
|
almaz
Almaz Karimov
Contributor
Автор теми
Зареєстрован(а) с: 25.09.2008
Повідомлення: 516
|
Хорошо. Пользуюсь svn 1304. Поправлю пока обработку первого символа ответа и введу проверку длины ответа с ожидаемой (acq_len). Если найдутся ещё неполадки - попутно тоже поправлю...
[Повідомлення редагувалось 3 раз(ів), останній раз 16.03.2011 в 08:06.]
21 век - век повсеместной автоматизации. Главное - во благо всем людям.
|
|
Повідомлення створено: 16. 03. 2011 [08:21]
|
|
roman
Roman Savochenko
Moderator Contributor Developer
Зареєстрован(а) с: 12.12.2007
Повідомлення: 3750
|
"almaz" wrote:
Хорошо. Пользуюсь svn 1304. Поправлю пока обработку первого символа ответа и введу проверку длины ответа с ожидаемой (acq_len).
Что с обработкой символа не так?
Проверка длины acq_len есть!
Learn, learn and learn better than work, work and work.
|
|
Повідомлення створено: 16. 03. 2011 [09:08]
|
|
almaz
Almaz Karimov
Contributor
Автор теми
Зареєстрован(а) с: 25.09.2008
Повідомлення: 516
|
Проверку длины ответа надо проводить в первую очередь (можно после проверки на последний символ \r), иначе при ошибке длины ответа будет появляться ошибка CRC.
Также проверка длины не производится в DCONReq для нетипичных блоков, так как acq_len использован в качестве признака непроверки первого символа (нужно будет ввести другую переменную). Вернее, проверка длины производится в Task, но после проверки CRC в DCONReq, то есть вместо ошибки длины будет появляться ошибка CRC.
С анализом первого символа вроде местами тоже неполадки. Пока детально не вникал - надо смотреть документацию на каждый блок.
[Повідомлення редагувалось 2 раз(ів), останній раз 16.03.2011 в 09:13.]
21 век - век повсеместной автоматизации. Главное - во благо всем людям.
|
|
Повідомлення створено: 16. 03. 2011 [09:25]
|
|
roman
Roman Savochenko
Moderator Contributor Developer
Зареєстрован(а) с: 12.12.2007
Повідомлення: 3750
|
"almaz" wrote:
Проверку длины ответа надо проводить в первую очередь (можно после проверки на последний символ \r), иначе при ошибке длины ответа будет появляться ошибка CRC.
Проверяется. Проанализируйте внимательнее код!
"almaz" wrote:
Также проверка длины не производится в DCONReq для нетипичных блоков, так как acq_len использован в качестве признака непроверки первого символа (нужно будет ввести другую переменную). Вернее, проверка длины производится в Task, но после проверки CRC в DCONReq, то есть вместо ошибки длины будет появляться ошибка CRC.
Как раз это и правильно. Первичны '\r' затем CRC, а уж затем всё остальное, включая и размер пакета в случае ответов с признаком ошибкой.
Learn, learn and learn better than work, work and work.
|
|
Повідомлення створено: 16. 03. 2011 [09:35]
|
|
almaz
Almaz Karimov
Contributor
Автор теми
Зареєстрован(а) с: 25.09.2008
Повідомлення: 516
|
Думаете есть смысл проверять контрольную сумму при неверной длине пакета? Ошибка длины пакета приоритетнее ошибки CRC.
21 век - век повсеместной автоматизации. Главное - во благо всем людям.
|
