Мысль космоса в том, что лично он не знает тех, кто не умеет 8N1, а раз таких нет, то и заморачиваться нет смысла. Это как лично я его понял, но может он что и другое на самом деле имел в виду... хз

да его мысль то понятна, но вот если у меня одно устройство будет с 8E1 например и возможности поменять нет, и производитель на это забил или система уже в работе с таким режимом то будет искаться устройство именно с таким режимом работы порта, если требуется включить устройство в ту же линию.
Если включение в новую линию то там в принципе пофигу....

Поработаю немного секретарём Космоса. )) Мне кажется, что на это он вам ответит: - ключевое слово "если"... Это если конечно я до этого всё правильно понял, о чём он хотел донести... ))

Имхо гипотетически такое конечно возможно, почему бы нет...

8N1 9600 ....
Очтальные по возможности... Если вопрос только в программе, то добавить остальное....
Специально городить (менять схемотехнику из-за остальных вариантов не стоит)
При нехватки памяти в контроллере, для реализации каких-либо других "фичь"..
протоколы сокращать первыми.....

Полно "итальянцев" (контроллеров известных в АВОК фирм)
которые умеют только один вариант чаще всего это 8N1 9600

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

У нас же АВОК, а "не производство" (станки и т.д.)
Какой смысл в высоких скоростях.... я вообще датчики опрашиваю раз в 15 минут...

yozik в первую очередь смысл в цене, я уже не первый раз сталкиваюсь с подобным.
Вот и сейчас тоже столкнулся. Требуется данные передать в Data Centr Expert который бывший APC а ныне Schneider Electric, он понимает только SNMP или Modbus TCP, устройств два, оба RTU и одно 8N1 другое 8E1 - прикажете покупать два шлюза или все же на одном устройстве подогнать режим работы под второе ?

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

Победила дружба! Такая типа история из семейной жизни: жена согласилась немного уступить мужу, но муж при этом оказался не прав и немного должен... )))

Также можно столкнуться, что одно будет с протоколом Modbus, а второе с протоколом Овен. Тоже зачастую проблематично, надо порт открывать-закрывать, сколько-то ждать и подключаться разными программами опроса. Прикажете нам протокол Овен в свои устройства добавить? Просто во время проектирования сети смотрят на совместимость устройств. У меня в проектах такое на каждом шагу, и часто бывает, что два устройства рядом, а кабели разные. Так что для новых проектов и большинства частных случаев модернизации вышеозвученная конфигурация устраивает.

У меня тоже с контроллерами много хотелок от желающих такое же, но с перламутровыми пуговицами. Недавно вот взяли моду опять нагрев заслонок делать. Или нагреватель шестиступенчатый. Возможно, потом и сделаю, но вначале надо с основными функциями разобраться. Иначе будет каша. Да и ПЛК надо применений оставить, а то так по миру пойдут))).

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

Это кому делать нечего?
А использовать двоичную логику?
1+2+4 3 ступени вроде,а на самом деле 7

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

Ребята, не обижайтесь, но разговоры вы ведёте уровня радиолюбительского школьного кружка. У меня всё больше и больше возникает ощущение, что вы просто не знаете, как делаются такие вещи правильно. Делитесь поверхностными наблюдениями, урывочным опытом вроде "а у меня тут было"...

Никакого системного подхода и уважения да хотя бы к приснопямятным ПУЭ. Получается как на алиэкспрессе: овно, палки и в основном "так прокатило". Я не брезгую пользоваться товарами с алишки, но доверять им безопасность объекта - увольте.

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

А что ПУЭ? Сечения кабелей?
Блокировки безопасности? Цвет, звук? Дак этого и в других гостах навалом.


За такие книжки на профессиональных радиофорумах бьют мокрыми от мочи тряпками. Могу как нибудь на досуге ссылку поискать.

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


Я как раз сам написал, поэтому у меня время отклика не более 5 мсек без учёта передачи байтов. К сожалению, у меня не стандартная ОС, в которую можно засунуть всё что хочешь. Недавно вот UDP пришлось проползти на брюхе, хотя рабочие чужие примеры были, но портировать что-то не получилось. Зато в исходниках больше 220 байт не проходило, у меня сейчас пакет на 260 пролетает.

Да за одну только мысль протащить два-три кабеля через один ссальник нужно не просто забить мокрыми от мочи тряпками, нужно в этой моче утопить мыслителя

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

Тему вообще зафлудили, люди будут искать информацию по импортозамещению и плеваться.

http://avc-corp.msk.ru/avc1_1.html

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

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

А религозность даже в религиозном вопросе не есть хорошо, потому что даже в священном Писании написано, что "буква убивает, дух животворит".

Наш новый сайт https://citynet-store.com/ Сыроватый правда пока немного..., но новый...

2 yozik Руководство по эксплуатации писал сам, собственноручно.

Отправили образец в Ростест для испытаний на соответствие ГОСТ Р МЭК 61326-1 , пока ждём результата...

А че сразу yozik ;-)
Спасибо, за "выделение" моего "вклада" в импортозамещение.

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

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

