Просмотр полной версии : Как заставить выходы в МК210-311 работать быстрее 1Гц?
Здравствуйте. Столкнулся с такой не совсем понятной неожиданностью. Есть модуль МК210-311, взял его чтобы "клацать" клапанами и очень удивился, что нельзя его заставить работать стабильно даже с частотой 4Гц, хотя казалось бы, реле это позволяют делать 15мс на замыкание и 15 мс на размыкание, по факту опытным путём выяснил, что реле адекватно отрабатывают за 50мс (замыкание+размыкание) итого получается условно 20Гц, меня бы устроили даже 10 Гц.
Но минимальное значение периода ШИМ, которое можно установить - это 1000 мс. При записи битовой маски непосредственно из контроллера в модуль максимальная частота стабильной работы была достигнута примерно в 3 Гц, дальше уже начинаются пропуски или смена темпа, т.е. импульсы могут прийти быстро 2 подряд, а потом пауза/пропуск.
В общем надо получить хотя бы 10 Гц, и очень удобно было бы это сделать изменяя период ШИМ до 100 мс, но минимальное значение 1000 мс.
Вопрос напрямую к производителям и разработчикам: вы можете как-то снизить минимальный период ШИМ хотя бы до 100 мс, а лучше до 50? Или мне нужно будет искать другие модули, которые справятся с этой задачей?
или есть другие способы?
Здравствуйте. Столкнулся с такой не совсем понятной неожиданностью. Есть модуль МК210-311, взял его чтобы "клацать" клапанами и очень удивился, что нельзя его заставить работать стабильно даже с частотой 4Гц, хотя казалось бы, реле это позволяют делать 15мс на замыкание и 15 мс на размыкание, по факту опытным путём выяснил, что реле адекватно отрабатывают за 50мс (замыкание+размыкание) итого получается условно 20Гц, меня бы устроили даже 10 Гц.
Но минимальное значение периода ШИМ, которое можно установить - это 1000 мс. При записи битовой маски непосредственно из контроллера в модуль максимальная частота стабильной работы была достигнута примерно в 3 Гц, дальше уже начинаются пропуски или смена темпа, т.е. импульсы могут прийти быстро 2 подряд, а потом пауза/пропуск.
В общем надо получить хотя бы 10 Гц, и очень удобно было бы это сделать изменяя период ШИМ до 100 мс, но минимальное значение 1000 мс.
Вопрос напрямую к производителям и разработчикам: вы можете как-то снизить минимальный период ШИМ хотя бы до 100 мс, а лучше до 50? Или мне нужно будет искать другие модули, которые справятся с этой задачей?
или есть другие способы?
А зачем вам ШИМ ?
Parovoz
ШИМ на релейных выходах убьет эти реле очень быстро. Вам требуется модуль с транзисторными выходами.
A.Simonov
16.11.2021, 10:51
Здравствуйте. Столкнулся с такой не совсем понятной неожиданностью. Есть модуль МК210-311, взял его чтобы "клацать" клапанами и очень удивился, что нельзя его заставить работать стабильно даже с частотой 4Гц, хотя казалось бы, реле это позволяют делать 15мс на замыкание и 15 мс на размыкание, по факту опытным путём выяснил, что реле адекватно отрабатывают за 50мс (замыкание+размыкание) итого получается условно 20Гц, меня бы устроили даже 10 Гц.
Но минимальное значение периода ШИМ, которое можно установить - это 1000 мс. При записи битовой маски непосредственно из контроллера в модуль максимальная частота стабильной работы была достигнута примерно в 3 Гц, дальше уже начинаются пропуски или смена темпа, т.е. импульсы могут прийти быстро 2 подряд, а потом пауза/пропуск.
В общем надо получить хотя бы 10 Гц, и очень удобно было бы это сделать изменяя период ШИМ до 100 мс, но минимальное значение 1000 мс.
Вопрос напрямую к производителям и разработчикам: вы можете как-то снизить минимальный период ШИМ хотя бы до 100 мс, а лучше до 50? Или мне нужно будет искать другие модули, которые справятся с этой задачей?
или есть другие способы?
Добрый день.
Характеристики модуля не держатся в секрете и указаны на сайте и в РЭ.
Там написано, что максимальная частота ШИМ 1Гц для данного модуля.
Дело в том, что выходы у этих модулей - релейные, на них нет особого смысла "ШИМить", иначе реле выйдут из строя очень быстро.
Если вам требуется ШИМ, то есть модули с транзисторными выходами: МУ210-410 и МУ210-411 (10-60 кГц частоты ШИМ)
https://owen.ru/product/moduli_diskretnogo_vivoda_ethernet/specifications
А зачем вам ШИМ ?
Затем, чтобы изменять частоту работы реле от 1 до 10 Гц, я же выше всё изложил.
Добрый день.
Характеристики модуля не держатся в секрете и указаны на сайте и в РЭ.
Там написано, что максимальная частота ШИМ 1Гц для данного модуля.
Дело в том, что выходы у этих модулей - релейные, на них нет особого смысла "ШИМить", иначе реле выйдут из строя очень быстро.
Если вам требуется ШИМ, то есть модули с транзисторными выходами: МУ210-410 и МУ210-411 (10-60 кГц частоты ШИМ)
https://owen.ru/product/moduli_diskretnogo_vivoda_ethernet/specifications
Мне нужно всего 10Гц, не килогерц, да даже не 100 Гц, а всего 10Гц. Я думаю это логично, если реле позволяет отрабатывать такую частоту конструктивно, то сделать такую возможность доступной. И что в вашем понимании "очень быстро"? День? Неделя? Месяц? Там стоят реле принципиально отличающиеся от реле в контроллере? В контроллере реле в подобном режиме уже работают порядка 5 лет, постоянно непрерывно щелкая по 8 часов в сутки. С частотой порядка 10Гц.
Petrovi4
20.11.2021, 18:05
Типичный инжынер современности...
Ради интереса почитайте про такой параметр реле как "Maximum operating frequency Mechanical" и "Maximum operating frequency Electrical"
Совершенно внезапно производители указывают последний в районе 2000 срабатываний в час.
Сергей0308
20.11.2021, 19:04
Вероятно человек хочет сделать механический выпрямитель переменного тока, на диодах сэкономить, здесь грех смеяться, сразу видно - вещь стоящая получится, тем более сейчас проблемы с полупроводниками!
Есть еще "механическая долговечность", у Финдера, к примеру, заявлено 10 млн. срабатываний. Это 278 часов работы в этом идиотском режиме.
Уважаемые господа инженеры, в чём смысл ваших поучительных высказываний? Я задал конкретный вопрос преимущественно производителям, точнее просьбу снизить минимальный период ШИМ до 100мс. Но коль уж вы так усердно пытаетесь макнуть меня в мою же некомпетентность, то объясните мне пожалуйста какова будет принципиальная разница между тем, что я поставлю срабатывание реле на 50 мс каждую секунду и оставлю это на 1 час? И между тем, что я периодически примерно раз в 20 минут буду запускать реле с частотой в 10Гц на 10-15 секунд? Ведь в первом случае это позволяет сделать конфигурация модуля.
special for Petrovi4
Частота выходов модуля 1Гц, что позволяет реле щёлкать как минимум по 3600 раз в час, можешь заодно переадресовать своё замечание "типичным инжЫнерам современности" из Овен.
По поводу ресурса реле за 8 лет эксплуатации приборов Овен, пока ещё ни одно реле не вышло из строя по механическим причинам, а нащелкали они уже гораздо больше чем заявлено в механическом ресурсе и уж тем более больше чем заявлено в электрическом ресурсе всего в 35000 срабатываний, а это всего лишь чуть менее 10ч непрерывной работы. Выходит модуль вывода расчитан на 10ч. постоянной работы?
В моём случае мне надо управлять пульсацией клапана, и не с какой-то заоблачной частотой, а порядка 10 Гц, даже полдюймовый пилотируемый клапан успевает отработать за 100мс и не износиться за пару лет эксплуатации, а по вашей логике реле развалиться должно.
Смысл мне брать модуль с ключами, чтобы на ключи навешивать реле? Или вы предлагаете на ключи навешивать другие более мощные ключи, и с него запитывать клапан просто потому что это по идее правильно? Есть стандартная технологическая задача, с которой прекрасно справляется реле, и всё, что нужно - это снизить период ШИМ до 100мс, что существенно расширит функционал модуля вывода. Вот и всё.
Поэтому смысла устраивать холивар не вижу, давайте решать реальные задачи, а не щеголять знаниями. Просьба моя вполне понятная и реальная, ничего сверхъестественного и противоречивого в ней не вижу.
Добрый день.
Характеристики модуля не держатся в секрете и указаны на сайте и в РЭ.
Там написано, что максимальная частота ШИМ 1Гц для данного модуля.
Дело в том, что выходы у этих модулей - релейные, на них нет особого смысла "ШИМить", иначе реле выйдут из строя очень быстро.
Если вам требуется ШИМ, то есть модули с транзисторными выходами: МУ210-410 и МУ210-411 (10-60 кГц частоты ШИМ)
https://owen.ru/product/moduli_diskretnogo_vivoda_ethernet/specifications
Мне нужен модуль МК, чтобы были дискретные входы и выходы. Вы мне предлагаете использовать МУ и МВ в паре, а потом ещё на транзисторные выходы навесить внешние реле т.е. вместо того, чтобы просто уменьшить период ШИМ в прошивке до 100 мс, с учётом того, что в характеристиках прибора заявлен минимальный импульс ШИМ 50мс. Вы мне предлагаете сделать всё тоже самое, но только выстроив дополнительный огород из двух модулей и дополнительной релейной обвязки. Просто потому что, вот так.
Я просто не вижу какой-то адекватной логики в этом, с одной стороны минимальный импульс в 50 мс вы допускаете на реле, но сделать 10 импульсов в секунду уже нельзя, аргументируя это быстрым механическим износом реле, при этом заявляете ресурс в 35000 срабатываний, который в теории вырабатывается за 10 часов непрерывной работы.
Емельянов Кирилл
22.11.2021, 01:00
давайте решать реальные задачи
Если это и вправду полдюймовый пилотируемый клапан, то вполне может хватить транзисторного ключа в прямом включении (катушки на таких клапанах по 10-15 Вт обычно), единственное диод защитный не забыть. Конечно, при условии, что катушка на постоянный ток. Вряд ли "Овен" быстро реализует вашу хотелку. Так что либо вендор другой, либо подстраивайтесь под существующую номенклатуру
Филоненко Владислав
22.11.2021, 08:26
Мне нужен модуль МК, чтобы были дискретные входы и выходы. Вы мне предлагаете использовать МУ и МВ в паре, а потом ещё на транзисторные выходы навесить внешние реле т.е. вместо того, чтобы просто уменьшить период ШИМ в прошивке до 100 мс, с учётом того, что в характеристиках прибора заявлен минимальный импульс ШИМ 50мс. Вы мне предлагаете сделать всё тоже самое, но только выстроив дополнительный огород из двух модулей и дополнительной релейной обвязки. Просто потому что, вот так.
Я просто не вижу какой-то адекватной логики в этом, с одной стороны минимальный импульс в 50 мс вы допускаете на реле, но сделать 10 импульсов в секунду уже нельзя, аргументируя это быстрым механическим износом реле, при этом заявляете ресурс в 35000 срабатываний, который в теории вырабатывается за 10 часов непрерывной работы.
Если при минимальном импульсе 50 мс сделать период ШИМ 100мс - этот шим будет 3-х позиционным, 0% мощности, 50% и 100%. Толку в таком шиме никакого.
Если при минимальном импульсе 50 мс сделать период ШИМ 100мс - этот шим будет 3-х позиционным, 0% мощности, 50% и 100%. Толку в таком шиме никакого.
Почему вы меня пытаетесь убедить в том, что мне это ненужно, когда мне это нужно? Какая разница скольки-позиционным будет этот шим, если надо просто использовать возможности реле? Обыкновенный практический толк от этого шим - это возможность генерировать импульсы с частотой в 10Гц. Вот и всё! Я это пишу с самого начала мне не надо 100 Гц, мне не надо делать пид-регулирование на этом шиме, мне просто надо щёлкать реле с частотой в 10Гц, и реле это позволяет сделать.
Филоненко Владислав
29.11.2021, 10:43
ну не будет реле генерировать импульсы 10 Гц. Во первых по ресурсу, во вторых само время срабатывания реле вещь нестабильная, механика! И будет у Вас плавать частота.
А хотите щёлкать - управляйте напрямую, макс. мощность-мин мощность - вот и будет щёлкать, благо быстродействие модуля по связи позволяет и не такое.
В виду ну очень нестандартной задачи/хотелки видится 2 решения:
1) все таки взять полупроводниковый выход( ну и вход в придачу) и потом навешать хоть цепочку из своих реле( от того что нет комбинированных дискретных IO с транзисторами тоже в свое время плевался, но как говориться "не нравиться, не ешь")
2) заказать у ОВЕНА спец прошивку( под партию или за денюжку( если очень хочется, но 1 шт) думаю согласятся). Ну а вопрос запиливания реле решить например счетчиком срабатываний, с автоматическим снятием с гарантии
ну не будет реле генерировать импульсы 10 Гц. Во первых по ресурсу, во вторых само время срабатывания реле вещь нестабильная, механика! И будет у Вас плавать частота.
А хотите щёлкать - управляйте напрямую, макс. мощность-мин мощность - вот и будет щёлкать, благо быстродействие модуля по связи позволяет и не такое.
Я же объяснил ещё в первом посте, что если управлять напрямую битовой маской, например, то получается порядка 4 Гц и то с перерывами, чаще 4 Гц щёлкать не получается напрямую. Быстродействие связки плк200+мк210 не позволяет это делать быстрее 4 Гц фактически.
Сами реле без проблем генерируют 5-10 Гц на том же самом контроллере и служат годами. Опять начинаете одно да потому, не будет работать, да не будет работать, ну проверьте сами, ну будет там нестабильность в 2-5мс в этом нет ничего критичного. Главное, на контроллере можно щёлкать как угодно без ограничений, а на модуле вывода реле сломаются, при этом даже если щёлкать, как написано в мануале то реле сломается через 10 часов работы. При этом минимальное время замыкания 50мс разрешено выставить, но сделать это 10 раз в секунду уже нельзя, где логика? даже 5 раз в секунду нельзя. А можно всего 1 раз в секунду.
В виду ну очень нестандартной задачи/хотелки видится 2 решения:
1) все таки взять полупроводниковый выход( ну и вход в придачу) и потом навешать хоть цепочку из своих реле( от того что нет комбинированных дискретных IO с транзисторами тоже в свое время плевался, но как говориться "не нравиться, не ешь")
2) заказать у ОВЕНА спец прошивку( под партию или за денюжку( если очень хочется, но 1 шт) думаю согласятся). Ну а вопрос запиливания реле решить например счетчиком срабатываний, с автоматическим снятием с гарантии
Ну в контроллерах нет ограничения на частоту щёлканья, в модулях вывода сделали, а заявленной коммутационной стойкости хватает на 10 часов работы всего.
Ну в контроллерах нет ограничения на частоту щёлканья, в модулях вывода сделали, а заявленной коммутационной стойкости хватает на 10 часов работы всего.
В контроллерах "прямой привод" IO и ограничение бы там пришлось специально делать, а в модулях в качестве ограничителя выступает "неспешный" Modbus TCP( ну а частоту ШИМа ограничили в разумных пределах)
P.S. Кстати у них появилась ПР103 с эзернетом, может эту фигню использовать вместо МК210 (IO у нее предостаточно, цена вроде сопоставимая, рефлекторное поведение можно локально замутить)?
Да я всё прекрасно понимаю, чем контроллер отличается от модуля вывода. И даже представляю, как в реальности принималось решение об 1 Гц, посидели, подумали и решили, пусть будет 1 Гц, и скорее всего в подавляющем большинстве случаев этого действительно достаточно. Я лишь прошу сделать не 1 Гц, а 10 Гц, просто минимальную уставку периода уменьшить до 100 мс то, что реально позволяет отрабатывать реле, вот и всё. Ну просто это как минимум логично. Хотя у каждого своя логика.
Филоненко Владислав
30.11.2021, 09:11
С чего это у MX210 ограничение по частоте обмена по TCP? Он как пулемёт работает.
С чего это у MX210 ограничение по частоте обмена по TCP? Он как пулемёт работает.
В лаболаторных условиях и до первого потерянного пакета( а там ретрансмиты, ТСР стек которым фиг по управляешь( обсуждали вроде года 4 назад, на заре появления модулей))!
В лаболаторных условиях и до первого потерянного пакета( а там ретрансмиты, ТСР стек которым фиг по управляешь( обсуждали вроде года 4 назад, на заре появления модулей))!
Я сомневаюсь, что кому-то придёт в голову соединять ПЛК и модуль в/в через WAN-канал. Если же у Вас в локалке на голом эзернете такие чудеса происходят - то все претензии к кривому монтажу. Даже в не самого хорошего качества WAN-канале латентность ниже 300 миллисекунд, что всяко выше быстродействия модуля по работе непосредственно с вводами/выводами.
Меня тоже не впечатлила работа модуля (имел дело - заказчик настоял) Пулемет так себе оказался даже в сравнении с rs-485. Хотя казалось бы.
то все претензии к кривому монтажу.
Так понял что я тогда не в ту сторону изогнул 50см-ровый кабелёчек от ПЛК до модуля. И видимо воткнул в eth-разъем поперёк - это ж обычное дело.
И да, после соединял этот же ПЛК этим же кабелёчком и другим полуживым кабелем с отломанными защелками но с другими приборами - и строчил пулеметчик за синий платочек.
Было года 3 назад. Может и выросли апельсины.
Филоненко Владислав
03.12.2021, 07:34
Валенок, у Вас всегда какие-то эксклюзивные проблемы. То тумблеры в закрытом шкафу сами переключаются, то Ethernet медленнее RS работает.
Валенок, Вы, прежде чем делать как бы ехидные комментарии, потрудитесь прочитать и, самое главное, понять написанное.
Что касается быстродействия собственно модулей Мх210, то у меня тоже сложилось впечатление, что они проигрывают линейке Мх110 в этом плане. Я имел дело только с модулями ввода, если что.
... потрудитесь прочитать и, самое главное, понять написанное..
Если же у Вас в локалке на голом эзернете такие чудеса происходят - то все претензии к кривому монтажу..
Именно. Про 50см - см. выше
в не самого хорошего качества WAN-канале латентность ниже 300 миллисекунд,
Меня мало волнует какая скорость где-то там на участке в - хоть 100500терабит/сек.
Если от ухода запроса до получения ответа больше 5..300мс или я не могу сделать одну-пару-тройку сотен последовательных запросов в секунду, это связь - гуано по сравнению с rs.
Или модули поддерживают тыщу открытых сокетов то можно засылать запросы как угодно параллельно ?
...какие-то эксклюзивные проблемы...., то Ethernet медленнее RS работает.
Т.е. Вы гарантируете что теперь в точка/точка можно делать минимум 200-300 последовательных запросов модуля в секунду и не будет ни одного обрыва или с задержкой ответа более 10мс на протяжении часа (например) ?
keysansa
06.12.2021, 22:32
Именно. Про 50см - см. выше
Про загнутый шнурок - это байка 0day. Если вы позволяете себе промэлектронику с соединениями "без язычка", скорее всего у вас столько других косяков, что рассматривать ваши претензии, без вызова на место - очень сложно.
Меня мало волнует какая скорость где-то там на участке в - хоть 100500терабит/сек.
Если от ухода запроса до получения ответа больше 5..300мс или я не могу сделать одну-пару-тройку сотен последовательных запросов в секунду, это связь - гуано по сравнению с rs.
Или модули поддерживают тыщу открытых сокетов то можно засылать запросы как угодно параллельно ?
Причем тут скорость и число сокетов?
Т.е. Вы гарантируете что теперь в точка/точка можно делать минимум 200-300 последовательных запросов модуля в секунду и не будет ни одного обрыва или с задержкой ответа более 10мс на протяжении часа (например) ?
Я прочитал выше, не нашел ваших условий локальной сети. Не увидел протокола соединения. Но modbus может обеспечить 200-300 запросов/с по 100 мбит сети. Даже по 10 мБ
не нашел ваших условий локальной сети.
Система простая - нажал кнопку и дома (С)
Какие условия могут быть с ПЛК, модулем и 50см. шнурком ? Ой, забыл, была полная луна.
Не увидел протокола соединения.
Э-э-э Ну как бы модбас-tcp
Но modbus может обеспечить 200-300 запросов/с по 100 мбит сети. Даже по 10 мБ
Modbus - может. Ноут - может. ПЛК - может. Шнурдаже без защелок - может. Другой девайс - может.
Модуль ни с кем не смог. Даже с шнуром с защелками.
Теперь - может ? Кто-то гарантирует ?
200 запросов можно и по rs. Всего лишь на 115200
Причем тут скорость и число сокетов?
Цитирую :
"потрудитесь прочитать и, самое главное, понять написанное."
вы позволяете себе промэлектронику с соединениями "без язычка",
Я позволяю себе отвечать за свою работу и оборудование которое ставлю.
скорее всего у вас столько других косяков,
)) Самое смешное в этом сообщении. Найдёте мои "помогитя !!"?
рассматривать ваши претензии..
А претензий нет. Был - факт. Опровернуть или показать неактуальность может не бла-бла а предоставление реальных данных за несколько часов - кол-во транзакций, максимальное ожидание ответа, кол-во переокрытий сокета (на столе ожидаю ноль). Без данных - балабольство.
Поддержу Валенка. Я достал из коробки МК210-311 и ПЛК200, аналогично соединил кабелем в 50 см, установил все необходимые библиотеки, добавил шаблон модуля в список устройств, привязал переменную битовой маски к блинкеру и начал экспериментировать, синхронно изменяя timehigh и timelow. Затыки (неравномерность частоты срабатывания) начались примерно на 150ms. Что соответствует примерно 3 Гц частоты срабатывания. Тогда я решил проверить, а срабатывает ли реле в принципе. Поменял режим работы на ШИМ, выставил 50 мс, и всё шикарно работало, но с частотой в 1Гц.
Я не против сделать прямое управление через битовую маску, если это будет работать, и суть темы не в том, чтобы охаять модули и вынудить производителей исполнять любые прихоти потребителей, а в том, чтобы использовать возможности прибора полностью соразмерно решаемым задачам, но так быстро при прямом управлении битовой маской он не работает.
Возможно проблема в том, что при добавлении шаблона модуля подгружаются и читаются все данные из модуля, поэтому быстродействие страдает и надо добавлять не шаблон целиком, а лишь нужные регистры, вот так я ещё не пробовал. В пользу этого говорит тот факт, что если оставить непрерывную запись регистров по времени, а не по изменению, то скорость ещё сильнее падает. А если оставить запись регистров по изменению, то можно 3 Гц получить.
Но опять же это (имхо) некий костыль получается, что модуль из коробки, подключенный цивилизованным образом по инструкции через шаблон устройства тормозит.
Коськовецкий Владислав
08.12.2021, 18:31
Да, вы правы, на самом деле при работе через шаблоны скорость обмена с модулями уменьшается в силу того что опрашиваются все параметры модуля.
Если скорость работы через шаблоны не устраивает используйте стандартные компоненты MB Slave.
keysansa
08.12.2021, 19:12
)) Самое смешное в этом сообщении. Найдёте мои "помогитя !!"?
Не знаю конкретно про вас, но часто приезжаю именно на "помогите". Хотя мне это не интересно, я больше в программирование. Но хорошим клиентам помогаю и по слаботочке.
ЗЫ. Вы забыли ответить на мой вопрос "Причем тут скорость и число сокетов? ".
Не знаю конкретно про вас...
Как это не знаете ? Знаете же :
.. скорее всего у вас столько других косяков..
..Вы забыли ответить на мой вопрос "Причем тут скорость и число сокетов? ".
А где взяли именно про скорость ?
..modbus может обеспечить 200-300 запросов/с по 100 мбит сети...
И да, причем именно тут "100 мбит сети" если меня волнует кол-во запросов в единицу времени ?
опрашиваются все параметры модуля..
Ну так можно дать сводную статистику опроса 1-го единственного параметра (регистра) модуля из ПЛК110 конфиг мастером (там мин пултайм 10мс) и, например, программным по простейшему алгоритму как с ком-портом :
1.отправили запрос, фикснули время
2.дождались ответа, отбили время, гоуту 1
?
На столе. С прямым монтажем 50-см кабеля. Покажите ехать модуля а не шашечки в виде эзернета.
Филоненко Владислав
10.12.2021, 07:59
Ну так можно дать сводную статистику опроса 1-го единственного параметра (регистра) модуля из ПЛК110 конфиг мастером (там мин пултайм 10мс) и, например, программным по простейшему алгоритму как с ком-портом :
1.отправили запрос, фикснули время
2.дождались ответа, отбили время, гоуту 1
?
На столе. С прямым монтажем 50-см кабеля. Покажите ехать модуля а не шашечки в виде эзернета.
Валенок, а почему у нас на стенде нет проблем с темпом опроса?
Валенок, а почему у нас на стенде нет проблем с темпом опроса?
Владислав, а почему из набора (ноуты, плк-шки, другое, модуль) были проблемы только в парах с модулем ? Он - "весь в белом" ?
Бла-бла или статистика ?
Филоненко Владислав
10.12.2021, 12:55
Владислав, а почему из набора (ноуты, плк-шки, другое, модуль) были проблемы только в парах с модулем ? Он - "весь в белом" ?
Бла-бла или статистика ?
Какая статистика то?
keysansa
10.12.2021, 18:23
Цитирую :
"потрудитесь прочитать и, самое главное, понять написанное."
Я так понимаю, понять я должен был что-то понять из этого?
Именно
Меня мало волнует какая скорость где-то там на участке в - хоть 100500терабит/сек.
Если от ухода запроса до получения ответа больше 5..300мс или я не могу сделать одну-пару-тройку сотен последовательных запросов в секунду, это связь - гуано по сравнению с rs.
Или модули поддерживают тыщу открытых сокетов то можно засылать запросы как угодно параллельно ?
?
У вас ответ по TCP идет более 300мс, а по RS меньше?
keysansa
10.12.2021, 18:27
Ну так можно дать сводную статистику опроса 1-го единственного параметра (регистра) модуля из ПЛК110 конфиг мастером (там мин пултайм 10мс) и, например, программным по простейшему алгоритму как с ком-портом :
1.отправили запрос, фикснули время
2.дождались ответа, отбили время, гоуту 1
?
На столе. С прямым монтажем 50-см кабеля. Покажите ехать модуля а не шашечки в виде эзернета.
Когда столкнулся с таким поведением модуля (RS, 2 модуля, 8DI, 8DO, не получалось выдержать реакцию в 200мс), ушел на другого вендора. Так как модули валялись, занялся тестами, ушел от их конфигурирования к опросу через код программы. В 200мс получилось уложиться.
P.S. Вроде анонсируют 240ю серию модулей и ПЛКашки с EtherCAT'ом. Возможно с ней наши мучения закончатся ;).
keysansa
10.12.2021, 19:50
P.S. Вроде анонсируют 240ю серию модулей и ПЛКашки с EtherCAT'ом. Возможно с ней наши мучения закончатся ;).
Скорость обмена по проприетарным протоколам сейчас не может угнаться за Ethernet. Валенок пытается сравнить доступ по Ethernet с Ростова до Архангельска, с соединением двух RS устройств в пределах цеха 300 метров. Иначе я не могу понять задержки более 300мс.
...Валенок пытается сравнить доступ по Ethernet с Ростова до Архангельска, с соединением двух RS устройств в пределах цеха 300 метров. Иначе я не могу понять задержки более 300мс.
У меня вся претензия именно к TCP( у Валенок предполагаю тоже).
В лабораторных условиях/на стенде/на столе все идет хорошо, но в реальном мире есть такое явление как потеря пакета, порождающая задержку и последующий автоматический ретрансмит( но сдается мне с достаточно приличными и покрутить мы их, вроде, не можем).
А так как у нас мастер в канале работает по принципу запрос/ответ, на fast retransmit можно не рассчитывать( который сглаживает проблему на больших/непрерывных потоках данных).
P.S. По моим сведениям большинство( если не все) real time протоколы не работают через TCP(наверное разработчики о чем то таком знали).
"Протокол TCP (https://ru.wikipedia.org/wiki/TCP), хотя и стандартизирован для передачи RTP,[3] (https://ru.wikipedia.org/wiki/Real-time_Transport_Protocol#cite_note-3) как правило не используется в RTP-приложениях, так как надежность передачи в TCP формирует временные задержки"( отсюда: https://ru.wikipedia.org/wiki/Real-time_Transport_Protocol)
https://stackoverflow.com/questions/49471342/tcp-for-real-time-systems/49471444
. Валенок пытается сравнить доступ по Ethernet с Ростова до Архангельска, с соединением двух RS устройств в пределах цеха 300 метров..
Keysansa пытается рассказывать о своих сновидениях ?
Цитируем или бла-бла ?
промышленный Ethernet (тот же EtherCat) не работает по TCP и требует соответствующего оборудования сети. О чем вы вообще? EtherCat не будет работать на линии между двумя городами.
keysansa
10.12.2021, 22:16
промышленный Ethernet (тот же EtherCat) не работает по TCP и требует соответствующего оборудования сети. О чем вы вообще? EtherCat не будет работать на линии между двумя городами.
Промышленный Ethernet - это и Ethercat, и Profinet и Powerlink и Modbus TCP. Все это поверх Ethernet.
keysansa
10.12.2021, 22:17
Keysansa пытается рассказывать о своих сновидениях ?
Цитируем или бла-бла ?
У Валенок задежки в локальной сети до 300мс? Тогда ой.
.. на столе все идет хорошо, но в реальном мире есть такое явление как потеря пакета,...
Ну хоть десяток последних постов прочитайте. Какой реальный мир, о чем Вы ?
Один от Ростова до Архангельска мериет видимо по экрану прикладывая дедушкин портновский метр (а как еще можно получить длину меньше упомянутой раза три ?)
Другой не может прочитать выше на несколько постов и начинает бла-бла как с чистого листа, и Вы туда же ?
keysansa
10.12.2021, 22:22
У меня вся претензия именно к TCP( у Валенок предполагаю тоже).
В лабораторных условиях/на стенде/на столе все идет хорошо, но в реальном мире есть такое явление как потеря пакета, порождающая задержку и последующий автоматический ретрансмит(с фиг знает какими таймаутами( но сдается мне с достаточно приличными и покрутить мы их, вроде, не можем)).
А так как у нас мастер в канале работает по принципу запрос/ответ, на fast retransmit можно не рассчитывать( который сглаживает проблему на больших/непрерывных потоках данных).
P.S. По моим сведениям большинство( если не все) real time протоколы не работают через TCP(наверное разработчики о чем то таком знали).
"Протокол TCP (https://ru.wikipedia.org/wiki/TCP), хотя и стандартизирован для передачи RTP,[3] (https://ru.wikipedia.org/wiki/Real-time_Transport_Protocol#cite_note-3) как правило не используется в RTP-приложениях, так как надежность передачи в TCP формирует временные задержки"( отсюда: https://ru.wikipedia.org/wiki/Real-time_Transport_Protocol)
https://stackoverflow.com/questions/49471342/tcp-for-real-time-systems/49471444
TCP чем вас не устраивает? Подтверждением передачи? Уберите CRC в сообщении, TCP сам для пакета рассчитывает.
ЗЫ. Потери пакетов (если вы не только в лаборатории работаете) возникают при отказе промежуточных узлов, и при перемаршрутизации линка (что возникает при тех же условиях). Изредка, такое наблюдается при превышении нагрузки (но вы же выбираете устройства с коммутационной матрицей, удовлетворяющих условиям ТЗ?). Попробуйте такое провернуть с 485.
keysansa
10.12.2021, 22:22
Ну хоть десяток последних постов прочитайте. Какой реальный мир, о чем Вы ?
Один от Ростова до Архангельска мериет видимо по экрану прикладывая дедушкин портновский метр (а как еще можно получить длину меньше упомянутой раза три ?)
Другой не может прочитать выше на несколько постов и начинает бла-бла как с чистого листа, и Вы туда же ?
Третий придумывает проблемы на ровном месте )
Третий (а еще четвертый, если канешна читали выше) просит гарантировать данные. На столе. Если проблемы решены. А в ответ - тишина.
При этом пятый в руки девайс не брал походу. Или, если брал, может что-то предоставить или просто поговорить пришел ? Третий этот модуль своими руками щупал года два назад если что.
keysansa
10.12.2021, 22:55
Третий (а еще четвертый, если канешна читали выше) просит гарантировать данные. На столе. Если проблемы решены. А в ответ - тишина.
При этом пятый в руки девайс не брал походу. Или, если брал, может что-то предоставить или просто поговорить пришел ? Третий этот модуль своими руками щупал года два назад если что.
TCP гарантирует "данные на столе".
ЗЫ. Но если у третьего в локальной сети отклики более 300мс - это проблемы не TCP, а третьего.
То есть можете поставить 50тыр как гарантию что на столе за несколько часов не будет ни одной задержки более 10мс ?
Я ставлю 5тыр, т.к. не продавец.
Быстрый выход плк на модуль ввода который читаем и сечем временные задержки.
Готовы ?
Плк с К у меня есть, у Вас видимо есть модуль, судя по уверенности и разговорчивости
keysansa
12.12.2021, 15:48
То есть можете поставить 50тыр как гарантию что на столе за несколько часов не будет ни одной задержки более 10мс ?
Я ставлю 5тыр, т.к. не продавец.
Быстрый выход плк на модуль ввода который читаем и сечем временные задержки.
Готовы ?
Плк с К у меня есть, у Вас видимо есть модуль, судя по уверенности и разговорчивости
Вы как-то неровно относитесь к ситуации.
Заявляете о невозможности обмена менее 300мс, но на спор выдвигаете требования 10мс девиации.
Причем с моей стороны необходимо поставить 50тыр, а с вашей 5тыр.
Потому, что вы не продавец.
e.filatov
12.12.2021, 19:10
То есть можете поставить 50тыр как гарантию что на столе за несколько часов не будет ни одной задержки более 10мс ?
Я ставлю 5тыр, т.к. не продавец.
Быстрый выход плк на модуль ввода который читаем и сечем временные задержки.
Готовы ?
Плк с К у меня есть, у Вас видимо есть модуль, судя по уверенности и разговорчивости
Данный спор не имеет смысла, т.к. скорость обмена по TCP зависит от очень огрмного кол-ва параметров. Сразу скажу ответ - стабильно 10 мс никогда, ни у одного производителя не будет. Именно поэтому и была разработана шина EtherCAT с минимальным временем отклика.
У себя же на столе при подключении точка-точка удавалось выжимать 5 мс на отклик (проверяли, считывая системное время из модуля, там гарантированно шаг 1мс+-1%). Но тут стоит ещё учитывать время цикла ПЛК, которое тоже плавает.
e.filatov
12.12.2021, 19:14
Промышленный Ethernet - это и Ethercat, и Profinet и Powerlink и Modbus TCP. Все это поверх Ethernet.
По поводу EtherCAT вы не правы, у них немного отличается топология на физ. уровне. Да, есть EtherCAT поверх классического Ethernet, только "кольца" вы в нём не получите
keysansa
12.12.2021, 20:32
По поводу EtherCAT вы не правы, у них немного отличается топология на физ. уровне. Да, есть EtherCAT поверх классического Ethernet, только "кольца" вы в нём не получите
Я кольца на классическом Ethernet могу получить, вопрос не в этом.
Филоненко Владислав
13.12.2021, 09:57
У меня вся претензия именно к TCP( у Валенок предполагаю тоже).
В лабораторных условиях/на стенде/на столе все идет хорошо, но в реальном мире есть такое явление как потеря пакета, порождающая задержку и последующий автоматический ретрансмит( но сдается мне с достаточно приличными и покрутить мы их, вроде, не можем).
А так как у нас мастер в канале работает по принципу запрос/ответ, на fast retransmit можно не рассчитывать( который сглаживает проблему на больших/непрерывных потоках данных).
P.S. По моим сведениям большинство( если не все) real time протоколы не работают через TCP(наверное разработчики о чем то таком знали).
"Протокол TCP (https://ru.wikipedia.org/wiki/TCP), хотя и стандартизирован для передачи RTP,[3] (https://ru.wikipedia.org/wiki/Real-time_Transport_Protocol#cite_note-3) как правило не используется в RTP-приложениях, так как надежность передачи в TCP формирует временные задержки"( отсюда: https://ru.wikipedia.org/wiki/Real-time_Transport_Protocol)
https://stackoverflow.com/questions/49471342/tcp-for-real-time-systems/49471444
Если поместить промоборудование в ту же сеть где и офис, смотрят нетфликс, работает 1C и пр - то потери пакетов есть неизбежная ситуация, никак просто не исправляемая. А если промоборудование в выделенной сети и там нет много широковещательных UDP - то всё очень быстро и качественно.
Если поместить промоборудование в ту же сеть где и офис, смотрят нетфликс, работает 1C и пр - то потери пакетов есть неизбежная ситуация, никак просто не исправляемая. А если промоборудование в выделенной сети и там нет много широковещательных UDP - то всё очень быстро и качественно.
Я правильно "услышал", что если изолированную(от офиса) пром сеть собрать исключительно из компонентов ОВЕН и при этом всю силу оставить "под боком"(а не в отдельном подземном бункере на удалении в километр), то потери пакетов ГАРАНТИРОВАНО исключены?
P.S. Предполагаю изобрели новый "медный" тип связи которому по боку эти всякие EMI?
P.S.2 Что то в памяти всплывает история, про то, как аж целая релюшка клала сетевой интерфейс модуля на лопатки.
Филоненко Владислав
13.12.2021, 16:02
Вы услышали совсем не то. Поставьте сниффер и отмониторьте офисную сеть крупного предприятия. Там море левых пакетов.
При этом типичный процессор типа 107/207 STM реально может переварить до 1000, максимум 2000 пакетов в секунду без их пропусков из-за переполнения буфера. И вот в этих пропущенных пакетах могут быть Ваши запросы на чтение дискретного входа. А ретрансмиты обычно - это от 50 до 200мс ожидания "ну когда же мне ASK пришлют". Вот и считайте как перегруженная сеть превращает среднее время ответа 2 мс в провалы по 200 мс.
И тут либо ставить процессоры помощнее (CORE i5 по тестам хорошо держит шторм в линии на 100Мбитах), либо всё же физически разнести сети управления от офиса.
И что ещё хуже, пакеты обычно идут косяком, час тишина, а потом как 15 минут все заваливают друг друга данными.
Проблем в изолированной сети с обменом не наблюдали.
Поэтому то и на столе обычно проблем нет - т.к. с отдельной карты сеть поднимают, а на производстве: "Чего это мы будет отдельный кабель тянуть, это ж Интернет, он даже 4 к тянет, чего пару пакетов в секунду не пропустит?" Зато экономия.
P.S. непромышленные сети не являются сетями с гарантированной доставкой в заданное время. Но немного подумав это достижимо.
P.P.S. вот не надо, ставим рядом пускатель без RS-цепочек и вдруг проблемы. ВнеГОСТовские помехи прибор держать не обязан. А всё опять же, экономия на суппресорах!
...А ретрансмиты обычно - это от 50 до 200мс ожидания "ну когда же мне ASK пришлют"...Вот и считайте как перегруженная сеть превращает среднее время ответа 2 мс в провалы по 200 мс.....
0. Желательно точно в "граммах" для 100х/200х ПЛК (ТСР стеки то небось разные).
P.P.S. вот не надо, ставим рядом пускатель без RS-цепочек и вдруг проблемы. ВнеГОСТовские помехи прибор держать не обязан. А всё опять же, экономия на суппресорах!
Я так и не понял: изолированная "овеновская" сеть( проложенная в типичном производстве) гарантирует на 100% целостность пакетов или все же допускает повреждения/потери пакетов?
И если, все же, второй вариант, то интересно поведение системы( например для потери пакета с запросом от мастера(но и другие варианты тоже интересны)):
Через сколько первый ретрансмит?
Через сколько реконнект?
Что будет делать мастер устройств при таймауте 10мс( а что будет делать modbus.lib(или как там ее))?
Пошлет ли мастер устройств следующий запрос через 10мс или будет упорно ждать ответа(или разрыва соединения)?
Получив следующий запрос без предыдущего модуль, по логике, должен выругаться и ТСР стек, по логике, прислать склеенный запрос: переварит ли их модуль?
....
Куча вопросов и так мало ответов
Т.е. интересуют какие то временные гарантии:
детектирования проблемы со связью
безопасного отката задания: что когда это все, все таки, разрулится через (20мин ?) модуль не включит, наконец то, выход(когда это делать уже категорически нельзя, иначе трах-тибидох)
P.S. Сейчас, конкретно мне, это больше для академического интереса.
Филоненко Владислав
14.12.2021, 10:11
Времена ретрансмитов обычно в диапазоне 50-200мс.
Мастер прождав 10мс будет посылать следующий запрос (тот же или другой зависит от настроек мастера)
Проблемы со связью можно отдетектировать по нескольким потерям связи. При этом смысла ставить таймаут в 10 мс никакого нет, быстрее не заработает. Сам протокол TCP - с гарантированной доставкой (но в не гарантированное время и с ограничением на это окно времени). Т.е. возможны 2 варианта:
а. потерян пакет, силами TCP соединение восстановлено (таймауты 50-200мс)
б. Соединене порвано (множественные потери или физическая потеря связи).
Соответственно для надёжной связи следует:
1. Выяснить таймауты (мин/макс) ответов приборов на длительном периоде и исходя из них выставлять таймауты мастера.
2. Если есть потери - это выяснится на тесте и либо надо устранить причины, либо поправить таймауты. Также можно включить режим повторов команд при срабатывании таймаута
3. Безопасный откат - ну термин странный для системы управления, есть защита от пропадания мастера (есть wathcdog мастера), а вот защиты от позднего прихода пакета не существует в обычной сети Ethernet - но можно избежать такого, убрав пропадания пакетов.
Также следует при проектировании системы учитывать реакцию модулей на команды - например Вы записываете новые настройки аналоговых входов - модуль начнёт их применять и некоторое время (минимум цикл опроса всех входов) значения с входов будут устаревшими/не соответствующими настройкам.
e.filatov
14.12.2021, 15:22
Вот как раз модуль 701-й под рукой был, решил "заснять" обмен.
Подключение через сеть компании, опрос с ПК Windows, 1 мастер TCP, пауза между запросами 0 мс.
Вот как раз модуль 701-й под рукой был, решил "заснять" обмен.
Подключение через сеть компании, опрос с ПК Windows, 1 мастер TCP, пауза между запросами 0 мс.
В чем смысл проделанной работы: чтобы другие полюбовались как у кого то на его конкретной машине с конкретным софтом идет обмен пакетиками?
Типовой ответ на опрос конкретного модуля составляет 3мс, а где гарантии что завтра не будет 4, а в полнолуние 400....?
Тема то вроде про около реалтайм на ОВЕНе(т.е. ПЛКашка(100/200) + модули)
P.S. Собственно ответить на это все могут только разрабы( драйвера сетевухи + сетевой стек + вероятно CS RT), если вдруг соблаговолят, да и то, сдается мне, им придется очень при очень плотно поковырять в исходниках!
e.filatov
15.12.2021, 01:22
В чем смысл проделанной работы: чтобы другие полюбовались как у кого то на его конкретной машине с конкретным софтом идет обмен пакетиками?
Типовой ответ на опрос конкретного модуля составляет 3мс, а где гарантии что завтра не будет 4, а в полнолуние 400....?
Тема то вроде про около реалтайм на ОВЕНе(т.е. ПЛКашка(100/200) + модули)
P.S. Собственно ответить на это все могут только разрабы( драйвера сетевухи + сетевой стек + вероятно CS RT), если вдруг соблаговолят, да и то, сдается мне, им придется очень при очень плотно поковырять в исходниках!
pt200, я как раз и показывал свой кейс. Извините, но изучение принципов обмена по TCP даст ответы на все Ваши вопросы. Больше мне добавить нечего.
P.S. Работа велась другая. Заснять обмен - 1 минута дела
Тоже предлагаю закончить эту беседу.
P.S. согласно RFC 6298 (https://datatracker.ietf.org/doc/html/rfc6298) таймаут динамический(от "ping'a"), но не менее 1с. Но в среднем у линукса, например, делают от 200мс.
Филоненко Владислав
15.12.2021, 12:49
В чем смысл проделанной работы: чтобы другие полюбовались как у кого то на его конкретной машине с конкретным софтом идет обмен пакетиками?
Типовой ответ на опрос конкретного модуля составляет 3мс, а где гарантии что завтра не будет 4, а в полнолуние 400....?
Тема то вроде про около реалтайм на ОВЕНе(т.е. ПЛКашка(100/200) + модули)
P.S. Собственно ответить на это все могут только разрабы( драйвера сетевухи + сетевой стек + вероятно CS RT), если вдруг соблаговолят, да и то, сдается мне, им придется очень при очень плотно поковырять в исходниках!
Вот и последние 3 страницы Вам и твердят, что прибор работает быстро, а если есть проблемы надо брать схему сети, сниффер и смотреть конкретно, т.к. проблемы не от прибора, у него секретного гиперканала к ПК фирмы ОВЕН нет, он пользуется Вашей сетью!
Вот и последние 3 страницы Вам и твердят, что прибор работает быстро, а если есть проблемы надо брать схему сети, сниффер и смотреть конкретно, т.к. проблемы не от прибора, у него секретного гиперканала к ПК фирмы ОВЕН нет, он пользуется Вашей сетью!
А я на последних 3х страницах пытаюсь выяснить как же поведут себя Ваши приборы в нашинской(да и в Вашинской, получается,тоже(раз продаете железки без встроенного гиперканала)) простой земной сети, а слышу только, что:
Наши устройства работают идеально!*
* при условии использования гиперканальной сети
Филоненко Владислав
17.12.2021, 13:37
А я на последних 3х страницах пытаюсь выяснить как же поведут себя Ваши приборы в нашинской(да и в Вашинской, получается,тоже(раз продаете железки без встроенного гиперканала)) простой земной сети, а слышу только, что:
Наши устройства работают идеально!*
* при условии использования гиперканальной сети
А мы всё хотим схему сети и логи снифера|. Какие мы нехорошие! Нет бы взмахнуть волшебной палочкой!
А мы всё хотим схему сети и логи снифера|. Какие мы нехорошие! Нет бы взмахнуть волшебной палочкой!
Перефразирую мое видение нашего плодотворного общения на таблетки:
Я: а можно инструкцию вначале почитать: принцип действия, побочки, ...?
ОВЕН: А ты сначала прими, а потом расскажешь(самим интересно). А там подумаем как это устранять.
P.S. Мне "лечить" нечего(системы то нет). Вернее была давнишняя попытка, которая "слилась" по множеству причин(ОВЕН там тоже "постарался").
Просто пытаюсь добиться истины(что бы знать), на случай, если вдруг еще придется столкнуться.
keysansa
17.12.2021, 21:23
Я правильно "услышал", что если изолированную(от офиса) пром сеть собрать исключительно из компонентов ОВЕН и при этом всю силу оставить "под боком"(а не в отдельном подземном бункере на удалении в километр), то потери пакетов ГАРАНТИРОВАНО исключены?
P.S. Предполагаю изобрели новый "медный" тип связи которому по боку эти всякие EMI?
P.S.2 Что то в памяти всплывает история, про то, как аж целая релюшка клала сетевой интерфейс модуля на лопатки.
А как вы потери пакетов мониторите? Собрали на столе из говна и палок и у вас связи нет?
А как вы потери пакетов мониторите?...
Я никак не мониторю(см. предыдущее сообщение), а вообще для этого в реальной сети используют TAP (https://ru.wikipedia.org/wiki/Network_tap)
...Собрали на столе из говна и палок и у вас связи нет?
Чем я вызвал Вашу агрессию?
Если знаете ответы на мои вопросы, ну подскажите убогому то, зачем сразу "на мыло".
Филоненко Владислав
21.12.2021, 10:31
т.е. никаких работ (и попыток) понять в чем же проблема, теряются ли пакеты и т.п. даже не предпринималось?
т.е. никаких работ (и попыток) понять в чем же проблема, теряются ли пакеты и т.п. даже не предпринималось?
Я что то совсем запутался: так ОВЕН гарантирует 100% сохранность пакетов в их сетях? (только в этот раз четко: ДА / НЕТ)
P.S. у других бывает(но, с другой стороны, они же не ОВЕН): https://www.youtube.com/watch?v=PPyUIuU-U9U
P.S2. просто если ДА, то у меня нет вопросов, кроме: зачем меня терроризировали бестолковыми расспросами последние ХХ страниц темы?
ну а если НЕТ, то зачем меня терроризировали бестолковыми расспросами последние ХХ страниц темы?
:)
Филоненко Владислав
22.12.2021, 10:49
Я что то совсем запутался: так ОВЕН гарантирует 100% сохранность пакетов в их сетях? (только в этот раз четко: ДА / НЕТ)
P.S. у других бывает(но, с другой стороны, они же не ОВЕН): https://www.youtube.com/watch?v=PPyUIuU-U9U
P.S2. просто если ДА, то у меня нет вопросов, кроме: зачем меня терроризировали бестолковыми расспросами последние ХХ страниц темы?
ну а если НЕТ, то зачем меня терроризировали бестолковыми расспросами последние ХХ страниц темы?
:)
Вы действительно запутались. Бывает.
Сеть Ethernet со стеком протоколов TCP/IP не гарантирует ни доставку пакетов до получателя, ни временные характеристики такой доставки. За таким в Ethercat, к примеру.
Также ясно, что Вы лишь пытаетесь разжигать, решение проблемы, по видимому (да и была ли проблема вообще как и приборы ОВЕН у Вас) Вас не интересует. Интересует лишь хайп и антиреклама.
Вы действительно запутались. Бывает.
Сеть Ethernet со стеком протоколов TCP/IP не гарантирует ни доставку пакетов до получателя, ни временные характеристики такой доставки. За таким в Ethercat, к примеру...
И так: ОВЕН, наконец то, не гарантирует доставку пакетов(не потребовалось и 100 страниц обсуждения), но что будет при потери не скажет(предполагаю, что теперь будет долгая песня про отрицание проблем с латентностью из за этого)
P.S. Я, вроде как, пытаюсь выяснить что меня ждет, если столкнусь с этим(так как мы, наконец то, выяснили что вероятность такого совсем не 0).
...Также ясно, что Вы лишь пытаетесь разжигать, решение проблемы, по видимому (да и была ли проблема вообще как и приборы ОВЕН у Вас) Вас не интересует. Интересует лишь хайп и антиреклама.
Как я писал выше "про таблетки", я скорее из сознательных граждан, которые, по возможности, стараются не совать в рот непонятно чего, а потом бежать с мольбами о помощи к производителю и если это называется "хайп и антиреклама" то прошу пардону.
P.S2 Кстати этот самый Modbus TCP есть не только у ОВЕНА, вроде еще ICP DAS/MOXA/куча китайцев с алика припоминается, а то еще заявите что ОВЕН дискриминирую(у меня скорее от заявления, что "Modbus TCP чудесен для RT" глаз дергаться начинает и все)
P.S3 Так я давно еще предлагал закругляться по этой теме(вроде всем все понятно)?!
Андрей Горский
22.12.2021, 14:23
И так: ОВЕН, наконец то, не гарантирует доставку пакетов(не потребовалось и 100 страниц обсуждения), но что будет при потери не скажет(предполагаю, что теперь будет долгая песня про отрицание проблем с латентностью из за этого)
Здравствуйте, признание ОВЕН соответствует стандартам сети Ethernet. Ваш телефон не гарантирует Вам доставку сообщений в мессенджерах еще и с детерминированным временем. Для этого великие умы разрабатывают новый стандарт, он называется Time Sensitive Network. (https://ru.wikipedia.org/wiki/TSN). Мы внимательно следим за развитием этих спецификаций и постараемся использовать данную технологию когда она перейдет из статуса draft в статус спецификации.
Так же отвечу Вам что произойдёт при потере пакета. В приборах Мх210 есть параметр: тайм-аут перехода в безопасное состояние. Если прибор не будет получать запросов от мастера более чем преднастроено в тайм-ауте, он перейдёт в безопасный режим. Об этом подробно указано в руководстве эксплуатации.
Здравствуйте, признание ОВЕН соответствует стандартам сети Ethernet. Ваш телефон не гарантирует Вам доставку сообщений в мессенджерах еще и с детерминированным временем. Для этого великие умы разрабатывают новый стандарт, он называется Time Sensitive Network. (https://ru.wikipedia.org/wiki/TSN). Мы внимательно следим за развитием этих спецификаций и постараемся использовать данную технологию когда она перейдет из статуса draft в статус спецификации...
Здравствуйте, приятно слышать что работаете над ситуацией.
...Так же отвечу Вам что произойдёт при потере пакета. В приборах Мх210 есть параметр: тайм-аут перехода в безопасное состояние. Если прибор не будет получать запросов от мастера более чем преднастроено в тайм-ауте, он перейдёт в безопасный режим. Об этом подробно указано в руководстве эксплуатации.
Насколько помню время это задается в секундах(т.е. минимум 1000мс, да и не особо важно), а в начале темы говорилось(с чего все это и началось) что очень вероятны проблемы при временах единицы-десятки мс(микромир так сказать) и вот с ними имеется боооольшая неопределенность на данный момент:
1) ретрансмиты от ТСР
2) таймауты от мастера
P.S. То что температуру на улице можно измерять этими модулями без проблем "раз в 5 минут", я никогда и не отрицал.
keysansa
22.12.2021, 22:35
Я никак не мониторю(см. предыдущее сообщение), а вообще для этого в реальной сети используют TAP (https://ru.wikipedia.org/wiki/Network_tap)
Чем я вызвал Вашу агрессию?
Если знаете ответы на мои вопросы, ну подскажите убогому то, зачем сразу "на мыло".
Я задал вопрос, никакой агрессии. В ответ на ваш вопрос.
Вот, что я процитировал:
Я правильно "услышал", что если изолированную(от офиса) пром сеть собрать исключительно из компонентов ОВЕН и при этом всю силу оставить "под боком"(а не в отдельном подземном бункере на удалении в километр), то потери пакетов ГАРАНТИРОВАНО исключены?
P.S. Предполагаю изобрели новый "медный" тип связи которому по боку эти всякие EMI?
P.S.2 Что то в памяти всплывает история, про то, как аж целая релюшка клала сетевой интерфейс модуля на лопатки.
Если вы считаете (как из вашего сообщения следует), что пакеты теряются, я решил узнать, как вы измеряете потерю пакетов. Если вы их не измеряете, зачем тут ГАРАНТИРОВАНО?
ЗЫ. Выше "я никак не мониторю", пропущу пока...
Вот как раз модуль 701-й под рукой был, решил "заснять" обмен.
Подключение через сеть компании, опрос с ПК Windows, 1 мастер TCP, пауза между запросами 0 мс.
Правильно ли я понимаю, что выходит, что при прямом управлении битовой маской, можно без особого труда достигнуть частоты в 10 Гц?
Просто у меня пока нет возможности проверить это на живом оборудовании, на объекте идут монтажные работы, а до объекта 200 км. Но в связке на столе плк200+кабель 50 см+мк210-311 стандартным способом при добавлении шаблона устройства у меня не получалось быстрее 4 Гц щёлкать выходами. Просто добавить один регистр битовой маски я ещё не пробовал.
Если вы можете это проверить и достоверно утверждать, что плк200 может щёлкать выходами модуля со скоростью срабатывания реле, то тему можно считать закрытой.
Parovoz (https://owen.ru/forum/member.php?u=21541), рекомендую, так же, указывать временные параметры сигнала(допуски: скважность, джиттер), а то 10Гц очень расплывчато:
например 9 импульсов по 50/50мс + 1 импульс 90/10мс за секунду устроит?
P.S. Мой ответ(от мимо проходил) МОЖНО, но вот насколько это будет стабильно "обсуждаем" последние ХХ страниц темы
e.filatov
23.12.2021, 14:21
Правильно ли я понимаю, что выходит, что при прямом управлении битовой маской, можно без особого труда достигнуть частоты в 10 Гц?
Просто у меня пока нет возможности проверить это на живом оборудовании, на объекте идут монтажные работы, а до объекта 200 км. Но в связке на столе плк200+кабель 50 см+мк210-311 стандартным способом при добавлении шаблона устройства у меня не получалось быстрее 4 Гц щёлкать выходами. Просто добавить один регистр битовой маски я ещё не пробовал.
Если вы можете это проверить и достоверно утверждать, что плк200 может щёлкать выходами модуля со скоростью срабатывания реле, то тему можно считать закрытой.
Добиться можно. Но никто не сможет гарантировать 10 Гц всегда, т.к. идёт привязка к обмену. А там может произойти всё, что угодно.
Опять, 25.
Я ничего не понял, 8 страниц тут шёл спор о том, что модули отрабатывают менее чем за 1 мс, плк и того меньше, а в итоге, как бы да, но как бы нет.
Что с этим делать? Мне нужно щёлкать 10 раз в одну секунду с периодичностью 50/50. Городить огород из двух модулей, а потом ещё и развязку на реле или ключе делать вообще нет никакого желания.
e.filatov
23.12.2021, 22:05
Опять, 25.
Я ничего не понял, 8 страниц тут шёл спор о том, что модули отрабатывают менее чем за 1 мс, плк и того меньше, а в итоге, как бы да, но как бы нет.
Что с этим делать? Мне нужно щёлкать 10 раз в одну секунду с периодичностью 50/50. Городить огород из двух модулей, а потом ещё и развязку на реле или ключе делать вообще нет никакого желания.
Я устал... Я ухожу. (из топика)
Филоненко Владислав
24.12.2021, 08:11
Правильно ли я понимаю, что выходит, что при прямом управлении битовой маской, можно без особого труда достигнуть частоты в 10 Гц?
Просто у меня пока нет возможности проверить это на живом оборудовании, на объекте идут монтажные работы, а до объекта 200 км. Но в связке на столе плк200+кабель 50 см+мк210-311 стандартным способом при добавлении шаблона устройства у меня не получалось быстрее 4 Гц щёлкать выходами. Просто добавить один регистр битовой маски я ещё не пробовал.
Если вы можете это проверить и достоверно утверждать, что плк200 может щёлкать выходами модуля со скоростью срабатывания реле, то тему можно считать закрытой.
Шаблон содержит множество параметров, вот у вас и получилась такая низкая частота. Оставьте только 1 параметр - маску, и скорость опроса резко возрастёт!
Филоненко Владислав
24.12.2021, 08:15
Добиться можно. Но никто не сможет гарантировать 10 Гц всегда, т.к. идёт привязка к обмену. А там может произойти всё, что угодно.
С одной стороны да. С другой если сеть контролируема и не содержит лишних широковещающих устройств - то почему бы и нет?
Например, на Электросиле в Питере поднимал сеть контроля и управления, цикл управления был 100мс, раз в 50 мс чтение статуса и раз в 50 мс запись управления. По сети Ethernet, ModBus TCP (МХ210 тогда ещё не было, но была сеть из множества ПЛК100/150 и скады).
И, насколько знаю, работает и по сей день.
Но в начале тоже не работало, т.к. тупо включили в офисную сеть. Но выполнив рекомендации по сегментированию и настройкам опроса - всё полетело.
P.S. Какие там стоят токарные станки! Можно камаз целиком загнать и обточить. По любой оси! :)
И медные шины в двигателях толщиной с ногу!
... цикл управления был 100мс, раз в 50 мс чтение статуса и раз в 50 мс запись управления. По сети Ethernet, ModBus TCP ....
Но в начале тоже не работало, т.к. тупо включили в офисную сеть. Но выполнив рекомендации по сегментированию и настройкам опроса - всё полетело..
Тут весь вопрос, а если в 50мс не уложится, то мы об этом как то узнаем, например все производство колом становиться(или и фиг с ним, в следующем цикле проскочит)?
То что в среднем по больнице ТСР сможет и быстрее, я опять же не спорю.
Parovoz (https://owen.ru/forum/member.php?u=21541) , по теме(от мимо проходящего):
Если тех процесс допускает эпизодические, ну допустим, 1но секундные зависания сигналов, то лично я бы осторожно попробовал МХ210, в остальных случаях смотрел в сторону 110х или ПЛКххх(если очень надо эзернет, т.к. там можно накостылить связь через UDP(который по "прозрачности" близок к 485му)).
Филоненко Владислав
24.12.2021, 20:24
Тут весь вопрос, а если в 50мс не уложится, то мы об этом как то узнаем, например все производство колом становиться(или и фиг с ним, в следующем цикле проскочит)?
То что в среднем по больнице ТСР сможет и быстрее, я опять же не спорю.
Parovoz (https://owen.ru/forum/member.php?u=21541) , по теме(от мимо проходящего):
Если тех процесс допускает эпизодические, ну допустим, 1но секундные зависания сигналов, то лично я бы осторожно попробовал МХ210, в остальных случаях смотрел в сторону 110х или ПЛКххх(если очень надо эзернет, т.к. там можно накостылить связь через UDP(который по "прозрачности" близок к 485му)).
Ну вот потому и цикл опроса 50 мс, а цикл управления 100. Чтобы укладывалось. А помех то и нет. вот всё и работает. Если настроить ^)
Но если у Вас Safety Critical применение - то, конечно, обычный TCP никак нельзя, но и цены тогда соовсем другие на Hard RT решения.
И самое главное какая разница МХ или ПЛК - сеть то одинаковая и одинаково себя ведёт - не сегментируешь - получишь потерянные пакеты
Кстати, для любителей "Safety Critical"/"Hard RT" можно посмотреть в сторону SNMP протокола, который теоретически больше для этих задач(предсказуемое поведение) заточен чем MB TCP :)
keysansa
25.12.2021, 17:27
Кстати, для любителей "Safety Critical"/"Hard RT" можно посмотреть в сторону SNMP протокола, который теоретически больше для этих задач(предсказуемое поведение) заточен чем MB TCP :)
Вы попробуйте согласовать SNMP на safety.
keysansa
25.12.2021, 17:30
Опять, 25.
Я ничего не понял, 8 страниц тут шёл спор о том, что модули отрабатывают менее чем за 1 мс, плк и того меньше, а в итоге, как бы да, но как бы нет.
Что с этим делать? Мне нужно щёлкать 10 раз в одну секунду с периодичностью 50/50. Городить огород из двух модулей, а потом ещё и развязку на реле или ключе делать вообще нет никакого желания.
1 мс овен на каком железе умеет? При каких условиях?
e.filatov
25.12.2021, 20:15
1 мс овен на каком железе умеет? При каких условиях?
Да причём тут ОВЕН?
У меня вопрос - Вы вообще понимаете как работает TCP?
Какие 1 мс? хоспади, развели тут базар.
У вас латентность в сети будет около 1 мс, не говоря уже времени обработки запроса и переключение входа/выхода.
На счет SNMP: есть у кого возможность сдампить обмен с модулем по этому протоколу?
Может действительно это какой никакой костыльный выход для любителей "быстрой езды".
Филоненко Владислав
27.12.2021, 07:01
1 мс овен на каком железе умеет? При каких условиях?
1 мс с внешним управлением по общепромышленным сетям редко кто на планете вообще может. И ещё меньше так делает!
Для задач движения (где такие времена и быстрее и встречаются) ставят отдельный контроллер движения, которому передают программу в G-кодах. А концевики и шаговики к нему напрямую.
И хотя я на ПЛК делал управление шаговиком с циклом 1 мс, и управление 12-ти фазным сварочным выпрямителем с контролем нуля и частотой 400Гц - но с тех пор я перестал заниматься такой хренью и использую внешние контроллеры. Т.к. внешний контроллер под одну задачу даже на ардуине-меге может быть быстрее и точнее общепромышленного ПЛК.
Филоненко Владислав
27.12.2021, 07:03
Да причём тут ОВЕН?
У меня вопрос - Вы вообще понимаете как работает TCP?
Какие 1 мс? хоспади, развели тут базар.
У вас латентность в сети будет около 1 мс, не говоря уже времени обработки запроса и переключение входа/выхода.
Женя, если в сети 2 устройства и тайминги настроить - 1 мс цикл запрос/ответ вполне реален. Проблема с Ethernet начинается когда все посылают запросы асинхронно и тогда возникают непредсказуемые паузы.
Но кому нужена сеть из 2-х устройств?
Филоненко Владислав
27.12.2021, 07:04
На счет SNMP: есть у кого возможность сдампить обмен с модулем по этому протоколу?
Может действительно это какой никакой костыльный выход для любителей "быстрой езды".
SNMP в силу своих особенностей будет медленнее ModBus TCP.
SNMP в силу своих особенностей будет медленнее ModBus TCP.
А можно чуть поподробнее про особенности( при беглом ознакомлении: UDP с простым содержимым и только)?
P.S. В упор не вижу каких то особенностей в самом SNMP, шли хоть 100 запросов в секунду.
Какой то пример обмена: https://packetlife.net/media/captures/SNMPv2c_get_requests.cap
Филоненко Владислав
27.12.2021, 12:26
Если Вам надо послать - то никакой разницы. А если надо ещё чтоб приняли, вовремя и ответили - то TCP понадёжнее.
Если Вам надо послать - то никакой разницы...
Быстрые выхода - уже пол дела.
...А если надо ещё чтоб приняли, вовремя и ответили - то TCP понадёжнее.
Вроде страниц 6 мусолили, что вовремя это как раз не про ТСР!
Филоненко Владислав
27.12.2021, 13:36
Быстрые выхода - уже пол дела.
Вроде страниц 6 мусолили, что вовремя это как раз не про ТСР!
не, Вы опять читали по диагонали!
Не важно TCP или UPD или вообще RAW-IP - сети плевать. Сети важно сколько мусора в ней.
Итак, был на объекте добавил, стандартное модбас устройство и регистры битовой маски выходов, в такой конфигурации при прямом управлении маской успевает отрабатывать 10Гц и даже быстрее. Если добавлять стандартный шаблон устройства, то не успевает по всей видимости из-за опроса большого количества регистров.
Таким образом тему можно считать закрытой, проблему решённой.
p.s. было бы неплохо иметь возможность в шаблонах устройств отключать ненужные каналы/регистры.
Powered by vBulletin® Version 4.2.3 Copyright © 2024 vBulletin Solutions, Inc. All rights reserved. Перевод: zCarot