Импортозамещение в АСУТП Опции

[kosmos440o]

Холивар, конечно, но все же
приведите пару конкретных примеров из HVAC.

Что тяжело делать на FBD - менюшки (возможно, что есть хорошие варианты, как у бывшего ТАС), свои протоколы. Всё, что связано с обычным IT - сортировка списков, поиск в массиве, годовые таймеры и т.п. Энто да, но большинству это не нужно. Ибо это лучше делать на ПК или спецсервере автоматизации с linux.

Сообщение отредактировал kosmos440o - 23.11.2018, 4:49

[kosmos440o]

Холивар, конечно, но все же
приведите пару конкретных примеров из HVAC.

Что тяжело делать на FBD - менюшки (возможно, что есть хорошие варианты, как у бывшего ТАС), свои протоколы. Всё, что связано с обычным IT - сортировка списков, поиск в массиве, годовые таймеры и т.п. Энто да, но большинству это не нужно. Ибо это лучше делать на ПК или спецсервере автоматизации с linux.

Сообщение отредактировал kosmos440o - 23.11.2018, 4:49

[Lex]

Что тяжело делать на FBD - менюшки (возможно, что есть хорошие варианты, как у бывшего ТАС), свои протоколы. Всё, что связано с обычным IT - сортировка списков, поиск в массиве, годовые таймеры и т.п. Энто да, но большинству это не нужно. Ибо это лучше делать на ПК или спецсервере автоматизации с linux.

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

[manjey73]

Lex а при чем тут HVAC ? им единым жива автоматизация ?
Ротация насосов, кондиционеров например, можно сделать тупо на FBD (делал такое), а можно сделать более продвинутый алгоритм, который FBD потянет, но будете долго собирать квадратики.
Мало того, есть с чем сравнивать Овен ПР, Zelio, Logo, реле ABB, среди них всех только у Овен математика не урезана, остальные в такой заднице со своими реализациями FBD.

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

Да, и на счет своих протоколов факт, это часто бывает нужно и необходимо.

Lex сортировка списков, например аварий по времени, чтобы в меню отобразить, или по важности ошибки

Много вы примеров видели, где у FBD есть свойства полезные, а не используемые для настройки его работы ?

Сообщение отредактировал manjey73 - 23.11.2018, 9:31

[GYUR22]

Lex а при чем тут HVAC ? им единым жива автоматизация ?
Ротация насосов, кондиционеров например, можно сделать тупо на FBD (делал такое), а можно сделать более продвинутый алгоритм, который FBD потянет, но будете долго собирать квадратики.
Мало того, есть с чем сравнивать Овен ПР, Zelio, Logo, реле ABB, среди них всех только у Овен математика не урезана, остальные в такой заднице со своими реализациями FBD.

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

Да, и на счет своих протоколов факт, это часто бывает нужно и необходимо.

Lex сортировка списков, например аварий по времени, чтобы в меню отобразить, или по важности ошибки

Много вы примеров видели, где у FBD есть свойства полезные, а не используемые для настройки его работы ?

С одной стороны если это адски важно то что вы пишете - то делов то сделать свой контроллер с блэкджеком и шлюпками шоб все сортировалось и ротировалось как надо.
А с другой стороны например сортировку аварий по важности и дате легко делать в БМС - сидя в удобном кресле, а не пыхтя от жары в тп.
Насосы и иже ротируются во всех вменяемых ФБД системах.
А вот паковать битики - это не очень здорово если это постоянная практика.
Я видел несколько - контроллеров где десятков аварий закодированы битами или чтобы запустить надо распарсить слово и заменить бит и записать.
Но при этом радетельстве отсутствует точка -общей аварии!
Этож изврат! Какое нафиг продуктивити?

[manjey73]

GYUR22 чтобы понять, о чем я говорю, вам надо на форуме Овен посмотреть что люди вытворяют на FBD в среде программирования Овен Лоджик. Там и ROM, EPROM и регистры сдвига и ПИДы и расчет восхода солнца и многое многое другое.

Повторить некоторые из подобных макросов на других ПР просто невозможно. Но даже в ОЛ есть то, чего можно было избежать.
Просто заложить определенный функционал в прошивку ПР. А так же дать возможность делать собственные макросы на таких языках как Си например. Вроде это в FLProg добавили, но давно не пользовался.

Сколько пользовал ПР разных с голыми FBD это иногда мучения, чтобы реализовать действительно сложные алгоритмы, но при этом мощностей таких устройств для задачи выше крыши. То есть есть места где ПЛК излишен, а среди различных ПР надо еще умудриться подобрать, который потянет... И вот эта середняковая ниша к сожалению пустует. Иногда приходится брать из-за этого ПЛК...

Сообщение отредактировал manjey73 - 23.11.2018, 10:53

[Lex]

