GYUR22 не, не, не. я и не говорил про Си на весь контроллер для продажи. Меня бы вполне устроил и FBD но чтобы эти FBD (так называемые макросы) можно было писать на Си и как раз тут можно было бы реализовать и макросы стеков и что-то еще.
Опять же, если это STM-ка какая нибудь, возможность просто стереть прошивку с языком FBD и наваять все в среде разработки для STM, так сказать на свой страх и риск для хардкорщиков...
Но вот для FBD если делать, то было бы достаточно добавить массивы, возможность обращаться к битам переменных через . (точку) и сделать возможность переходов по меткам. Этого было бы за глаза для очень многих задач вместе с возможностью писать FBD на Си.
Тот же опрос какого-нибудь прибора через RS485 с отличным от Modbus протокола...

счетчики Меркурий те же, или регистраторы Пульсар или их счетчики или вон весы какие-нибудь. То есть режимы должны быть как RTU так и ASCII доступны.

ИМХО
Наоборот, паковать битики аварий очень хорошая мысль.

1.При передаче по Модбас к примеру 16-аварий запакованные в битики это всего один запрос,
Значит уменьшается нагрузка на сеть.

2. Многие СКАДы лицензируются по количеству точек.
Так что еще уменьшение точек-удешевление СКАДы

Обычно в ФБД есть возможность группировать блоки в свой макрос, но писать свои блоки это то только для компиляторов (codesys?), и то можно где нито подорваться улетев за границу итп.
Я лично не против своих блоков, но лично мне для относительно простых систем хватает 20-24 типа блоков - и я не вижу сильной необходимости в применении большего количества типов.
По поводу битов - выделить бит обычно можно в любом ФБД.
Массивы я не знаю зачем они нужны в ОВКВ.
Опрос странных протоколов - это можно отдать на откуп верхнему уровню или шлюзу и опять таки - нестандартные протоколы это плохие практики и их все меньше, за исключением конечно особо упоротых случаев.
Переход по метке нужен в текстовом языке - в ФБД ветвление делается обычно другими способами.
И про время на написание прошивки на ЯВУ (Си, Си++ и прочие Паскали ) без шаблона производителя- если это что то особо простое, без протоколов обмена, проверок и прочая маргинальщина то да конечно. Но если что то серьезное и на один раз то только за взрослые деньги не сравнимые со стоимостью контроллера.
А сейчас железо можно найти очень недорогое, а люди еще не особо понимают что за личные хотелки надо платить.

Расстрою вас. В modbus 16 битов в виде битов занимает ровно столько же байтов, сколько эти биты занимают в байтах. И передаются точно также за один запрос.

Или вы хотели, чтобы протокол полувековой давности передавал бит в виде текстовой посылки "За сим повелеваю бит нумер 42 установить в басурманское положение true"?)

За все надо платить - надо сначала запаковать, потом распаковать, но я не говорю, что если это плохая практика ее нельзя применять - ее надо избегать.
Нам например с этим не очень удобно работать т.к. мы не можем в одной точке ее разобрать если она пришла в BACnet, а писать под каждую такую точку Control System и там разбирать, особенно если их несколько, это не очень приятно.
Обычно кодированием битиков страдают производители контроллеров типа evco, danfoss и прочей преконфигурятины т.к. им надо засунуть побольше.
Я так делать не буду т.к. понимаю что потом пострадаю на верхнем уровне - все просто.
А по поводу количества точек - надо выбирать по размеру и тогда все будет хорошо, а не пытаться запихать незапихуемое.

Вот таки да! Для Меркурия бы реализацию в комплект включить.
Повторюсь, FBD с возможностью написания блоков на ST - вполне жизнеспособный комплект.

А 16 битов в виде слова из двух байтов - занимает ровно в 16 раз меньше при передаче ))

GYUR22 я говорю о возможности работать с битами не превращая холст программы в мусорку из FBD для работы с ними. Как в ОЛ например путбит, ехтрактбит. Эти FBD нужны, так как можно строить различную логику, но иногда биты требуются для других задач. Та же паковка для аварий. И вместо свалки булевых переменных имеем всего несколько 16-ти битных.
Alarm в котором Alarm.0 ----- Alarm.15 это различные алярмы в программе, которые можно без всяких FBD вот так вот использовать в программе, а потом Alarm - отправить в Scada.

Массивы нужны для реализаций разных алгоритмов работы программы, а не конкретно в ОВКВ или где-то еще

