Таймер для массива данных.

Здравствуйте!
Каким образом возможно организовать обработку таймера в массиве. Т.е. у меня имеется к примеру 15 задвижек, я в массиве обрабатываю входы, выходы, состояния, если обрабатываю теги по одной задвижке все понятно, как только создаю обработку массива, естественно все "плывет", как использовать таймеры для обработки с каждой задвижкой. До этого с Бредли работал, как то по другому все проходило.) Контроллер 300.

Таймер.png

Сообщение **UNTK_RAA** » 24 дек 2019, 12:27

На каждую отдельную задвижку должен быть отдельный таймер.

В интерфейсе FB надо создать переменную с типом SFB4. Это таймер TON.

UNTK_RAA писал(а): ↑24 дек 2019, 12:27 На каждую отдельную задвижку должен быть отдельный таймер.

В интерфейсе FB надо создать переменную с типом SFB4. Это таймер TON.

Неужели нет других способов организации подобной задачи....((( Это ведь стандартная ситуация, когда на объекте большое количество однотипных устройств.
Неужели при 100 одинаковых задвижках придется городить такую тонну скопированного кода.... это ведь не удобно.

Отправлено спустя 9 минут 24 секунды:
В Бредли думаю тоже самое ))) как то через реальное время контроллера возможно....

Отправлено спустя 12 минут :
Если не говорить о задвижке, предположим есть входы DI, 64 штуки, на каждый из них подается некий сигнал, после поступления сигнала необходимо осуществить задержку предположим в 2 секунды, после чего уже будет "взведен" тег в алгоритме.
Придется использовать 64 таймера??? Да это сумасшествие какое то.

Отправлено спустя 4 минуты :
Можно ведь просто проиндексировать DI, DI[#index], где индекс равен от 0 до 64.

Сообщение **v0v** » 09 янв 2020, 23:55

Вы один раз напишите код FB и будете вставлять его с разными входами и выходами. В каждом вставленном блоке свой DB в котором как написал коллега UNTK_RAA будет SFB4 таймер со своим DB.

v0v писал(а): ↑09 янв 2020, 23:55 Вы один раз напишите код FB и будете вставлять его с разными входами и выходами. В каждом вставленном блоке свой DB в котором как написал коллега UNTK_RAA будет SFB4 таймер со своим DB.

Да, спасибо я понял, создал один FB и втыкай где надо, как только вставляешь создается DB, но если внутри "универсального" FB обойтись без таймера...

Существует функция SFC64 "TIME_TCK" Вот что вычитал "Можно использовать системное время, например, для того, чтобы измерять длительность процессов путем сравнения результатов двух вызовов SFC 64 и тем самым убедится что Ваш процесс укладывается в нормативы рассчитанные вами"

Только вот не понимаю как это реализовать....

Идея в том чтобы создать один FB для обработки всех задвижек. Как пример у меня реализована обработка аналоговых сигналов, тем самым при расширении площадки мне не придется заниматься "долгой" доработкой проекта, да и в данный момент я обрабатываю все аналоговые каналы, даже пустые, АСУшники в последующем смогут подключить оборудование к свободному каналу, и достаточно будет например заменить в логике работы резервуара AI[1] на AI[12] если будет установлен дополнительный датчик, вариаций много. При должной пояснении в руководстве, данная работа не будет вызывать у сотрудников паники).

Сообщение **v0v** » 10 янв 2020, 07:00

Может вы не совсем поняли. Таймер в FB тоже один будет.

Сообщение **winb** » 10 янв 2020, 08:54

Если сильно хочется поработать с массивами, то можно сделать так:
1. Определить пользовательский тип (пусть будет ITIMER), в котором будут содержаться элементы интерфейса используемого IEC таймера (например, SFB4). В этом типе могут быть поля IN:BOOL, PT:TIME, Q:BOOL, ET:TIME, в соответствии с интерфейсом блока таймера.
2. В вашем функциональном блоке сделать массив типа ITIMER необходимого размера, сколько нужно таймеров, такой и размер. Пример: timers: ARRAY [0..9] of ITIMER
3. В начале функционального блока организовать вызов нужного количества блоков таймеров, привязать к интерфейсу массива timers.
4. В ходе выполнения программы работать с массивом timers.
Пример:

Снимок.PNG

Снимок2.PNG

Сообщение **aranea** » 10 янв 2020, 11:17

KorgathVarvar, это ваша первая программа на промышленном ПЛК? имеется опыт наладки программного обеспечения? судя по стремлению к циклам и массивам, вы уже знакомы с каким-то высокоуровневым языком программирования?
знакомы с ООП? тогда что может быть логичнее чем FB (класс/тип) и DB (экземпляр/объект)? причем количество экземпляров логично что будет совпадать с количеством реальных объектов (задвижек)
да хоть тысячи их, задвижка, допустим, довольно простой механизм, а как в цикле отлаживать логику работы отдельно-взятого механизма посложнее? визуально оценить все его входы и выходы, отследить внутреннюю логику при возникновении проблемы?
в офисе можно что угодно и как угодно написать для сферически-вакуумного оборудования, но в поле, при наладке, при поиске проблем и устранении причины простоев - эти циклы аукнутся
опять же данные для верхнего уровня как брать из кучи? а если добавить/удалить, сместить адресацию?
гнать такой подход при помощи несвежего веника
весь МЭК 61131-3 нацелен на простоту, понятность и прозрачность

aranea писал(а): ↑10 янв 2020, 11:17 KorgathVarvar, это ваша первая программа на промышленном ПЛК? имеется опыт наладки программного обеспечения? судя по стремлению к циклам и массивам, вы уже знакомы с каким-то высокоуровневым языком программирования?
знакомы с ООП? тогда что может быть логичнее чем FB (класс/тип) и DB (экземпляр/объект)? причем количество экземпляров логично что будет совпадать с количеством реальных объектов (задвижек)
да хоть тысячи их, задвижка, допустим, довольно простой механизм, а как в цикле отлаживать логику работы отдельно-взятого механизма посложнее? визуально оценить все его входы и выходы, отследить внутреннюю логику при возникновении проблемы?
в офисе можно что угодно и как угодно написать для сферически-вакуумного оборудования, но в поле, при наладке, при поиске проблем и устранении причины простоев - эти циклы аукнутся
опять же данные для верхнего уровня как брать из кучи? а если добавить/удалить, сместить адресацию?
гнать такой подход при помощи несвежего веника
весь МЭК 61131-3 нацелен на простоту, понятность и прозрачность

Вы верно подметили, мой опыт в разработке не так велик. Имеется и опыт наладки и доработки проектов различных контроллеров за другими программистами. Имеется небольшой опыт в web и Си

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

Меня именно это и задело))) 100 одинаковых задвижек сиди вставляй FB и каждой входа выхода прикручивай. Более сложные объекты я не трогаю, если это будет некий нагреватель или котел (печь) и их 50 штук, то лучше сделать без массива.

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

Это вопрос следующий.) А вообще мне гораздо проще ориентироваться если это ZD[0] то скорее всего у нее и DI[0],[1] (закрыто\открыто) и DO по той же логике.

Вообще вероятно я саму концепцию своей программы выбрал не верно, надо подумать.

Отправлено спустя 7 минут 27 секунд:
:thankyou:

winb писал(а): ↑10 янв 2020, 08:54 Если сильно хочется поработать с массивами, то можно сделать так:
1. Определить пользовательский тип (пусть будет ITIMER), в котором будут содержаться элементы интерфейса используемого IEC таймера (например, SFB4). В этом типе могут быть поля IN:BOOL, PT:TIME, Q:BOOL, ET:TIME, в соответствии с интерфейсом блока таймера.
2. В вашем функциональном блоке сделать массив типа ITIMER необходимого размера, сколько нужно таймеров, такой и размер. Пример: timers: ARRAY [0..9] of ITIMER
3. В начале функционального блока организовать вызов нужного количества блоков таймеров, привязать к интерфейсу массива timers.
4. В ходе выполнения программы работать с массивом timers.
Пример:
Снимок.PNG
Снимок2.PNG

Вы подтолкнули меня в нужную сторону.