Просмотреть полную версию : Управление входом с модбаса в программе
Заказчик просит реализовать следующее в модбасе:
Еще замечание по управлению насосами.
Рекомендуем сделать две различные ячейки на пуск и останов насоса.
Команду будет выполняться по факту записи значения 1.
Сброс этой единицы делать после выполнения команды.
То есть в этих ячейках при правильном функционировании всегда будет 0.
Итого на 2 насоса надо 4 ячейки команд: 2-пуск, 2-стоп.
я понимаю что это в лоджике невозможно?
Заказчик просит реализовать следующее в модбасе:
Еще замечание по управлению насосами.
Рекомендуем сделать две различные ячейки на пуск и останов насоса.
Команду будет выполняться по факту записи значения 1.
Сброс этой единицы делать после выполнения команды.
То есть в этих ячейках при правильном функционировании всегда будет 0.
Итого на 2 насоса надо 4 ячейки команд: 2-пуск, 2-стоп.
я понимаю что это в лоджике невозможно?
"Сброс этой единицы" должна выполнять программа на лоджике? Если так, то невозможно. Можно поинтересоваться, какова причина такого требования?
.
Я уже писал, вот что просит заказчик:
Еще замечание по управлению насосами.
Рекомендуем сделать две различные ячейки на пуск и останов насоса.
Команду будет выполняться по факту записи значения 1.
Сброс этой единицы делать после выполнения команды.
То есть в этих ячейках при правильном функционировании всегда будет 0.
Итого на 2 насоса надо 4 ячейки команд: 2-пуск, 2-стоп.
т.е на запись единицы по модбасу, я должен отпрабатывать заданную команду и сбрасывать эту единицу в модбасе.
вот что просит заказчик:
Можно поинтересоваться, какова причина такого требования?
От: Гордеев Александр Сергеевич
Отправлено: 10 февраля 2011 г. 9:43
Кому: Зиновьев Василий Александрович
Копия: Ромбах Григорий Яковлевич
Тема: RE: карта с coils
Просто из за такой реализации могут возникнуть проблемы в будущем, неоднозначности. Например пуск был по команде то есть в ячейку записали 1.
Затем сработала защита и насос встал, а в ячейке висит 1, и для запуска надо будет сделать две записи, сначала 0 а потом 1. Ну и наоборот, пустили с кнопки, в ячейке 0 остановить надо опять подать 1 а потом 0.
Будем надеяться, что проблема решаема.
Соответственно Вам надо знать выполнена ли команда пуска или останова. Другими словами знать состояние насоса в текущий момент времени. Посмотрите есть ли в том чем вы управляете регистр состояния насоса (State).
А так получается неопределенность - любому сочетанию входных переменных соответствует любое состояние насоса если не учитывать предыдущее состояние насоса и входов.
Встречается еще вариант: записываем значение в ячейку памяти функцией 06 например по адресу 40009 (рабочая директива), при чтении этого регистра функцией 03 выдается совсем другое значение - рабочее состояние.
В любом случае без знания текущего состояния управляемого устройства
задачу не решить.
Лично я для контроля за состоянием насоса использую регистр состояния (INTEGER):
0 - авария
1 - стоп
2 - резерв
3 - проверка срабатывания
4 - вкл (принудительно)
5 - автомат
6 -
7 - ручной
8 -
От: Гордеев Александр Сергеевич
Отправлено: 10 февраля 2011 г. 9:43
Кому: Зиновьев Василий Александрович
Копия: Ромбах Григорий Яковлевич
Тема: RE: карта с coils
Просто из за такой реализации могут возникнуть проблемы в будущем, неоднозначности. Например пуск был по команде то есть в ячейку записали 1.
Затем сработала защита и насос встал, а в ячейке висит 1, и для запуска надо будет сделать две записи, сначала 0 а потом 1. Ну и наоборот, пустили с кнопки, в ячейке 0 остановить надо опять подать 1 а потом 0.
Будем надеяться, что проблема решаема.
Не вижу проблемы. Проекты Конструктора автоматически перезапускаются при наличии единицы на переменной "Пуск" до тех пор, пока туда не будет записан ноль. А состояние ВУ (запущена/остановлена) благополучно читается из специальной переменной в любой момент времени.
Соответственно, что вам мешает сделать также? Запись одна? Одна. Чтение одно? Одно. Сложность программирования верхнего уровня не изменяется ни на байт.
И что касается систем диспетчеризации - там проблемы обратных связей решены на корню. И не важно, обратная связь осуществляется по той же переменной или по какой другой.
PS. Кстати, у вашего заказчика тогда большие проблемы с общением с любыми частотниками - в них контроль запуска осуществляется НЕ по управляющему слову, а по слову состояния. Мне кажется будет эффективнее несколько поднять уровень знаний заказчика, чем ложиться под каждое его надуманное требование.
.
Не вижу проблемы. Проекты Конструктора автоматически перезапускаются при наличии единицы на переменной "Пуск" до тех пор, пока туда не будет записан ноль. А состояние ВУ (запущена/остановлена) благополучно читается из специальной переменной в любой момент времени.
Соответственно, что вам мешает сделать также? Запись одна? Одна. Чтение одно? Одно. Сложность программирования верхнего уровня не изменяется ни на байт.
И что касается систем диспетчеризации - там проблемы обратных связей решены на корню. И не важно, обратная связь осуществляется по той же переменной или по какой другой.
PS. Кстати, у вашего заказчика тогда большие проблемы с общением с любыми частотниками - в них контроль запуска осуществляется НЕ по управляющему слову, а по слову состояния. Мне кажется будет эффективнее несколько поднять уровень знаний заказчика, чем ложиться под каждое его надуманное требование.
.
Не понял про конструктор, чего там перезапускается :).
Такой вариант чтением битов состояний, однозначно идентифицирующий объект управления и предлагается с моей стороны.
Не понял про конструктор, чего там перезапускается :).
В общем - в Конструкторе сделано именно так, как не хочет ваш заказчик и всё работает без проблем и не вызывает никаких нареканий.
В преобразователях частоты сделано аналогично. Из этого следует только один вывод - зак ошибается.
.
vBulletin v3.8.3 (Russian), Copyright ©2000-2024, Jelsoft Enterprises Ltd.