Финансовая сторона не раскрыта. Что за облигация?

Нажмите для просмотра прикрепленного файла

Три по цене двух - всё просто вроде... платите за два, а получаете три... )))

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

Стесняюсь спросить - а какова цель отправки датчика в Ростест? Датчики не подлежат обязательной сертификации на сколько мне не изменяет память.
Если вы хотите получить сертификат добровольный - спросите меня "как" - это не так сложно в наше время... и достаточно быстро.
Благо мы всю продукцию сертифицировали.

Кстати, да - мы тоже "импортозамещенцы" ))) кто не слышал - rgp-tech.ru )

Как-как. Поддельный пожсертификат 250 косарей стоит, делают 2 дня. Поддельный он в том смысле, что к нему не будет ни протоколов, ни описаний, но он будет зарегистрирован и юридически проведён как "мы вам верим на слово".

Запишу в копилочку, что дочка/бренд спб-автоматики получает фуфловые сертификаты

Каждый думает в меру своей испорченности ) Поддельный сертификат за 250 косарей? - улыбнули ) А у нас даже ТУ официально зарегистрированы, чем не каждая компания может похвастаться...

Зачем?) Что это даёт?

У вас там не описка в THS-03 - датчик наружный а измерение температуры 0...50С ?

К сожалению, не описка ) Изначально схема разрабатывалась для комнатного и канального датчиков температуры, а там "минус" не нужен, поэтому для более точной передачи информации о температуре диапазон 0-10В привязали к 0-50 градусов.
Сам измерительный элемент выдает -40 + 120 )

Поэтому при использовании THS-03 в качестве именно уличного датчика - мы рекомендуем устанавливать дополнительный измерительный элемент Pt1000 (ну или иной)

Уже сейчас работаем над "универсальной" платой, где диапазон будет -30 + 70, а также выход 0-10В или 4-20мА.

Кстати, уже есть ModBus ) http://rgp-tech.ru/ths_price/ там как раз на выходе температуры все в порядке )))

http://www.rostest.ru/services/test/TCparameters_electro/

Испытания ЭМС на соответствие ГОСТ Р МЭК 61326-1 для оформления Декларации Таможенного Союза 020/2011

ТУ мы тоже разработали... таким образом у нас будет "Протокол о проведении испытаний от АККРЕДИТОВАННОЙ ИСПЫТАТЕЛЬНОЙ ЛАБОРАТОРИИ, Декларация ТС 020/2011 и ещё планируем добровольный сертификат Ростеста на соответствие ГОСТ Р МЭК 61326-1 - это просто, для красоты.

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

А как понять "датчик наружного воздуха (для влажных помещений)"? ))
Нажмите для просмотра прикрепленного файла

А вообще молодцы, хороший ассортимент.

По поводу сертификатов - не кажется ли вам, что слишком вы заморочились "на бумажки"? У нас большая строительная компания (СПб-Автоматика) - максимум что нужно - сертификат от производителя. Проектировщик очень редко задумывается про ЭМС и прочее.
Это совет, не более - вложите денежки в качество и внешний вид продукции.

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

Ааа понятно...

За совет спасибо, но без ЭМС не дают Декларацию Таможенного Союза, а это сейчас маст хев, если вы не в курсе...

арбузный ангел по 5 копеек )))

"Хардкора" не надо. По крайней мере форумчане не обрадуются.
"Свое ПО" быстро нормальным сделать не успеете.
Так что предлагаю остановиться на Кодесисе.
Сбросьте основные параметры (количество и тип вх/вых, питание, процессор, память, формфактор. наличие интерфейсов
и поддерживаемых протоколов, есть ли встроенный/выносной пульт ) в личку, просто интересно, как выглядит и чем набит свеже разработанный контроллер.

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

Хардкор устроил шнайдер со своей серией М221. LD+IL = очень "удобно", особенно с присваиваниями и вычислениями.

Тоже голосую за кодесис ) Хоть и не работал с ним, но говорят - на сомашин похоже = ) Си++ - жестоко, тогда уж ST ))

Ориентация на HVAC будет или универсального применения?

Кодесис нудный, я бы голосовал за среду как у Zelio или FLprog. Конечно, с обязательной сертификацией по 61131.

Я тоже за codesys, пусть будет дорого.

Только вот не надо Zelio или FlProg, не убивайте возможности железа...
Ни вам массивов, ни вам переходов и много чего еще по мелочи.

GYUR22 читайте внимательнее -СДЕЛАТЬ на уровне прошивки либо С++ либо любой FBD говноязык на вкус.
Если потребовалась такая задача, прошил другой прошивкой и окунаешься в Ад а не так, без выбора, сиди на чем дали и матерись на баги и ошибки.

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

Кстати на примере ОЛ, пилят пилять до сих пор...

И очень очень много.
Вон живой пример Данфоссы МСХ
изначально на Си были, лет 6 если не больше.
теперь еще FBD есть, но как-то коряво.
Хорошо что оставили возможность свои блоки на Си вставлять.
Так что свое ПО это долго...

я говорю о конкретной фразе - а не там где то.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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