Страница 1 из 3 123 ПоследняяПоследняя
Показано с 1 по 10 из 23

Тема: Как выключить пищалку при отключении питания?

  1. #1

    По умолчанию Как выключить пищалку при отключении питания?

    Собственно, сабж.
    Где-то писали (но только не в документации, разумеется), что ПЛК ОВЕН поддерживают системные события start, stop, before_reset, after_reset, debug_loop.
    Пищалка у меня используется для индикации аварии, что-то типа:

    if rs485.lastError <> _485_NO_ERROR_ then
    beeper := true;
    end_if;


    Другая задача каждый цикл делает beeper := false.
    Так вот, когда питание отключается, пищалка продолжает работу от батареи... И не экономно, и для психики вредно.

  2. #2
    Пользователь
    Регистрация
    23.09.2008
    Адрес
    Центророссийск
    Сообщений
    2,318

    По умолчанию

    Заходите в 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
    Попробуете ?

  3. #3

    По умолчанию

    Единственное, чего непонял - так это слово "торпеда"...

    Думаете, я так не делал? Я добросовестно прочел тыщи полторы страниц документации по Кодесису, продукции ОВЕН, форум и пр., и пр... Да, а перед ними еще много читал 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'ов.

    В общем, кто мне расскажет, КАК ВЫКЛЮЧИТЬ ПИСК? Я догадываюсь, что он специально такой сделан... Вечнозеленый. Но неужели не предусмотрели никакой возможности его заткнуть?

    Сорри за объем, наболело.

  4. #4

    По умолчанию

    Ну, вот описанный Вами пример.

    Да, еще вопрос. Вот это, собсно, что значит в приложении к ПЛК ОВЕН:
    "triggered by external event : задача вызывается по событию, которое определено в поле Event. Список доступных событий зависит от целевой платформы"?
    Вложения Вложения

  5. #5

    По умолчанию

    И еще. Нужны прерывания. По каждому входу в отдельности и по комбинациям сигналов на них (маске). Причем по фронтам и уровням... Как у Атмела.

    И нужна возможность нормальной перепрошивки (желательно прямо по сети RS-485, причем в удаленном режиме) пользователем. Всей линейки устройств. И без дурацких джамперов. А то что это такое - МДВВ прошиваются в сервисных центрах, а ПЛК запломбирован? При таком количестве ошибок в фирмаре и софте без этого никак, господа!

  6. #6

    По умолчанию

    Ну вот, подумал и еще проверил... Все равно...

    В этом примере писк включается однократной командой по срабатыванию первого входа... Ну, почти однократной.
    Вложения Вложения

  7. #7

    По умолчанию

    Вдогонку: а ошибку четности во встроенных реализациях интерфейсов никак не отловить из программы пользователя? Ну, чтобы качество связи оценивать хотя бы...

  8. #8

    По умолчанию

    Цитата Сообщение от superMAX Посмотреть сообщение
    Собственно, сабж.
    Где-то писали (но только не в документации, разумеется), что ПЛК ОВЕН поддерживают системные события start, stop, before_reset, after_reset, debug_loop.
    Пищалка у меня используется для индикации аварии, что-то типа:

    if rs485.lastError <> _485_NO_ERROR_ then
    beeper := true;
    end_if;


    Другая задача каждый цикл делает beeper := false.
    Так вот, когда питание отключается, пищалка продолжает работу от батареи... И не экономно, и для психики вредно.
    Обработал события на старт и стоп программы.
    Обнаружил интересную вещь: при запуске/останове программы кнопкой на самом контроллере, события инициируются, если это делать через меню CoDeSys, то не инициируются
    Но!, если хоть раз нажать программно старт или стоп, то кнопка на контроллере работает, но события уже не инициируются (это продолжается до нажатия сброса кнопкой на контроллере). После переподключения все работает нормально (но не всегда ), если конечно пользоваться кнопкой контроллера.
    New task не создавал, только привязка к системным событиям функции.
    Кстати можно привязывать и программу, а не функцию (что я и делал), не знаю насколько это правильно. Вначале создается программка, а потом уже в событиях прописывается ее имя (тогда кнопка создать POU не разблокируется вообще)

  9. #9

    По умолчанию

    1) Задача проверки питания сводится к добавлению Модуля Statistic в PLC Configuration
    2) MDVV с двумя регистрами 51 и 50 на Modbus RTU - просто летает. Да вообщем то по протоколу овен и не предпологалась высокая скорость реакции - там свои задачи.
    3) Многозадачность конечно хорошо - но надо помнить что задачи выполняются последовательно.

  10. #10

    По умолчанию

    А прерывания - зачем? Идеология CoDeSys иная, программа отвязывается от железа.
    И зачем Вы писали самостоятельно мастер ModBus? Чем встроенный не устраивает?

Страница 1 из 3 123 ПоследняяПоследняя

Ваши права

  • Вы не можете создавать новые темы
  • Вы не можете отвечать в темах
  • Вы не можете прикреплять вложения
  • Вы не можете редактировать свои сообщения
  •