оно, по тексту- сделано под описываемую весьма странную классификацию. в ней тоже описано масло масляное, собранное из отдельных слов, подходящих по смыслу.
Почему то кажется, что все проблемы, описанные в тексте - исходят изначально из первого абзаца. Даже с учетом достаточно непонятных формулировок и смыслов в нём, которые можно трактовать тремя и более диаметрально противоположными смыслами.
ну и само собой туда класть результат работы программы а не саму программу, это само собой разумеется. ну или бот чтобы отвечал только подписчикам канала и у них всякое спрашивать иногда. Общение и социализация - Великая Сила.
Я бы к примеру пошёл другим путём. Даже можно сказать хожу уже третий год другим путём.
Доп. данные - Sprinkad я когда то смотрел, лет 15 назад когда в компании Plazma-t делал ТЗ на расчёт насосных установок.
Вот сейчас у меня по системам автоматизации телеграмм канал с 700 подписчиками ( ютуб 2600). В принципе монетизация уровня " в резюме" - мне кажется более чем приемлиемым вариантом, если нет понимания как и чего продавать. Опять же в большом телеграмм канале всегда можно найти людей которые существенно умнее в какой то отдельно взятой узкой нише.
Опять же сделав условно бесплатную историю с расчётом ботом в телеграмме можно создать в телеграмме канал (комьюнити) и получить быстрый и адэкватный отзыв о работе программы и предложения по исправлению/дополнению такие, какие врятли можно получить от платной программы. Бонусом так же множество советов более бывалых проектировщиков их отдельной какой либо сферы - если программа будет востребована проектировщиками " сарафанным радио"
как совет - интерфейсом для программы могут быть кнопки и текст в телеграмм боте. можно даже просить чатгпт чтобы он форматирование в виде таблицы оставил, при выводе в телеграмм.
вот поэтому и интересно, где в климатической технике, даже теоретически - может возникнуть требование запроса измерений, выполняемых одновременно.
В моей вселенной это вот что что, но климатика настолько инерционна, что некоторые параметры измерять даже раз в секунду - это весьма и весьма быстро. а уж управлять кзр-ом так вообще.
Поэтому такое требование - в виде одновременных измерений - звучит Диссонансом с климатическими системами.
Чисто для информации к примеру сигнетикс не свои алгоритмы не сами писали а списывали с некоторых давно выпускаемых серийно контроллеров. Это не существенней дипломов, зато уровень компетенций не пропиваемый.
"""На счет поддержки будет кстати такая вещь. В нескольких ВУЗах будет обучение автоматизации на примере idiBus. Лабораторные работы и практикумы. """
это ещё и обучение и постоянный, наработанный годами штат поддержки.
и тут вообще каждое слово можно написать с большой буквы.
А так то не понятно, ну допустим у Вас умные устрйства с большими процессорами. ну так положите на них opc_ua и не надо ничего нового изобретать. возьмите любой другой уже подходящий протокол. Изобретение нового это дело достаточно неблагодарное. Потому что у Вас видение какого то маленького, достаточно узкого участка АСУ- ТП. я к примеру вот не могу даже представить себе где нужно одновременное начало измерения температуры, передавать по 485-му. а Вы не можете представить к примеру количество опс приборов с опросом 24/7/385, по отношению к асу-тп.
Сначала наверно стоит ознакомиться со Всеми Спецификациями, чтобы не выдёргивать из конеткста. Благо сайт modbus.org известен, и раздел Технических спецификаций там один. Чтобы понимать что шифрование по необходимости есть.
Ну а самые большие проблемы с протоколом описаны в конце, и собственно лишают новые протоколы всякого смысла - цитата
"""
И да, протокол Modbus это не только библиотеки опросчиков на абсолютно разных языках, opc серверы и scada системы,
это ещё и обучение и постоянный, наработанный годами штат поддержки.
чего нет и врят-ли появится у новых протоколов, к сожалению.
какие вопросы описано в статье решает предлагаемый новый протокол:
Шифрование.
Обновление прошивок по шине..
Одновременное считывание показаний
Внеочередное обращение к Master.
Спящий и безопасный режим.
Обратная совместимость с MODBUS RTU.
Стандартная обработка ошибок передачи данных.
ну для начала шифрование данных в modbus возможно. Для этого наверно стоит смотреть не на описание на ipc2.ru а брать исходный текст на modbus.org.
Оффтопом - тогда, кстати и не будет этого бреда из серии "регистров всего 9999". потому что в спецификации от 1996 года этот подход уже тогда был признан устаревшим и предлагалось в Той спецификации так больше не делать, а использовать для каждого типа функций модбаса при необходимости по 65534 регистра каждая. и да, крайняя версия протокола от 2012 года.
второй пункт - в modbusrtu вполне можно передавать файлы и ими обновлять прошивки.
20-я функция модбаса вам в помощь, то-есть проблемы нет как таковой
Пункт третий - одновременное. Групповые посылки это конечно интересно, но вот необходимость в этом... Если это один модуль - зачастую этот вопрос решается битовыми масками. Если это разные модули, то тут наверно вопросов больше чем ответов - к примеру что будет если послать команду допустим включения реле на три модуля сразу и один модуль его включил, второй не включил потому что ошибочно прочитал пакет, и в ответ выдаёт ошибку, а третий модуль вообще выключен и не отвечает.
Возможно эти коллизии и разрулены, но Все ли они разрулены и нужно ли их Так разруливать, или лучше опрашивать всё таки Последовательно, вопрос достаточно интересный и не однозначный.
Четвертый пункт - а зачем обращатья к Мастеру? в чём сермяжный смысл? если можно скажем программно на линии сделать ещё одно " подчинённое устройство" которое и будет как бы " отвечать. НО это как бы ну совсем какие то узкие применения, не мильно понятно вообще для куда.
Пятый пункт - Это вообще не понятно для чего. Хотите в модулях отключить аналоговый тракт - ну так стандартными методами этот вопрос решается достаточно просто, конфигурированием устройства так же по модбасу.
Шестой пункт- Совместимость - судя по описанию предлагается какой то странной и не однозначной.
Седьмой пункт - Обработка ошибок. Наверно для того, чтобы лучше понимать этот вопрос - стоит обратиться к Спецификации на Протокол Модбаса. Там есть ОЧЕНЬ МНОГО интересного, в 2012-м году, что может решить наверно 98% вопросов, котоыре даже не так очевидны, как кажется.
Ну а отдельно вообще про новый протокол и модбас:
1) Стандартных библиотек предлагающих Разные формы абстракции - для Модбаса реализовано Очень много.
И на python и на С и, что более важно, для Большинства ( если не для всех за малым исключением) Scada систем.
Для более высокого уровня абстракции всё таки принято использовать OPC серверы,
которые опросив данные по модбасу могут выдавать данные в более приятном виде - и в виде физических величин, и с датой актуальности и качества данных. И могут иметь Нормальное плюс-минус шифрование и защиту , OPC_UA к примеру.
И эта архитектура зарекомендовала себя весьма и весьма хорошо.
И да, потуги были у иридиума сделать свой протокол и у вайронборда.
ну как то оно не выходит широко за пределы одного-двух производителей. Наверно отчасти и потому что Уровень проработки вопросов в Modbus всё таки существенно шире и более объёмен.
И да, протокол Modbus это не только библиотеки опросчиков, opc серверы и scada системы,
это ещё и обучение и постоянный, наработанный годами штат поддержки.
чего нет и врят-ли появится у новых протоколов, к сожалению.
да, было бы совсем жестко со средней пенсией 21000 в год, конечно)))
просто нолики не сложились, а цифры 12 не было, не заметил)
ага, просто смотрю что цифры не подходят одна к другой, лишний ноль потерялся)
Интересная математика в целом:
41 720 000 пенсионеров
получают в среднем
21 800
перемножаем одно на другое получаем
909 496 000 000
и в целом пенсионный фонд тратит 9 трл.
9 000 000 000 000
то-есть на выплаты среднему пенсионеру идёт всего лишь 10% от вообще выплат пенсионного фонда.
вроде в нулями нет же косяков, верно же?
оно, по тексту- сделано под описываемую весьма странную классификацию. в ней тоже описано масло масляное, собранное из отдельных слов, подходящих по смыслу.
вот именно!
Кто то в 2023 году пользуется яндэксом? и яндэкс-картами? Это Очень странно.
Почему то кажется, что все проблемы, описанные в тексте - исходят изначально из первого абзаца. Даже с учетом достаточно непонятных формулировок и смыслов в нём, которые можно трактовать тремя и более диаметрально противоположными смыслами.
То-есть вы по смыслу - сертифицируете каким то образом Алгоритм?
как, где?
во внииПО?
не понятно.
(доп. вводные - сейчас я в болиде работаю)
ну и само собой туда класть результат работы программы а не саму программу, это само собой разумеется. ну или бот чтобы отвечал только подписчикам канала и у них всякое спрашивать иногда. Общение и социализация - Великая Сила.
Я бы к примеру пошёл другим путём. Даже можно сказать хожу уже третий год другим путём.
Доп. данные - Sprinkad я когда то смотрел, лет 15 назад когда в компании Plazma-t делал ТЗ на расчёт насосных установок.
Вот сейчас у меня по системам автоматизации телеграмм канал с 700 подписчиками ( ютуб 2600). В принципе монетизация уровня " в резюме" - мне кажется более чем приемлиемым вариантом, если нет понимания как и чего продавать. Опять же в большом телеграмм канале всегда можно найти людей которые существенно умнее в какой то отдельно взятой узкой нише.
Опять же сделав условно бесплатную историю с расчётом ботом в телеграмме можно создать в телеграмме канал (комьюнити) и получить быстрый и адэкватный отзыв о работе программы и предложения по исправлению/дополнению такие, какие врятли можно получить от платной программы. Бонусом так же множество советов более бывалых проектировщиков их отдельной какой либо сферы - если программа будет востребована проектировщиками " сарафанным радио"
как совет - интерфейсом для программы могут быть кнопки и текст в телеграмм боте. можно даже просить чатгпт чтобы он форматирование в виде таблицы оставил, при выводе в телеграмм.
"""...Начиная с версии 5 (1981) MS-DOS ..."""
есть ощущение что имелся ввиду 1991 год, или версия пониже (1.1 к примеру)
Бодрого Вам написания статей, дело это нужное и полезное, согласен.
pic32Z2048efg144B- I/PI даже вот интересно) ну и если к ней подключен скажем TM043NDH02-40 TFT 4.3' ну мало ли, ну вдруг)
Бодрого дня, вот прямо интересно, а есть ли порт на pic32 к примеру? ;)
вот поэтому и интересно, где в климатической технике, даже теоретически - может возникнуть требование запроса измерений, выполняемых одновременно.
В моей вселенной это вот что что, но климатика настолько инерционна, что некоторые параметры измерять даже раз в секунду - это весьма и весьма быстро. а уж управлять кзр-ом так вообще.
Поэтому такое требование - в виде одновременных измерений - звучит Диссонансом с климатическими системами.
Чисто для информации к примеру сигнетикс не свои алгоритмы не сами писали а списывали с некоторых давно выпускаемых серийно контроллеров. Это не существенней дипломов, зато уровень компетенций не пропиваемый.
и при управлении приточкой желательно измерять температуру и управлять кзр-ом как можно медленней.
"""На счет поддержки будет кстати такая вещь. В нескольких ВУЗах будет обучение автоматизации на примере idiBus. Лабораторные работы и практикумы. """
это ещё и обучение и постоянный, наработанный годами штат поддержки.
и тут вообще каждое слово можно написать с большой буквы.
А так то не понятно, ну допустим у Вас умные устрйства с большими процессорами. ну так положите на них opc_ua и не надо ничего нового изобретать. возьмите любой другой уже подходящий протокол. Изобретение нового это дело достаточно неблагодарное. Потому что у Вас видение какого то маленького, достаточно узкого участка АСУ- ТП. я к примеру вот не могу даже представить себе где нужно одновременное начало измерения температуры, передавать по 485-му. а Вы не можете представить к примеру количество опс приборов с опросом 24/7/385, по отношению к асу-тп.
хм...
"""Шифрованые данные это уже не оригинал а новый протокол. Цитата тут: https://modbus.org/docs/Modbus-SecurityPR-10-2018.pdf"""
Сначала наверно стоит ознакомиться со Всеми Спецификациями, чтобы не выдёргивать из конеткста. Благо сайт modbus.org известен, и раздел Технических спецификаций там один. Чтобы понимать что шифрование по необходимости есть.
Ну а самые большие проблемы с протоколом описаны в конце, и собственно лишают новые протоколы всякого смысла - цитата
"""
И да, протокол Modbus это не только библиотеки опросчиков на абсолютно разных языках, opc серверы и scada системы,
это ещё и обучение и постоянный, наработанный годами штат поддержки.
чего нет и врят-ли появится у новых протоколов, к сожалению.
"""
достаточно спорная статья.
какие вопросы описано в статье решает предлагаемый новый протокол:
Шифрование.
Обновление прошивок по шине..
Одновременное считывание показаний
Внеочередное обращение к Master.
Спящий и безопасный режим.
Обратная совместимость с MODBUS RTU.
Стандартная обработка ошибок передачи данных.
ну для начала шифрование данных в modbus возможно. Для этого наверно стоит смотреть не на описание на ipc2.ru а брать исходный текст на modbus.org.
Оффтопом - тогда, кстати и не будет этого бреда из серии "регистров всего 9999". потому что в спецификации от 1996 года этот подход уже тогда был признан устаревшим и предлагалось в Той спецификации так больше не делать, а использовать для каждого типа функций модбаса при необходимости по 65534 регистра каждая. и да, крайняя версия протокола от 2012 года.
второй пункт - в modbusrtu вполне можно передавать файлы и ими обновлять прошивки.
20-я функция модбаса вам в помощь, то-есть проблемы нет как таковой
Пункт третий - одновременное. Групповые посылки это конечно интересно, но вот необходимость в этом... Если это один модуль - зачастую этот вопрос решается битовыми масками. Если это разные модули, то тут наверно вопросов больше чем ответов - к примеру что будет если послать команду допустим включения реле на три модуля сразу и один модуль его включил, второй не включил потому что ошибочно прочитал пакет, и в ответ выдаёт ошибку, а третий модуль вообще выключен и не отвечает.
Возможно эти коллизии и разрулены, но Все ли они разрулены и нужно ли их Так разруливать, или лучше опрашивать всё таки Последовательно, вопрос достаточно интересный и не однозначный.
Четвертый пункт - а зачем обращатья к Мастеру? в чём сермяжный смысл? если можно скажем программно на линии сделать ещё одно " подчинённое устройство" которое и будет как бы " отвечать. НО это как бы ну совсем какие то узкие применения, не мильно понятно вообще для куда.
Пятый пункт - Это вообще не понятно для чего. Хотите в модулях отключить аналоговый тракт - ну так стандартными методами этот вопрос решается достаточно просто, конфигурированием устройства так же по модбасу.
Шестой пункт- Совместимость - судя по описанию предлагается какой то странной и не однозначной.
Седьмой пункт - Обработка ошибок. Наверно для того, чтобы лучше понимать этот вопрос - стоит обратиться к Спецификации на Протокол Модбаса. Там есть ОЧЕНЬ МНОГО интересного, в 2012-м году, что может решить наверно 98% вопросов, котоыре даже не так очевидны, как кажется.
Ну а отдельно вообще про новый протокол и модбас:
1) Стандартных библиотек предлагающих Разные формы абстракции - для Модбаса реализовано Очень много.
И на python и на С и, что более важно, для Большинства ( если не для всех за малым исключением) Scada систем.
Для более высокого уровня абстракции всё таки принято использовать OPC серверы,
которые опросив данные по модбасу могут выдавать данные в более приятном виде - и в виде физических величин, и с датой актуальности и качества данных. И могут иметь Нормальное плюс-минус шифрование и защиту , OPC_UA к примеру.
И эта архитектура зарекомендовала себя весьма и весьма хорошо.
И да, потуги были у иридиума сделать свой протокол и у вайронборда.
ну как то оно не выходит широко за пределы одного-двух производителей. Наверно отчасти и потому что Уровень проработки вопросов в Modbus всё таки существенно шире и более объёмен.
И да, протокол Modbus это не только библиотеки опросчиков, opc серверы и scada системы,
это ещё и обучение и постоянный, наработанный годами штат поддержки.
чего нет и врят-ли появится у новых протоколов, к сожалению.