Lex а при чем тут HVAC ? им единым жива автоматизация ?

Промотайте страницу вверх, там в верхнем левом углу написано АВОК Диалог Специалистов .

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

За свои более чем 15 лет практики всегда делал ротацию в FBD и никогда не было потребности в "более продвинутых" алгоритмах. Что это вообще? Вот конкретно - что?
На всякий случай ремарка - FBD были из контроллеров Landis&Staefa, Siemens SBT, Saia Burgess, Carel, Контар.

Мало того, есть с чем сравнивать Овен ПР, Zelio, Logo, реле ABB, среди них всех только у Овен математика не урезана, остальные в такой заднице со своими реализациями FBD.

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

Да, и на счет своих протоколов факт, это часто бывает нужно и необходимо.

Lex сортировка списков, например аварий по времени, чтобы в меню отобразить, или по важности ошибки

Это все, как верно указал коллега GYUR22 надо смотреть (делать) на компе - в отладочном ПО или в диспетчеризации.
Сортировать аварии на экране контроллера - это зачем?
Активных обычно немного - разбирайся по очереди с каждой - в любом порядке.
А работа с архивами аварий - ну не на месте в венткамере и ИТП право слово!

Много вы примеров видели, где у FBD есть свойства полезные, а не используемые для настройки его работы ?

Вопрос не понял.
Но, например, у грандов, практикующих Бакнет, ФБ представляют собой комплекс,
и для настройки работы, например, двигателя вентилятора, нет не так, вентилятора в целом,
достаточно правильно настроить один ФБ - дискретный выход.
Там будут и задержки пуска, останова, и аварии, и неисправности и перегрузка и перепад давления
и наработка часов и еще куча много иногда полезного.
И для ротации там тоже всего один ФБ с множеством настроек ротации, начиная от количества ротируемых.
Причем этот блок в FBD соединяется с блоками вентиляторов или насосов одной линией, но по этой линии передается
не один сигнал а сразу несколько (автоматически) - статус, команда, авария, тип аварии, наработка часов и пр.

Все уже придумано до нас. И сделано.
Зачем возвращаться к исходникам (С++)?
Чтобы изобрести очередной велосипед?
Нет.
Просто "потому что я умею" или "потому что я знаю С++".
Ну так и говорите, по-честному.


Сообщение отредактировал Lex - 23.11.2018, 12:23

[manjey73]

Lex я прекрасно знаю, какой это форум, просто человек планирует разработку контроллера, если он сделает его ТОЛЬКО для HVAC, то рынок останется узкий, который ПЕРЕПОЛНЕН.

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

по сути вы говорите о МАКРОСЕ, состоящем из простых FBD, которые заложены в прошивке прибора.

Говорю честно. я не знаю С++, но если будет возможность создать нужный макрос на этом языке, а в программе прибора уже просто поставить квадратик с кучей настроек, это было бы превосходно, ради такого не грех немного и С++ изучить, хотя бы в рамках возможностей прибора.
Такие вещи обычно делаются для определенных целей и частого использования. Опять же, могу отправить посмотреть и к Овен, и к Zelio и к Logo 8-й версии, где макросы возможны в принципе. То есть когда вы можете не копировать целую кучу FBD а создать один на разные случаи использования.

Сообщение отредактировал manjey73 - 23.11.2018, 13:14

[GYUR22]

Lex я прекрасно знаю, какой это форум, просто человек планирует разработку контроллера, если он сделает его ТОЛЬКО для HVAC, то рынок останется узкий, который ПЕРЕПОЛНЕН.

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

по сути вы говорите о МАКРОСЕ, состоящем из простых FBD, которые заложены в прошивке прибора.

Говорю честно. я не знаю С++, но если будет возможность создать нужный макрос на этом языке, а в программе прибора уже просто поставить квадратик с кучей настроек, это было бы превосходно, ради такого не грех немного и С++ изучить, хотя бы в рамках возможностей прибора.
Такие вещи обычно делаются для определенных целей и частого использования. Опять же, могу отправить посмотреть и к Овен, и к Zelio и к Logo 8-й версии, где макросы возможны в принципе. То есть когда вы можете не копировать целую кучу FBD а создать один на разные случаи использования.

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

[manjey73]

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

Но разрабу виднее, соглашаться с некоторыми предложениями или нет, все равно он решит так, как решит.
А вариантов там масса. Если взять пример Овена. Есть прошивка с CodeSys а есть прошивки с Master Scada одних и тех же ПЛК, а есть прошивка с Телемеханикой Лайт того же ПЛК.
Как минимум сделать возможность менять бинарные прошивки самостоятельно, без отправления разработчику и без предварительного заказа.
То есть прибор продается всегда с ПО под FBD. Хочешь Си, скачал прошивку, накатил, делаешь на Си. Решил опять использовать FBD, прошил, используй FBD.
Такой подход вполне оптимален, так как человек может попробовать разные пути и выбрать подходящий не меняя железо.

