CODESYS V3.5. Вопросы и ответы

[Петр Петрович]

Задача прояснилась, но я все равно пока не понимаю, зачем вам там цикл WHILE.
Выложите пример кода, чтобы стало яснее, для чего вы его используете.

Спасибо, оправил в личку двумя частями. Приношу извинения, не пойму, можно ли вставлять сообщения как код, форматирование пропадает. Вчера вечером заменил WHILE на REPEAT и забыл про это. Ну суть, конечно, не меняется. Этот обработчик внутри главного цикла.

[Евгений Кислов]

Спасибо, оправил в личку двумя частями. Приношу извинения, не пойму, можно ли вставлять сообщения как код, форматирование пропадает. Вчера вечером заменил WHILE на REPEAT и забыл про это. Ну суть, конечно, не меняется. Этот обработчик внутри главного цикла.

Я посмотрел код - и, честно говоря, понятнее не стало.
Попробуйте алгоритм на словах описать (чем подробнее - тем лучше).
В чем смысл каждой последующей итерации?

[Петр Петрович]

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

[Евгений Кислов]

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

Приведенное описание не поясняет необходимость цикла с неизвестными числом итераций при парсинге.

[Петр Петрович]

В общем, пожалуй, да. Длина сообщения конечно известна. Правда, двигаться внутри приходится, то по по два байта, то по четыре, то вообще на заранее неизвестное число байт, это если в телеграмме символьная строка или несколько строк. Эти шаги выясняются при разборе. Контрольной суммы как ни странно, железка не дает. Т.е. я сразу не могу отбросить всю телеграмму. Окончание строки может быть как "FB" так и отсутсвовать, если данные пришли сами, без запроса. В этом случае будет просто четное число бвйт, но это чисто так, примечание.

Условие выхода из цикла в общем понятны, и их можно задать. Но если данные будут искажены, то выход может и не состоятся. Это в реальных условиях. А просто обрабатывать в главном цикле побайтно мне кажется рискованно. У меня время цикла среднее менее 200 мкс. Т.е. как я понимаю, он выполняется примерно 5000 раз в секунду, грубо. В нем обрабатывать конечно можно было бы, но ведь потом программа может усложнится и цикл увеличится. Возвращаясь к циклу, условия выхода там в общем то заданы... но если в данных будет ошибка, то парсер собьется и последствия - зацикливание. Вот пока думаю.

[Евгений Кислов]

Но если данные будут искажены, то выход может и не состоятся.

Мне эта фраза непонятна - если данные искажены, то парсер (основанный на заранее известных правилах) должен определить пакет как невалидный и на этом прекратить работу.

P.S. - если для вас критично быстродействие и с учетом того, что у вас Raspberry Pi - вы можете парсер (или вообще всю эту часть, включая обмен) переписать на С и передавать данные в CODESYS через разделяемую память.

[Петр Петрович]

Мне эта фраза непонятна - если данные искажены, то парсер (основанный на заранее известных правилах) должен определить пакет как невалидный и на этом прекратить работу.

Согласен! Надо будет еще раз проанализировать код, может, я что-то усложняю. Скорость, кстати, пока отличная (ттт). А вообще, обработка в главном цикле, без дополнительных циклов, практикуется?

[Евгений Кислов]

Согласен! Надо будет еще раз проанализировать код, может, я что-то усложняю. Скорость, кстати, пока отличная (ттт). А вообще, обработка в главном цикле, без дополнительных циклов, практикуется?

Обработка в главном цикле без дополнительных WHILE/REPEAT - это типовой подход.
FOR используется гораздо чаще, так как обычно число итераций заранее известно.

[Петр Петрович]

Обработка в главном цикле без дополнительных WHILE/REPEAT - это типовой подход.
FOR используется гораздо чаще, так как обычно число итераций заранее известно.

Ясно, спасибо. А про FOR я читал Ваш документ про отладку, да.

[DenisV]

Системное время в веб-конфигураторе и время в таргет-переменной st.Rtc.dtDateAndTime это разное время? Почему при ручной синхронизации времени dtDateAndTime равна времени Ntp сервера, а системное время в конфигураторе дополнительно смещено по utc?
Screenshot_3.png
Screenshot_4.png


Причем если предположить, что это разные переменные, и веб-конфигураторе выставить время GMT 0, с применением настройки, после синхронизации опять произойдет смещение согласно siSetUtcOffset
Screenshot_5.png

Ntp сервером выступает мой ПК с utc +3