Вид для печати
Собственно, сабж.
Где-то писали (но только не в документации, разумеется), что ПЛК ОВЕН поддерживают системные события start, stop, before_reset, after_reset, debug_loop.
Пищалка у меня используется для индикации аварии, что-то типа:
if rs485.lastError <> _485_NO_ERROR_ then
beeper := true;
end_if;
Другая задача каждый цикл делает beeper := false.
Так вот, когда питание отключается, пищалка продолжает работу от батареи... И не экономно, и для психики вредно.
Заходите в task configuration
Раскрываете его
System events
Галка напротив stop
В столбце called POU пишете my_stop
Внизу разблокируется кнопка Create POU RR
(через задний проход, ессно. Уведите курсор на другую строку. Потом снова обратно)
Жмете Create POU RR
Переходите на POUs. Там появилась Ваша my_stop (функция)
В ней пишите beep:=false и че еще надо.
Все.
Теперь торпеда. От нее не спасетесь.
Обратно в task configuration
Создаете NewTask
Делаете ее freewheelling (или чего нужно)
Присоединяете к ней PLC_PRG
Про нужную библиотеку кодесис сам напомнит.
Теперь все
PS
Попробуете ?
Единственное, чего непонял - так это слово "торпеда"...
Думаете, я так не делал? Я добросовестно прочел тыщи полторы страниц документации по Кодесису, продукции ОВЕН, форум и пр., и пр... Да, а перед ними еще много читал abok.ru для выбора платформы. Остановился на ОВЕНе.
Сперва обрадовался и заюзал многозадачность... Обнаружились жуткие тормоза при работе по протоколу ОВЕН, я решил (наивный), что это из-за многозадачности и оставил только два процесса... Хотя поудивлялся, как же надо было Кодесису изнасиловать двухсот мегагерцовый проц, чтобы время реакции выхода МДВВ на событие входа МДВВ измерялось секундами.
Выяснил, что это - из-за протокола. Думаю, во многом из-за использования в нем чисел с булькающей запятой для передачи дискретного сигнала (интересно, а ведь камень все же дискретно думает... Какова погрешность ШИМа от ОВЕНа?)... Скачал и опробовал конфигураторы. Ан выяснилось, что они нуждаются в шлюзе RS232-RS485. Однако подсказали что МДВВ-таки конфигурируется из ПЛК, а конфигураторы бессильны. Написал небольшую прогу... И, конечно, выбрал ModBus-ASCII. Хотя догадывался, что RTU все же лучше, но захотелось большей надежности и возможности прослушивания сети.
На этом этапе программа была переписана во второй раз. Наученный горьким опытом, сделал интерфейсный модуль между моим кодом и представлением входов-выходов. Ну, стала быстрее работать, однозначно. Целый день радовался.
Затем обнаружилась аномалия в поведении первого выхода МДВВ. Он то плакал, то смеялся, то щетинился как еж... В общем, у него оказался ШИМ-шайтан встроенный. Правда, на выяснение этого обстоятельства ушло два дня. Почему бы дорогому ОВЕНу не опубликовать толковую errata и не вкладывать ее в упаковки с товаром? А лучше продавать (заказаный DHL'м, кстати, модуль) с дееспособной прошивкой! Тему, в которой этот вопрос обсуждался, надыбал только сегодня.
Но было уже все равно, так как я перешел на ModBus-RTU, в очередной раз перетряхнув программу (ну, не хотелось мне делать PACK и UNPACK... Сделал поразрядную адресацию). Вот. Пока полет нормальный, DCON, надеюсь, исследовать не придется.
Затем занялся визуализацией. Конечно, CoDeSys HMI меня напряг... Придется еще и парольную систему в большом Кодесисе осваивать. Главным образом потому, что ни DDE, ни OPC у меня, естественно, не заработали.
Про разные входы у ПЛК и МДВВ узнал из форума. Иначе бы я их спалил, подключив к оптосенсорам 24 В. Про то, что придется один прибор питать от 24 В, а другой - от 220, знал с самого начала. Единственное, что тогда действительно удивляло, так это то, что приборы с транзисторными выходами изготавливаются под заказ. Это как-то не модно уже, господа... Вы, вообще, в каком веке живете? Да, и только после консультации у местного дилера (довольно крупного, насколько я понимаю, что, впрочем, не обеспечило наличия приборов у него на складе, несмотря на присутствие всей линейки ОВЕН в прайсе), я - программист и электронщик с двадцатилетним стажем, врубился, что такое выходы "для управления твердотельными реле".
Ну, вот, теперь, вроде, только пищалка. Программа была написана и отлажена давно, заказчик неделю ждет, когда же я наконец прошью контроллер...
Да, сам коДеСаксь, конечно, просто убог. Особенно раздражают знааки подчеркивания в зарезервированных словах (ну ладно, ладно, стандарт МЭК...) и конфигураторы в виде деревьев. И дурацкие ветки с единичными листьями в них... Дубовые технологии. (Кстати, была такая фирма Oak Tech. Ага, они самые. А еще была Pine Technologies, но про нее мало кто знает... Гы-гы, в общем). Одно только и радует - бесплатность.
Единственное, с чем могу сравнить - это эпопея с освоением OrCAD'a. PCAD, кстати, вообще не стал осваивать после нескольких general protection fault'ов.
В общем, кто мне расскажет, КАК ВЫКЛЮЧИТЬ ПИСК? Я догадываюсь, что он специально такой сделан... Вечнозеленый. Но неужели не предусмотрели никакой возможности его заткнуть?
Сорри за объем, наболело.
Ну, вот описанный Вами пример.
Да, еще вопрос. Вот это, собсно, что значит в приложении к ПЛК ОВЕН:
"triggered by external event : задача вызывается по событию, которое определено в поле Event. Список доступных событий зависит от целевой платформы"?
И еще. Нужны прерывания. По каждому входу в отдельности и по комбинациям сигналов на них (маске). Причем по фронтам и уровням... Как у Атмела.
И нужна возможность нормальной перепрошивки (желательно прямо по сети RS-485, причем в удаленном режиме) пользователем. Всей линейки устройств. И без дурацких джамперов. А то что это такое - МДВВ прошиваются в сервисных центрах, а ПЛК запломбирован? При таком количестве ошибок в фирмаре и софте без этого никак, господа!
Ну вот, подумал и еще проверил... Все равно...
В этом примере писк включается однократной командой по срабатыванию первого входа... Ну, почти однократной.
Вдогонку: а ошибку четности во встроенных реализациях интерфейсов никак не отловить из программы пользователя? Ну, чтобы качество связи оценивать хотя бы...
Обработал события на старт и стоп программы.Цитата:
Сообщение от superMAX
Обнаружил интересную вещь: при запуске/останове программы кнопкой на самом контроллере, события инициируются, если это делать через меню CoDeSys, то не инициируются :confused:
Но!, если хоть раз нажать программно старт или стоп, то кнопка на контроллере работает, но события уже не инициируются (это продолжается до нажатия сброса кнопкой на контроллере). После переподключения все работает нормально (но не всегда :( ), если конечно пользоваться кнопкой контроллера.
New task не создавал, только привязка к системным событиям функции.
Кстати можно привязывать и программу, а не функцию (что я и делал), не знаю насколько это правильно. Вначале создается программка, а потом уже в событиях прописывается ее имя (тогда кнопка создать POU не разблокируется вообще)
1) Задача проверки питания сводится к добавлению Модуля Statistic в PLC Configuration
2) MDVV с двумя регистрами 51 и 50 на Modbus RTU - просто летает. Да вообщем то по протоколу овен и не предпологалась высокая скорость реакции - там свои задачи.
3) Многозадачность конечно хорошо - но надо помнить что задачи выполняются последовательно.
А прерывания - зачем? Идеология CoDeSys иная, программа отвязывается от железа.
И зачем Вы писали самостоятельно мастер ModBus? Чем встроенный не устраивает?
Прерывания необходимы для реакции на аварийные комбинации входов, когда время реакции должно быть нулевым.
Конечно, я не писал свою реализацию протокола.
Так что там насчет а) контроля качества связи; б) external events? Никто не знает?
Малышев Олег, спасибо большое. Второй раз мне мозги вправляете... Что поделаешь, склероз... Читал ведь про модуль статистики... Хотя, с другой стороны, ну кому так его обозвать пришло в голову? Ваще такие вещи бы надо иметь в конфиге таргета по умолчанию. Кому не нужны - мог бы (наверное) и отключить.
Спасибо, рад был помочь. В большинстве случаев управление в случае аварии народу не нужно... Поэтому пошли обратным путем.
Нулевого ничего не бывает. Однако прерывания всё-же уже реализованы в ПЛК110 (время реакции 20 мкс). На ПЛК 100/150 слишком медленные входа/выхода.Цитата:
Сообщение от superMAX
а) контроля качества связи - все данные есть в соответствующих переменных мастеров
external events - а конкретнее что бы хотелось? Какие такие "внешние" события?
Олег , поясните плз , как сделать чтоб мдвв летал ? у меня
при подключении мдвв к плк (командами 50 и 51) реакция входов-выходов около 1сек ( .
Выложите сюда проект на ПЛК и конфигурацию на МДВВ.
З.Ы. еще, как вариант, для того, чтобы МДВВ летал. :D
:D :D :D :D :D
да какой там проект !
http://clip2net.com/s/2hjfK
в проге : vih1:=vhoMDVV1;
http://clip2net.com/s/2hjit
реакция выхода на вход - около секунды ....
Странненько, у меня она практически моментальная. Может, все же зальете сюда проектик?
Какая скорость обмена стоит?
Вот проект : оч хотелось бы увидеть реакцию выхода на вход в разумных временных рамках
А Вы можете залить в ПЛК простой проект (без программы), где бы приравняли считанные значения с 51 регистра к 50 (типа замкнуть входы на выходы напрямую)?
Потому что, залил Ваш проект, ну, все нормально. Время отклика - десятая доля секунды.
Так и сделал сейчас , реультат тот же , то бишь нет результата = отклик с полсекунды (((( на 150-м . обмен 11520 ....
Предлагаю открыть прибор, разрезать дорожку и впаять диод по питанию пищалки и светодиодов. То, что должны были сделать производитель со инженеры! У меня та же бяка со светодиодами.