Еще могу сказать по аналоговым входам, выходам. Либо контроллер делать модульным с возможностью перестановки выходов вместо дискретных.
И делать набор универсальных входов, дискрет, 0-20мА, 0-10В. желательно не менее 8 таких входов и не менее 4 выходов сразу на борту.

Сообщение отредактировал manjey73 - 23.11.2018, 13:46

[GYUR22]

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

Но разрабу виднее, соглашаться с некоторыми предложениями или нет, все равно он решит так, как решит.
А вариантов там масса. Если взять пример Овена. Есть прошивка с CodeSys а есть прошивки с Master Scada одних и тех же ПЛК, а есть прошивка с Телемеханикой Лайт того же ПЛК.
Как минимум сделать возможность менять бинарные прошивки самостоятельно, без отправления разработчику и без предварительного заказа.
То есть прибор продается всегда с ПО под FBD. Хочешь Си, скачал прошивку, накатил, делаешь на Си. Решил опять использовать FBD, прошил, используй FBD.
Такой подход вполне оптимален, так как человек может попробовать разные пути и выбрать подходящий не меняя железо.

Еще могу сказать по аналоговым входам, выходам. Либо контроллер делать модульным с возможностью перестановки выходов вместо дискретных.
И делать набор универсальных входов, дискрет, 0-20мА, 0-10В. желательно не менее 8 таких входов и не менее 4 выходов сразу на борту.

Далеки вы очень от народа Юрий Венедиктович
Какбе все хотят денег и запилить три прошивки на контроллер - это на вскидку около десяток человекогодов или денег милионов 10-20 рублей.
Как человек производящий устройства на контрактном производстве в Росии могу сказать - если хотите получить вменямую (на которую еще другие смогут наварить) цену то это от полтыщи и больше устройств (вы продадите столько?). И делать стопицот модулей - невыгодно к сожалению т.к. количество не получится большим, плюс контрактники наваривают процентов 30% от Китая, но Китай он далеко и туда нужны объемы. Самый такой вариант что-то одноплатное с максисмумом io- чтобы перекрыть жадных на io вендоров и влезть в стандартный корпус.
По поводу Си и иже плюсов - может быть маленький язык для логики нужен, но программировать на Си весь контроллер - нафиг к терапевту.

[manjey73]

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

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

Сообщение отредактировал manjey73 - 23.11.2018, 15:15

[yozik]

А вот паковать битики - это не очень здорово если это постоянная практика.

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

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

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

[GYUR22]

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

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

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

[Ashihara]

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

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

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

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

[GYUR22]

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

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

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

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

[DiBraS]

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

[DiBraS]

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

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

Сообщение отредактировал DiBraS - 23.11.2018, 16:59

[manjey73]

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

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

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

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

Сообщение отредактировал manjey73 - 23.11.2018, 17:05

[yozik]

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

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

[GYUR22]

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

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

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

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

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

[yozik]

не умеющих выполнять групповые запросы

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

[GYUR22]

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

Прикрепленные файлы

 chillers.png ( 286,66 килобайт ) Кол-во скачиваний: 17

 

[yozik]

3. За 18 лет работы не помню чтобы хотел массивы.

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

4. А зачем нужны зверушки со своими протоколами - они вроде как почти все вымерли?

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

Обычно кодированием битиков страдают производители контроллеров типа evco, danfoss и прочей преконфигурятины

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

[GYUR22]

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

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

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

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

[yozik]

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

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

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

шлюзы обычно конфигурируются точка-точка и все спец функции обычно за бортом.

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

А так, есть у вас установка, которая висит на своем счетчике предположим, вы ставите контроллер, который обслуживает ее работу, снимает показания счетчика ЗАОДНО и отправляет это все на верхний уровень.

[GYUR22]

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

[yozik]

1.У нас нету рецептов это другая индустрия - я даже смутно представляю что это,

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

2. У каждого своя специфика - я ж говорю про ОВКВ а не про промхолод- там да свой чудесный мир со своими жЫрными тараканами (пару раз пересекался

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

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

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

[GYUR22]

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

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

[yozik]

1.Есть приоритет

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

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

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

Att_SetR.... 32865.1 R Economy mode On
Disatt_SetR 32865.2 R Economy mode Off
TelRSetPar. 32865.3 R Reset changed parameters indicator
ROnAux..... 32865.4 R Auxiliary output
ROffAux..... 32865.5 R Auxiliary output Off
ROnOn...... 32865.6 R Instrument on
ROffOff..... 32865.7 R Instrument off

Сообщение отредактировал yozik - 23.11.2018, 18:08

[svintus]

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

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

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

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


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

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