S7-300 для управления мнемосхемой

[volotovskyd]

Здравствуйте.
Помогите новичку. Начитался книжек по S7 для того, чтобы реализовать тему, но в процессе написания программы столкнулся с тем, что все получается громоздко. Решил тормознуть и задать вопрос знающим. Задача следующая:
1) Есть S7-300 с DI (32 канала) - 5шт и DI (32 канала) - 5шт.
2) Нужно написать программу для управления мнемосхемой (большим количеством лампочек) работы технологического оборудования. Т.е. мне нужно опросить входы, на которые пришли сигналы о работе или остановке оборудования и выдать по соответствующим выходам сигналы на лампочки и звуковую сигнализацию. Дополнительно в схеме присутствуют кнопки проверки ламп и квитирования сигнализации.

Я так понимаю, что нужно написать скорее всего функциональный блок обработки сигнала с одного входного канала, а потом его "подсунуть" для всех каналов. Но я пока не нашел как это сделать, не расплодив полторы сотни вызовов данного блока в ОВ1. Тянет в сторону косвенной адресации и создания в глобальном DB структуры, описывающей каждый канал (взаимосвязь вход/выход, состояние каждого канала, возможно временные задержки срабатывания и еще что-то). Направьте меня в нужном направлении, плиз. Куда копать?

Еще, если я правильно понял, косвенную адресацию нельзя сделать в LAD или FBD, а только в STL. Хотелось бы обойтись только LAD и FBD, т.к. потом эту программу могут ковырять после меня люди далекие от STL или ассемблера. Опыт в ассемблере имеется для PIC, правда подрастраченный.

Заранее спасибо всем откликнувшимся.

[CoMod]

Если есть типовые случаи включения Индикаторов при Вх1+Вх2+... то можно и функциональный блок сделать, а на его входы подавать комбинацию входов.
А если у каждой лампы уникальный набор условий, то рисовать ветку для каждой лампочки.

[panf]

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

[volotovskyd]

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

Если не сложно, сбросьте проект посмотреть.

[volotovskyd]

В проекте будет два типа каналов: аварийный и позиционный. Для аварийного канала логика работы следующая: лампа не горит - параметр в норме; лампа заморгала - параметр не в норме; кнопка квитирования аварийной сигнализации переводит лампу в режим горения ровным светом и при пропадании аварийного сигнала на входе лампа тухнет. Логика работы канала позиционной сигнализации: лампа горит - параметр в норме; позиция остановилась - лампа заморгала; кнопка квитирования позиционной сигнализации гасит лампу. Кроме этого есть два отдельных звуковых сигнала на случай срабатывания аварийного канала и позиционного канала и отдельные кнопки проверки ламп и звуковых сигналов для каждого типа сигнализации.

Короче говоря речь идет о двух схемах работы, которые в LAD нарисовал без проблем, но плодить данные блоки для каждой пары вход/выход не хочу.

[almaz78]

то есть один вход контролирует один выход?
или все же комбиназия входов контролирует один выход?

[volotovskyd]

то есть один вход контролирует один выход?
или все же комбиназия входов контролирует один выход?

Один вход - один выход.
Но в схеме еще на входах присутствуют по паре кнопок для проверки и сброса сигнализации, и 2 выхода для двух звонков.

[almaz78]

Ну тогда все не так страшно. Читайте DI и пишите в DO как DWORD.
Исползуйте nested fb. То есть исползуйте три уровня fb: 1 уровень на входе dword из этого fb вызывайте 4 блока 2го уровня у которых на входе будет Byte . А из из блока второго уровня вызывайте 8 блоков первого простейшего уровня у которого на входе будет BIT

В конечном итоге в ob1 у вас будет 5 блоков.

[CoMod]

Один вход - один выход.
Но в схеме еще на входах присутствуют по паре кнопок для проверки и сброса сигнализации, и 2 выхода для двух звонков.

Покажи ветку... если ветки такие простые, то нет смысла плодить блоки, так как выгоды от этого нет никакой.
Тут может выгодней подумать над именами тэгов, чтобы копировать ветку и в новой ветке менять имена поиском и заменой_001_на_011.
Я так делаю для разных механизмов, при этом есть возможность что то изменить в конкретной ветке для конкретного механизма.
Тебе ведь нужна простая тупая наглядная логика ? Или нужен шедевр алгоритмической оптимизации через заднеприводное неявное индексирование, которое буде понятно только тебе ?

