Вид для печати
Подскажите пожалуйста! Приобретён ПЛК 100-24 К-М. Есть задача ситывания текущего времени из ПК и его запись в ПЛК. В Library Manager подключаю библиотеку SysLibRtc для использования системной функции SysRtcGetTime, но ПЛК с подключенной бибиотекой приложение "не пускает". (Без SysLibRtc ПЛК загружается и работает нормально). Что делать? М.б. нужна другая прошивка или ругая модель ПЛК?
Нужна другая модель ПЛК. В ОВЕН ПЛК1ХХ библиотека SysLibRTC не поддержана. Поддержана SysLibTime.
Примеры работы с библиотекой есть на форуме...
В общем, чтобы записывать текущее время ПК в Овен, вывёртываюсь так: С помощью средста VB-6 считываю текущую дату и время с ПК, затем - формирую (т.е. вычисляю) текущее время и представляю его числом, понятным Овену, как текущая дата и время в формате DINT. Затем перевожу это число в Hex-ы, меняю местами по 4 информационных байта фрейма и вставляю в посылку по Modbus ASCII. (Используется Com порт). Осталось найти как считать контрольную сумму (взятый из имеющегося примера алгоритм не даёт нужного числа), может кто подскажет, где есть описение протокола Modbus ASCII именно для Овена с доходчивым описанием алгоритиа вычисления контрольной суммы.
Пы.Сы. Посылка, для конкретной точки времени, получается такая: 05100004000200AAFD4D35BD (данные AAFD4D35 точно щас не помню, только контр. сумму ).
Причём пока не поставил 2 нуля (в имеющемся описании фрейма) после длины запроса (парам. 0002), Овен посылку не воспринимал. Код посылки выискивал с помощью Lectus Modbus OPC and DDE server.
Осталось найти надлежащий алгоритм вычисления КС. Буду очень благодарен Вам за подсказку.
МиХаил, спасибо, но это расчёт CRC суммы, когда в ASCII требуется LRC сумма. Порылся в инете и нашёл 2 разных способа исчисления LRC суммы. Отличие - оконцовке. В одном (видимо в стандартном) сумма инвертируется и плюсуется 1, в другом - 256 (FA) минус сумма "доконтрольных" чисел.
Потратим минуту времени находим в интернете следующее:Цитата:
Сообщение от Василий_S
Контрольная сумма в режиме ASCII это LRC. Контрольная сумма - это 8-ми разрядное число, передаваемое как два ASCII символа (hex). Контрольная сумма образуется путем конвертирования всех hex символов в двоичные числа, сложением этих чисел без учета переноса, и вычислением дополнительного кода полученного числа. В приемнике LRC заново рассчитывается и сравнивается с полученным LRC. При вычислении LRC двоеточие, CR, LF и любой другой не-ASCII символ отбрасывается.
Источник:
http://www.google.ru/url?sa=t&source...uvkViQ&cad=rjt
Александр, Нашёл свою ошибку - не указал количество передаваемых байт, вместо числа - поставил 00. Оттого и КС отличается от требуемой.
Это проще сделать использую ОРС КДС и сислиб тайм.
Да, но в моём случае ситуация иная: SCADA самодельная - на VBЦитата:
Сообщение от lara197a
Ура-аааааааааааааааааааааааааааа! Получилось!
В ПЛК постоянно передаётся время из ПК. Блин, арифметичекая сумма должна быть, а не логическая перед инвертированием.
Вопрос! В сети RS 485, протокол Modbus ASCII, - несколько устройств Owen - Slave, естесственно со своим адресом каждый. Каким макаром можно осуществлять посылку данных (в д. сл. - текущее время) на все устройства одновременно?
Заранее благодарен за ответ.
По хорошему постоянно время передавать в ПЛК не стоит, это достаточно делать раз в сутки.
Посмотрю как бдут разбегаться часы. А вообще-то спрашивал про возможность одновременной записи данных вовсе устройства.
Фига се, существенный разбег по времени получается между временем, сосчитанным с ПК и показаниями часов реального времени в ПЛК. В 13-26 уже была разница в 16 сек, а в 15-08 - 48 сек.
Точность по времени актуальна в поставленной задаче, поэтому придётся частенько корректировать время.
Можно попробовать передавать на адрес 0
Адрес 0 используется для широковещательной передачи, его распознаёт каждое устройство.
Дмитрий, спасибо. Т.е. посылка пр Modbus ASCII должна начинаться 00 10 ...., так? Я бегло пробовал, чё-то не пошло и отложил на потом . Займусь плотнее.Цитата:
Сообщение от Дмитрий Ф
Вообще, часы реального времени гонят полную лажу. А точность по времени актуальна. Делаю постоянное считывание времени с ПК, и склоняюсь привязать время в ПК к серверу времени.
Чото странно. Живьем видел 15 мин за год. А тут - 1-2 дня за год :eek:[/QUOTE]
Что есть - то есть. В один тег записываю время, присылаемое с ПК, во второй - из часов реального времени и, покуривая сигарету, наблюдаю как часики тикают - разница во времени растёт "на газах". Может, часы такие попались?
[QUOTE=Валенок;54397]А тот кто посылает, различает broadcast ?
Простите, не совсем понял вопрос.
Состояние батарейки может влиять на ход часов?Цитата:
Сообщение от Валенок
Не должно. Только на ход часов при отключении питания.
Если я правильно понял тему, то я натыкался на похожие проблемы на ПЛК63: http://www.owen.ru/forum/showthread.php?t=9010
Изначально та тема была начата по другой проблеме (кривые руки), но вот к сообщению №9 проблема уже более-менее локализовалась. Правда программа под ПЛК63 и, не помню уж точно, но, наверное, отображала часы на экран. Если так - вывод надо закомментарить. Я тогда проблему не решил, и всё время вычисляю, как и посоветовали, одним из методов - что в моём случае жить совершенно не мешает.
В данном случае задача обратная. Следить за тем, чтобы часы в сотке тикали так же как и в компе. В результате творческих терзаний организовал постоянную запись времени в "принимающий" тег (с периодичностью цикла опроса значений заданных тегов по модбасу) и коррекцию часов таймера из этого тега уже в программе контроллера с периодичностью 9 секунд. Но всплыла ещё одна проблемка - после записи значения времени из ПК в реальные часы ПЛК сами часы стартуют с отличным от записываемого времени в пределах 1 сек. Полагаю, что часики ПЛК отбрасывают или не учитывают доли секунд. А точность по времени актуальна.Цитата:
Сообщение от Elka
Более того, разаботку программы ПЛК надо будет множить на 20 с лишним контроллеров, т.к. надо вести учёт около 200 импульсных сигналов со счётчиков активной мощности. И все контроллеры вязать в модбасовскую сетку. Вот тогда будет гораздо "веселее" синхронизировать время в контроллерах со временем ПК.
а NTP не пробовали подключать? так чтобы ПЛК сам стучался на сервак и забрал время, протокол поверх udp вроде не очень замороченный
capzap когда-то выкладывал пример программы подключения к ntp
Да, что касается точности, то если вы будете ломиться на ntp сервера более высокого уровня, вас просто могут блокирнуть, а ntp сервера уровня 2, которые общедоступны, тоже дают точность в пределах секунды.
однако он жалуется, что надо это делать на 20 устройствах с таким решением, так как каждому надо передавать время из Scada
а, ну да, давненько... на даты часто не смотрю..