ПО Fbd для пр110

[rovki]

здесь две задачи.первая обнаружение -что два выхода "хотят" установится в положение "on" -это один элемент "и", и вторая задача -это блокирование
двух заказанных выходов ( это еще два элемента"и" )-первым элементом
элементом "и" через инверсию.ух,давно не приходилось описывать принц.схему словами.т.е ,какие бы комбинации входных сигналов не происходили,по тем или иным причинам, которые бы могли привести к одновременному включению двух заказанных выходов программно эти ситуации выявляются и блокируют(не включают) оба выхода и сигнализируют об этом.Таким образом анализ ведется не входов ,а выходов.Лучше заблокировать
выходы и известить об этом ,чем потом менять какое- нибудь реверсивное твердотельное реле (по причине К.З.) по цене 2-3 раза дороже чем ПР110.

[rovki]

в развитие предыдущей темы ,хорошо бы иметь блок функциональной диагностики-это симбиоз архиватора и пкл.только архиватор будет сохранять не входные потоки информации,а результаты анализа(аварийные ситуации) ,анализ этих ситуаций должен производить пкл или что то подобное с набором необходимых функций.не всегда есть возможность и необходимость иметь оператора,а если он есть ,то это упростит ему задачу анализа аварийных ситуаций,что сократит время поиска неисправности, и придаст системе управления большею живучесть.

[Дмитрий]

в развитие предыдущей темы ,хорошо бы иметь блок функциональной диагностики-это симбиоз архиватора и пкл.только архиватор будет сохранять не входные потоки информации,а результаты анализа(аварийные ситуации) ,анализ этих ситуаций должен производить пкл или что то подобное с набором необходимых функций.не всегда есть возможность и необходимость иметь оператора,а если он есть ,то это упростит ему задачу анализа аварийных ситуаций,что сократит время поиска неисправности, и придаст системе управления большею живучесть.

ну наворотили из обычного программированого реле монстра и главное в эксплуатации простых и насущных задач это нав ряд-ли пригодиться, акцент нужен на надёжногсть и простоту программирования, а если для каждого элемента в ФБ нужно будет писать его правила, будет бардак и вакханалия в простом деле написания логических схем.

[rovki]

а речь не шла о пр110,я предлогаю новый блок.и кому нужно реализовать
децентрализованную функцианальную диагностику тот и купит.согласен что не нужно ,а точнее порой не возможно реализовать на простых устройствах ввода -вывода,данную задачу (верхнего уровня).но для диспечерских задач иметь прописанный сценарий действий в нештатных
ситуациях-не плохо.

[rovki]

есть много простых но очень ответственных задач.и выход из строя копеечного датчика (например температуры) может привести к потере многих тысяч рублей.не надо все к сантехнике(жкх) сводить ,есть и технологические процессы которыми надо управлять,хотя и в сантехнике последствия могут быть ощутимыми.

[Филоненко Владислав]

можно или не реализован? - как ни странно оба ответа...
в реле уже реализован, а в среде программирования еще нет.
а маска в данном случае - запрещение использования поля в сравнении времени - запретили месяцы - каждый месяц включение/выключение, к примеру.

[Филоненко Владислав]

здесь две задачи.первая обнаружение -что два выхода "хотят" установится в положение "on" -это один элемент "и", и вторая задача -это блокирование
двух заказанных выходов ( это еще два элемента"и" )-первым элементом
элементом "и" через инверсию.ух,давно не приходилось описывать принц.схему словами.т.е ,какие бы комбинации входных сигналов не происходили,по тем или иным причинам, которые бы могли привести к одновременному включению двух заказанных выходов программно эти ситуации выявляются и блокируют(не включают) оба выхода и сигнализируют об этом.Таким образом анализ ведется не входов ,а выходов.Лучше заблокировать
выходы и известить об этом ,чем потом менять какое- нибудь реверсивное твердотельное реле (по причине К.З.) по цене 2-3 раза дороже чем ПР110.

Зачем что-то там контролировать, когда простая схема из 1 НЕ гарантирует, что 2 выхода никогда не будут иметь одинаковое состояние?

[rovki]

я,уже и не знаю как еще обьяснить,я вам про Фому ,а вы мне про Ерему, я не говорил что нужно исключать одинаковые состояния ,я говорил,обьяснял,рисовал ,что нужно исключать
два включеных(активных,on) выхода,и для этого нужно 4 элемента.но дело
не в количестве элементов,если вам специалисту приходится обьяснять ,что такое блокировка выходов,то как быть начинающему пользователю,который при реализации алгоритма исходит из того ,что у него все работает,что кто-то нажмет две кнопки вперед-назад одновременно(я утрирую) или что неисправность концевиков или датчиков, даст команду на обогрев и охлаждение одновременно,и.т.д. и.т.п,десятки примеров.особенно при наличии в алгоритме счетчиков,таймеров,упустить этот момент очень легко.это приходит с опытом.а когда человек увидит в свойствах выходов возможность блокировки выходов,он задумается для чего это .у него появится осознанный выбор использовать это или реализовать самому "предупрежден-значит вооружен ".на этом заканчиваю давать свои ,ни кому не нужные, предложения и за бесплатно читать лекции ,жаль что не нашел в лице овен единомышленников .честь имею, каблов анатолий геннадьевич.
P.S специалисты в одной области должны понимать друг друга с полу слова и аргументировано отстаивать свои позиции,а не играть в игру Глухой-Слепой.

[Евстигнеев Максим]

Уважаемый rovki,
спасибо за Ваши пожелания, которые мы обязательно рассмотрим.

[rovki]

блокировка выходов нужна в следующих случаях-
отказов входных цепей или их нештатного срабатывания.
ошибках в алгоритме (логики работы).
неправильном монтаже.
и еще ,мало заблокировать выходы,надо сигнализировать об этом тем или иным способом,но желательно без использования штатных выходов(их и так мало).все это не потребует дополнительного железа,реализация программная .затраты будут разовые (программирование) а результатами будем пользоваться всегда.последнее -"хвост" ни когда не станет "головой" если только копировать как сделано у других.дерзайте и удача придет к вам.










.