[almaz78]

CoMod я с вами полностью согласен насчет косвенной адресации, но насчет блоков нет.
я думаю гораздо выгоднее исползовать блоки. Они и созданы для того чтобы не копировать повторющийся код.
Если не тсользовать блоки тогда как минимум будет 160 веток. Если потом придется изменить что то в логике то это потребует изменения 160 веток. При использовании блоков изменение займет минуты

[CoMod]

Они и созданы для того чтобы не копировать повторющийся код.
Если не использовать блоки тогда как минимум будет 160 веток.
Если потом придется изменить что то в логике то это потребует изменения 160 веток.
При использовании блоков изменение займет минуты

Механики и гидравлики создают мне проблемы и казалось бы одинаковые механизмы имеют много необщего... нетиповые неповторяющиеся схемы на уровне НИОКР.
На пусконаладке времени немного... окна...или ночью... иногда легче и нагляднее что то изменить в одной из "160 веток", чем пытаться сделать универсальный блок для всех "160" не совсем идентичных устройств.
Иногда конкретно один механизм из нескольких синхронизируемых ведёт себя не так как все из-за механических или гидравлических проблем ... при использовании одного блока для всех механизмов очень не наглядно оперативно понять и указать смежникам где возникает проблема... смежники первым делом винят Программиста...
А вот если целая функция посвящена именно этому механизму, то можно сразу увидеть самому и показать смежникам в какой ветке возникла проблема с частотниками, энкодерами, регулируемыми гидрораспределителями и кучей датчиков. Конкретно в функции для этого механизма временно добавляешь условия проверки возникновения неявных событий с помощью триггеров и фронтов со счётчиками... и прочими алгоритмами, в том числе для вывода дополнительных данных и графиков на экран. Из личного опыта - сразу оперативно показывал и нашим и интуристам, что проблема в их конкретном устройстве гидравлики/механики, а не в моей программе, указывая на 2 онлайн окна- видишь у этого механизма вся ветка зелёная... а у этого ветка тут обрывается...
Когда всё отлажено, то в принципе можно сделать оптимизированный для всех механизмов блок... но это опять новая пуско-наладка... и так работает... зачем создавать новые проблемы на пустом месте.
Без конкретики трудно рекомендовать конкретное решение.
Учебник по созданию функциональных блоков https://yadi.sk/d/LUHX8gGs32pwKQ
документация https://yadi.sk/d/zrQzGvwqvgqgF

[almaz78]

CoMod,

я с вами полностью согласен в случае с неодинаковими механизмами. но здесь 160 идентичных! на мои взгляд ето идеалниы проект для блоков.
если в таких ситуациях не исползовать блоки то тогда в каких проектах стоит их использовать?

[Dfcz]

Здравствуйте.
....Я так понимаю, что нужно написать скорее всего функциональный блок обработки сигнала с одного входного канала, а потом его "подсунуть" для всех каналов. Но я пока не нашел как это сделать, не расплодив полторы сотни вызовов данного блока в ОВ1. Тянет в сторону косвенной адресации и создания в глобальном DB структуры, описывающей каждый канал (взаимосвязь вход/выход, состояние каждого канала, возможно временные задержки срабатывания и еще что-то). Направьте меня в нужном направлении, плиз. Куда копать?

Еще, если я правильно понял, косвенную адресацию нельзя сделать в LAD или FBD, а только в STL. Хотелось бы обойтись только LAD и FBD, ...

Я делал (надо искать - давно это было) так: писал один блок, один из параметров которого менялся по времени, т.е. перебирал входы и выходы.
Таким образом обрабатвал значения -цати аналоговых датчиков и передавал значения в панель оператора.
Для оператора время не критично и перебирал по таймеру (просто по таймеру).
В другом случае, когда эти значения нужны для работы исп.механизмов, обрабатывал в блоке прерывания (типа ОВ35 и пр.).
В ЛАДе не пробовал, но думаю тоже будет работать.
Никакой косвенной адресации, прямочки по входам чесал.