з.ы. вы просто не представляете, сколько приходится городить огородов, когда на каждую зверушку приходится покупать шлюзы.
А так, есть у вас установка, которая висит на своем счетчике предположим, вы ставите контроллер, который обслуживает ее работу, снимает показания счетчика ЗАОДНО и отправляет это все на верхний уровень.
Переход по меткам нужен и в FBD для организации шагов алгоритма без применений огорода из всякого рода наборов FBD, типа AND? SEL и так далее, меньше квадратиков на холсте, легче читать программу, меньше ненужных квадратиков.
И маленький нюанс, как бы вы ни сделали ветвление на FBD, все они ВЫПОЛНЯЮТСЯ, и тратят время цикла. с метками, можно пропускать чать выполнения кода.

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

Вот в этом я поддержу manjey73
Реализовать "автомат состояний" на Си намного проще и читабельнее чем на FBD
Так что иметь возможность написать свой FBD блок на том же Си это очень полезная функция.
Да много программ поддерживают написание FBD блоков на FBD,
но это не совсем то.

По очереди:
1.В BACnet все очень просто все перменные имеют имя и описание в теле - все эти 16 битные что с ними делать? Гораздо приятнее когда у вас система Self Ducumented - и не надо лезть за каждым битом (хотя конечно не всегда так). И в результате получаем кучу нечитаемых 16 битных аварий которые всем лень расшифровывать т.к. это стоит денег - некрасиво короче.
2. Зачем счетчик в контроллер - у них обычно своя сеть?
3. За 18 лет работы не помню чтобы хотел массивы.
4. А зачем нужны зверушки со своими протоколами - они вроде как почти все вымерли?
5. Вам сколько надо времени цикла? Мне достаточно - 1 секунды, меньше зачем нужно можете объяснить, что там экономить?

Сенсорные панели обычно не умеют выполнять груповые запросы,
а вот с "упакованными битами работать умеют.

Проиллюстрирую богомерзкие упакованные биты и код ошибки

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

Вы оптимист :-) в холодоснабжении их миллионы (в каждой витрине, прилавке и т.д.)
это они

а еще Eliwell, Dixel и еще много разных.
Хотя уже наметилась тенденция с переходом многих из них на Modbus

1.У нас нету рецептов это другая индустрия - я даже смутно представляю что это, шлюзы обычно конфигурируются точка-точка и все спец функции обычно за бортом.
2. У каждого своя специфика - я ж говорю про ОВКВ а не про промхолод- там да свой чудесный мир со своими жЫрными тараканами (пару раз пересекался
3. Тут я да наверное оптимист мы в основном с большими более менее железяками работаем - прилавками не занимались, но сейчас чаще дешевле поставить новую железку чем насиловать старую

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

На примере как раз очень похоже на "НЕупакованные биты"


вот пример специфического шлюза

1.Есть приоритет
2. Нет упакованные биты это как раз они - двоичные веса 1-2-4-8-16-32-64-128 итд - и их как раз надо распаковывать сдвигать и мэпить на другие переменные

Да это скорее промышленность
Упрощенно "рецепт" это набор уставок(параметров)
в АВОК можно использовать для чего-то типа "умного дома"
в умном доме сценарий-это синоним рецепта в промышленности


Скорее коммерческий чем пром.

Ну "железки" там тоже большие :-)
не дешевле
там все специфическое, контроллер по цене 10-30уе, датчики по 2уе :-)
И в нагрузку" верхний уровень" от производителя за 500мильйонов :-)

Ну хоть на чем то они должны зарабатывать ?

Но все равно на экране будет только код одной аварии

Не понял. Честно. А не проще сделать AND c маской?
Для прмера вот упакованные биты

Очень приятная тусовка. Волею судеб, наблюдаю в прямом эфире эволюцию программописания на примере Carel

1. Стиль FBD сохранился, 90% новых макроблоков написано на ST. Пользователю предлагается выбор при создании макроблока - FBD или ST.

2. Написание графического интерфейса - чистый ST, c.suite.

Субьективно, легче читаются программы FBD, макроблоки для блоков FBD легче писать на ST.


И да, массивы повсеместно, c.suite. А Carel никуда особенно от климата не ушел.

Может быть, новая волна программистов в штате.

Как по мне одна из лучших программ.
Очень дружелюбно к пользователю, отличная справка по блокам.

Особенно хорошо использование нескольких страниц (намного удобнее чем все на одном листе)


Ну да старые "пилят" MCXDesign для Данфосса

Да, пилят. Успехов им. Как по мне, прорыв у Карел где то с 2010-2012. Принципиальный.


И да, Carel ушел от пакования в INT. Пою, что вижу.

