ВходНаше всё Теги codebook 无线电组件 Поиск Опросы Закон Воскресенье
19 мая
177186 Топик полностью
teap0t (01.01.2010 14:31 - 14:56, просмотров: 189) ответил AlexandrY на Не проще ли рассказать что у вас за трудности.
Встала тут передо мной задача: надо сделать устройство управления промышленной аппаратурой. Задача, конечно, свежая и оригинальная. До того свежая, что на устройства такого рода (P[rogrammable] L[ogic] C[ontroller]) уже даже стандарт есть IEC 61131. Evgeny_CD и ссылку на книгу по теме подогнал. Вообще, надо заметить, народ решает задачи контроля промышленных процессов двумя основными способами - изготовлением узкоспециализированных устройств для узкоспециальных задач (пожарная сигнализация, "умный дом") и производством универсальных контроллеров для управление всем подряд. Узкоспециальные направления обсуждать не будем. Взглянем лучше на универсальные контроллеры. На рынке подобные системы присутствуют в больших количествах - Siemens, Omron etc. Есть и самопальные. Всё, что я до сих пор видел (вернее, о чём читал) выглядит как модуль с фиксированным количеством линий ввода и вывода, между которыми с помощью неких программных средств можно организовывать связи и формировать логику работы управляющей системы. В номенклатуре присутстсвуют модули аналогового ввода. Функциональность сименсовских модулей LOGO можно наращивать объединением нескольких модулей. Максимальное количество объединяемых модулей фиксировано. Есть и другие ограничения по объединению. У других производителей параметры сходные. Дабы не обнимать необъятное, сузим задачу, вернее, определим достаточно широкий, но небезграничный сегмент управляющих систем, а именно - системы с дискретным вводом-выводом, т.е. кнопками, сухими контактами, соленоидами, модулями плавного пуска и т.д. Другими словами, системы, имеющие на сигнальных входах и линиях управления только состояния ВКЛЮЧЕНО/ВЫКЛЮЧЕНО. Основное свойство - максимум гибкости при минимуме номенклатуры управляющих модулей. Достичь указанной цели можно объединением элементарных модулей с минимальной собственной функциональностью в супермодули. Подходящие для задачи корпуса и прочие причиндалы выпускает Phoenix Contact (ME MAX). Конструктив монтируется на стандартную DIN-рейку. Особенностью данного конструктива является сквозная шина (5 линий), объединяющая все модули. На шину хорошо ложится протокол CAN. Далее возникает проблема объединения модулей в супермодули. Возможны (т.е. мне известны) два подхода к решению задачи - абсолютная (a la Ethernet) и относительная (позиционнозависимая) адресация элементарных модулей. Рассмотрим оба способа внимательнее. Для абсолютной адресации нужен источник уникальных номеров модулей. На данный момент это не проблема, т.к. номерные микросхемы самых разных назначений не делает только ленивый. Функционал модуля определяется на этапе монтажа-конфигурации и записывается в энергонезависимую память модуля или загружается при включении питания. Но есть проблема: модули у нас одинаковые и их функциональность определяется только номером модуля, а выполняемые задачи определяются физическими линиями связей (положением в составе системы). Перепутав при монтаже/техобслуживании два модуля мы можем запустить слив расплавленного металла вместо включения вентиляции цеха. Гораздо правильнее в контексте подключения к жгутам и оконечным исполнительным устройствам выглядит позиционнозависимая система адресации: на первый слева модуль заводится привод плавильной ванны, на второй слева - вентиляция цеха. Модули при этом никакой конфигурации не хранят и загружаются каждый раз при включении питания. Модули можно перемешивать в произвольном порядке, но исполняемая ими роль (в контексте географического положения) не меняется - вентиляция всегда на втором слева модуле. Теперь надо решить вопрос конфигурации модуля. Возможны следующие полярные способы задания конфигурации: Бинарный исполняемый код. Нужная функциональность выбирается из списка имеющихся. Интерпретируемый код (BASIC с расширением для управления промышленными процессами). В первом случае сложности с наличием всех возможных сочетаний (конфигурации могут отличаться полярностью входного сигнала). Во втором задача ставится черезчур радикально. Промежуточный вариант - создание библиотеки системных функций для стандартных задач (a la BIOS for IBM PC). Вот об этом и вопрос. К вопросу о неисчерпаемости таймера. Насчёт таймера я не думал, а кнопку можно попытаться сосчитать. Какие свойства могут быть у кнопки, как класса/системного вызова? Кнопка может иметь встроенную защиту от дребезга или нуждаться во внешней процедуре защиты. У кнопки может быть активен уровень или фронт. У кнопки должна быть задана полярность активного состояния. На выходе два состояния - АКТИВНА/НЕАКТИВНА. Всё? С кнопками возможна некая проблема, связанная с нетрадиционной ориентацией пользователя. Возьмём к примеру "кнопку водителя" на АЗС. Данная кнопка запускает процесс налива топлива в бак. Стандартная процедура, как её представляет программист: водитель подъехал к ТРК (топливораздаточной колонке), снял пистолет с ТРК и засунул его в бак, пошёл заплатил, вернулся и нажал "кнопку водителя" (дал команду "старт"), система залила заказанное количество топлива, водитель повесил пистолет на ТРК. Всё - процедура завершена. А как это может выглядеть в жизни ? Водитель нажал кнопку, а топливо не льётся (трубопровод длинный). Нетерпеливый пользователь начинает тыкать в кнопку. Следующее замыкание интерпретируется системой как команда "стоп". Система считает процедуру налива завершённой, но водитель с этим не согласен. Далее следуют разборки. Решение: блокировать опрос состояния кнопки на 20 сек после подачи команды "старт". Если использовать описанную выше кнопку, то для реализации защищённого алгоритма нужен ещё таймер. Но можно добавить к стандартной кнопке свойство "panic_mode" (yes/no) дабы это часто используемое свойство кнопки исполнялось системной библиотекой автоматически. Выход кнопки при этом может дополняться состоянием БЛОКИРОВАНА, а может и не дополняться и выдавать вместо него состояние АКТИВНА. Что ещё можно сказать про кнопки? Кнопка, запускающая процесс, должна срабатывать по отпусканию, а кнопка, останавливающая его, по нажатию. Надо ли дополнять класс свойством "выполняемая функция"? Бывают ещё трёхпроводные системы - отдельно "старт", отдельно "стоп". Или это уже свойства объекта "начало_работы" ? Бывают кнопки с фиксацией... Как-то так.
Это я, здравствуйте. http://the-epic-file.com/bookshelf.htm