16 битов занимают ровно два байта при передаче. Вам тоже стоит почитать описание протокола, прежде чем ржать.



В modbus невозможно выполнить негрупповой запрос на чтение. В нём таких просто нет. Единичная только запись бывает.

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

насколько понимаю синтаксис это и есть биты только номера
Вес:
0 бит =1
1 бит =2
2 бит =4
...

Раньше, где-то с конца 2008г
В связи с переходом на 1tool и серию рСО3



Тогда да, мы об одном и том же.
Только я не понимаю зачем их сдвигать?
как по мне проще AND с маской (1, 2, 4, и т.д) и проверка на больше 0
меньше "телодвижений" вроде бы.



Я знаю и всегда стараюсь использовать именно групповые запросы
даже если мне половина регистров не нужна.
так менььше нагрузка на сеть.
Только не все оборудование так умеет :-)

Как говорится что есть с тем и работаем.
На самом деле мне все равно упакованы или не упакованы биты.

Но если вернутся к обсуждению то
в дополнение к FBD очень хочется возможность написания FBD блоков на Си или любом другом языке.
Иногда реализация на Си более очевидна и "читаема" чем кучка FBD
особенно если среда разработки FBD "корявая"

"Раньше, где-то с конца 2008г
В связи с переходом на 1tool и серию рСО3"

Не, позжее. Знаком с некоторыми. Философия поменялась. Да и эти и эти уходят. Жаль.

Сейчас 1Tool не в моде. Хотя, Израиль, очень даже.Для оборонки все эти Эзернеты новомодные не пройдут, в отличие от.

По факту, продвижение BLDC компрессоров в сферу климата, цена пока конская, но время покажет.

Обещал скинуть инфу по ПЛК, который разработали.
Что нашел на ПК - позже могу и фото, если интересно, конечно.

Почем бы купили в качестве модуля ввода вывода на МодБас? Это часть ПО уже реализована...

И выкладываю скрин экрана (это для ПЛК) - он цветной даже )))

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

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

А вот второй экран как раз и должен содержать мнемосхему (как у Вас
и такой же уже выкладывал Космос440)
Причем доступ к нему желателен не через меню, а по нажатию одной кнопки (обычно стрелки)
Он как раз очень удобен для наладки.
А доступ по нажаьтю одной кнопки из-за автовозврата в основной экран (обычно это есть у всех контроллеров, автовозврат всмысле).
Т.к при наладке придется часто на него смотреть, и доступа к нему через меню
при автовозврате будет "раздражать"

ПС все сугубо мое мнение.

Выкладывайте обмен опытом весьма интересен

Ashihara попробуйте опросить групповым запросом ПЛК63/73 по штатным адресам переменных, обхохочетесь...

Fanat у меня несколько вопросов 1 - цена вашего чуда? 2 - возможность получить на тестирование? 3 - возможность прошить другой прошивкой, не в качестве модуля в/в ? ну и полные характеристики ?

1 секунда цикл ? да вы батенька извращенец... меня Кареловские 320 мс фильтра по входам убили наповал. Нажимаешь на щите кнопку, а ее еще и держать надо, чтобы эта сволочь подумала, что я не ошибаюсь и действительно кнопку нажал...

Не это не недостаток,
это такая "фишка"
зато Вам в программе не надо "антидребезг" делать :-)

ПС это шутка.

так эту фишку у других можно вк/вЫкл или настроить, а тут полный ПС...
Или как люди гордятся 100 мс циклом и ниже ну никак ?

У меня только один вопрос к таким - НАПУРКУА ?

Да не нужно в климате микросекунды считать. Еще и программные задержки стоят на события везде. Специфика.

У вас просто задачи другие.

svintus просто кроме датчиков, где нужна фильтрация, есть кнопки на дверце шкафа, где она вредна.
То же относится и к циклу программы. А производители почему-то этого не учитывают

Так то оно так, но это другой запрос. Если имеется 10 регистров и 10 коилов, то придется выполнить два запроса, один к регистрам, другой к коилам, а между ними еще и промежуток минимум в 0.1с. Хотя если мастер не может сформировать запрос на чтение к нескольким регистрам одновременно, это не актуально.

А вообще, для мастера это не тривиальная задача, понять что надо опросить несколько регистров за раз. Особенно если заданы диапазоны регистров с промежутками.

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

Не все забывают. Используются разные задержки для входов, сконфигурированных как аналоговые и как дискретные. Здесь для аналоговых фильтр по умолчанию 0.5с, для дискретных 0.1с.
Но только подобный фильтр для кнопок на щите не поможет. Если, например, время опроса модуля входов-выходов по линии Modbus 1с, чтобы гарантированно прошло нажатие кнопки, необходимо жать ее не менее 1 с. Поэтому имеется специальный тип входа - "кнопка НО/НЗ/контр.линии". При нажатии срабатывает сразу, по отжатию, если прошло времени меньше чем указано в настройке "Мин.время нажатия кнопки", будет сохранять состояние "нажато" в течении этого времени. Последний тип "кнопка с контролем линии" это кнопка с концевыми резисторами, позволяет определять состояния замкнуто - разомкнуто - обрыв линии - КЗ линии.



Модуль входов-выходов ModIO-230

Не мамонты еще живы :-)
Есть еще старые кадры....
Так что лампочки и кнопочки еще сопротивляются...

GYUR22 моветон это когда на щите нет кнопок и приходится открывать шкаф, чтобы сделать пуск-стоп установки.
Как раз управление вешается на дискретные входы ПЛК, а всякие датчики, которые и раз в 1 с можно опрашивать на модули.
Но когда у самого ПЛК фильтр такой как у Карел, то это уже печалька.
например на pCO3 был собран шкафчик протечки, а выбран он был потому, что у него есть возможность отдавать данные по SNMP (это было требованием заказчика). Очень не многие ПЛК умеют гонять данные по данному протоколу. либо ставить шлюз (по тем ценам 24 тыра), либо Карел.

Таки вы мене не поняли.
Если на шкафу стоит барашек и пара тройка лампочек то - норм, либо втроенная либо выносная панелька которая включается на передней стенке шкафа.
Т.к. есть диспетчеризация и иже, то кому будут показывать постоянно горящие лампочки шкафы когда рядом нет людей - друг другу?
А вот делать пульт управления полетом в стиле 60-х годов с десятками лампочек и барашков - это уже плохая практика на сегодняшний день т.к. есть панельки и иже + еще и лампочки менять не будут.
Да наверное есть случаи когда много лампочек надо - но их несколько процентов, вот о чем я.

Специально убирал все кнопочки с двери от разных кнопконажимателей. Только пару индикаторов, типа работа, авария. Чтобы издалека видно было состояние. А любым механизмом можно пошевелить из меню контроллера, доступ многоуровневый.

Я и говорю: лучше, чем паковать, программерам руки вырвать из задницы и засунуть в плечи. Тем паче, 63/73 это вроде ещё овновая разработка, а не китайская.

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

Модбас, как протокол, реально очень простой. Мне когда приспичило на атмелке его набрать в 1998 году, я справился за 2-3 дня. И не то, чтобы я ну прямо профессиональный программер и сейчас и тогда. В 1998 я вообще первые шаги в автоматике делал, до этого только "синклеры" в школе программировал на бейсике и ассемблере. И если овен с этим не справился, то я прямо не знаю, что о них думать. А есть ли там программеры вообще в этой конторе или сброд один собрался...

1. Индикация присутствия напряжения в ШУ. (обязана быть) это как минимум

Их очень много процентов, если у Вас таких случаев мало значит Вы не связаны с промышленностью (производством)
Там очень любят ручные режимы

я выше писал - что трех лампочек достаточно всем и каждому
У вас есть машина - у нее есть ручной режим управления двигателем, ну хотябы форсунки открыть закрыть?
Эра тру ручного режима уже уходит - в BACnet есть например возможность все входы выходы повключать в ручном режиме по сети -Override.
Мое послание что все несколько изменилось с начала веков.
В промышленности я соглашусь могут применятся контроллеры приточек и по 2000EUR вместо привычных 100-200EUR и уж как они там вертят это их дело, т.к. стоимость всего остального уже невелика.
В бизнес сегменте борются за каждую копейку и поэтому - логично избавиться от всего ненужного в 90%.

поэтому избавляются от панелей и ставят лампочки

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

Приезжаю на объект. Сдох контроллер. Из органов управления - кнопка тотал стоп. Сетевой насос работает, гоняет воду. Открываю щит - в пускатель завинчен саморез. Говорят, слесаря догадались, чтобы сеть не разморозить.

Будущее даже ближе. Новые контроллеры MPX One и uChiller. Доступ через NFC или Bluetooth из Андроидного приложения.

Уж очень в тему:
Какой толк от этих ножей в ядерной войне

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

+1 :-)


1. На ЕС вентиляторах есть выход реле "авария"
2. Перед ЕС вентилятором контактор стоит (особенно если он трехфазный)
Вот его включение и будет "работа" (к примеру)