Вид для печати
Скорость обмена по проприетарным протоколам сейчас не может угнаться за Ethernet. Валенок пытается сравнить доступ по Ethernet с Ростова до Архангельска, с соединением двух RS устройств в пределах цеха 300 метров. Иначе я не могу понять задержки более 300мс.Цитата:
Сообщение от pt200
У меня вся претензия именно к TCP( у Валенок предполагаю тоже).Цитата:
Сообщение от keysansa
В лабораторных условиях/на стенде/на столе все идет хорошо, но в реальном мире есть такое явление как потеря пакета, порождающая задержку и последующий автоматический ретрансмит( но сдается мне с достаточно приличными и покрутить мы их, вроде, не можем).
А так как у нас мастер в канале работает по принципу запрос/ответ, на fast retransmit можно не рассчитывать( который сглаживает проблему на больших/непрерывных потоках данных).
P.S. По моим сведениям большинство( если не все) real time протоколы не работают через TCP(наверное разработчики о чем то таком знали).
"Протокол TCP, хотя и стандартизирован для передачи RTP,[3] как правило не используется в RTP-приложениях, так как надежность передачи в TCP формирует временные задержки"( отсюда: https://ru.wikipedia.org/wiki/Real-t...sport_Protocol)
https://stackoverflow.com/questions/...stems/49471444
Keysansa пытается рассказывать о своих сновидениях ?Цитата:
Сообщение от keysansa
Цитируем или бла-бла ?
промышленный Ethernet (тот же EtherCat) не работает по TCP и требует соответствующего оборудования сети. О чем вы вообще? EtherCat не будет работать на линии между двумя городами.
Промышленный Ethernet - это и Ethercat, и Profinet и Powerlink и Modbus TCP. Все это поверх Ethernet.Цитата:
Сообщение от melky
У Валенок задежки в локальной сети до 300мс? Тогда ой.Цитата:
Сообщение от Валенок
Ну хоть десяток последних постов прочитайте. Какой реальный мир, о чем Вы ?Цитата:
Сообщение от pt200
Один от Ростова до Архангельска мериет видимо по экрану прикладывая дедушкин портновский метр (а как еще можно получить длину меньше упомянутой раза три ?)
Другой не может прочитать выше на несколько постов и начинает бла-бла как с чистого листа, и Вы туда же ?
TCP чем вас не устраивает? Подтверждением передачи? Уберите CRC в сообщении, TCP сам для пакета рассчитывает.Цитата:
Сообщение от pt200
ЗЫ. Потери пакетов (если вы не только в лаборатории работаете) возникают при отказе промежуточных узлов, и при перемаршрутизации линка (что возникает при тех же условиях). Изредка, такое наблюдается при превышении нагрузки (но вы же выбираете устройства с коммутационной матрицей, удовлетворяющих условиям ТЗ?). Попробуйте такое провернуть с 485.
Третий придумывает проблемы на ровном месте )Цитата:
Сообщение от Валенок
Третий (а еще четвертый, если канешна читали выше) просит гарантировать данные. На столе. Если проблемы решены. А в ответ - тишина.
При этом пятый в руки девайс не брал походу. Или, если брал, может что-то предоставить или просто поговорить пришел ? Третий этот модуль своими руками щупал года два назад если что.
TCP гарантирует "данные на столе".Цитата:
Сообщение от Валенок
ЗЫ. Но если у третьего в локальной сети отклики более 300мс - это проблемы не TCP, а третьего.
То есть можете поставить 50тыр как гарантию что на столе за несколько часов не будет ни одной задержки более 10мс ?
Я ставлю 5тыр, т.к. не продавец.
Быстрый выход плк на модуль ввода который читаем и сечем временные задержки.
Готовы ?
Плк с К у меня есть, у Вас видимо есть модуль, судя по уверенности и разговорчивости
Цитата:
Сообщение от Валенок
Вы как-то неровно относитесь к ситуации.
Заявляете о невозможности обмена менее 300мс, но на спор выдвигаете требования 10мс девиации.
Причем с моей стороны необходимо поставить 50тыр, а с вашей 5тыр.
Потому, что вы не продавец.
Данный спор не имеет смысла, т.к. скорость обмена по TCP зависит от очень огрмного кол-ва параметров. Сразу скажу ответ - стабильно 10 мс никогда, ни у одного производителя не будет. Именно поэтому и была разработана шина EtherCAT с минимальным временем отклика.Цитата:
Сообщение от Валенок
У себя же на столе при подключении точка-точка удавалось выжимать 5 мс на отклик (проверяли, считывая системное время из модуля, там гарантированно шаг 1мс+-1%). Но тут стоит ещё учитывать время цикла ПЛК, которое тоже плавает.
По поводу EtherCAT вы не правы, у них немного отличается топология на физ. уровне. Да, есть EtherCAT поверх классического Ethernet, только "кольца" вы в нём не получитеЦитата:
Сообщение от keysansa
Я кольца на классическом Ethernet могу получить, вопрос не в этом.Цитата:
Сообщение от e.filatov
Если поместить промоборудование в ту же сеть где и офис, смотрят нетфликс, работает 1C и пр - то потери пакетов есть неизбежная ситуация, никак просто не исправляемая. А если промоборудование в выделенной сети и там нет много широковещательных UDP - то всё очень быстро и качественно.Цитата:
Сообщение от pt200
Я правильно "услышал", что если изолированную(от офиса) пром сеть собрать исключительно из компонентов ОВЕН и при этом всю силу оставить "под боком"(а не в отдельном подземном бункере на удалении в километр), то потери пакетов ГАРАНТИРОВАНО исключены?Цитата:
Сообщение от Филоненко Владислав
P.S. Предполагаю изобрели новый "медный" тип связи которому по боку эти всякие EMI?
P.S.2 Что то в памяти всплывает история, про то, как аж целая релюшка клала сетевой интерфейс модуля на лопатки.
Вы услышали совсем не то. Поставьте сниффер и отмониторьте офисную сеть крупного предприятия. Там море левых пакетов.
При этом типичный процессор типа 107/207 STM реально может переварить до 1000, максимум 2000 пакетов в секунду без их пропусков из-за переполнения буфера. И вот в этих пропущенных пакетах могут быть Ваши запросы на чтение дискретного входа. А ретрансмиты обычно - это от 50 до 200мс ожидания "ну когда же мне ASK пришлют". Вот и считайте как перегруженная сеть превращает среднее время ответа 2 мс в провалы по 200 мс.
И тут либо ставить процессоры помощнее (CORE i5 по тестам хорошо держит шторм в линии на 100Мбитах), либо всё же физически разнести сети управления от офиса.
И что ещё хуже, пакеты обычно идут косяком, час тишина, а потом как 15 минут все заваливают друг друга данными.
Проблем в изолированной сети с обменом не наблюдали.
Поэтому то и на столе обычно проблем нет - т.к. с отдельной карты сеть поднимают, а на производстве: "Чего это мы будет отдельный кабель тянуть, это ж Интернет, он даже 4 к тянет, чего пару пакетов в секунду не пропустит?" Зато экономия.
P.S. непромышленные сети не являются сетями с гарантированной доставкой в заданное время. Но немного подумав это достижимо.
P.P.S. вот не надо, ставим рядом пускатель без RS-цепочек и вдруг проблемы. ВнеГОСТовские помехи прибор держать не обязан. А всё опять же, экономия на суппресорах!
Цитата:
Сообщение от Филоненко Владислав
0. Желательно точно в "граммах" для 100х/200х ПЛК (ТСР стеки то небось разные).
Я так и не понял: изолированная "овеновская" сеть( проложенная в типичном производстве) гарантирует на 100% целостность пакетов или все же допускает повреждения/потери пакетов?Цитата:
Сообщение от Филоненко Владислав
И если, все же, второй вариант, то интересно поведение системы( например для потери пакета с запросом от мастера(но и другие варианты тоже интересны)):
- Через сколько первый ретрансмит?
- Через сколько реконнект?
- Что будет делать мастер устройств при таймауте 10мс( а что будет делать modbus.lib(или как там ее))?
- Пошлет ли мастер устройств следующий запрос через 10мс или будет упорно ждать ответа(или разрыва соединения)?
- Получив следующий запрос без предыдущего модуль, по логике, должен выругаться и ТСР стек, по логике, прислать склеенный запрос: переварит ли их модуль?
- ....
Куча вопросов и так мало ответов
Т.е. интересуют какие то временные гарантии:
- детектирования проблемы со связью
- безопасного отката задания: что когда это все, все таки, разрулится через (20мин ?) модуль не включит, наконец то, выход(когда это делать уже категорически нельзя, иначе трах-тибидох)
P.S. Сейчас, конкретно мне, это больше для академического интереса.
Времена ретрансмитов обычно в диапазоне 50-200мс.
Мастер прождав 10мс будет посылать следующий запрос (тот же или другой зависит от настроек мастера)
Проблемы со связью можно отдетектировать по нескольким потерям связи. При этом смысла ставить таймаут в 10 мс никакого нет, быстрее не заработает. Сам протокол TCP - с гарантированной доставкой (но в не гарантированное время и с ограничением на это окно времени). Т.е. возможны 2 варианта:
а. потерян пакет, силами TCP соединение восстановлено (таймауты 50-200мс)
б. Соединене порвано (множественные потери или физическая потеря связи).
Соответственно для надёжной связи следует:
1. Выяснить таймауты (мин/макс) ответов приборов на длительном периоде и исходя из них выставлять таймауты мастера.
2. Если есть потери - это выяснится на тесте и либо надо устранить причины, либо поправить таймауты. Также можно включить режим повторов команд при срабатывании таймаута
3. Безопасный откат - ну термин странный для системы управления, есть защита от пропадания мастера (есть wathcdog мастера), а вот защиты от позднего прихода пакета не существует в обычной сети Ethernet - но можно избежать такого, убрав пропадания пакетов.
Также следует при проектировании системы учитывать реакцию модулей на команды - например Вы записываете новые настройки аналоговых входов - модуль начнёт их применять и некоторое время (минимум цикл опроса всех входов) значения с входов будут устаревшими/не соответствующими настройкам.
Вот как раз модуль 701-й под рукой был, решил "заснять" обмен.
Подключение через сеть компании, опрос с ПК Windows, 1 мастер TCP, пауза между запросами 0 мс.
В чем смысл проделанной работы: чтобы другие полюбовались как у кого то на его конкретной машине с конкретным софтом идет обмен пакетиками?Цитата:
Сообщение от e.filatov
Типовой ответ на опрос конкретного модуля составляет 3мс, а где гарантии что завтра не будет 4, а в полнолуние 400....?
Тема то вроде про около реалтайм на ОВЕНе(т.е. ПЛКашка(100/200) + модули)
P.S. Собственно ответить на это все могут только разрабы( драйвера сетевухи + сетевой стек + вероятно CS RT), если вдруг соблаговолят, да и то, сдается мне, им придется очень при очень плотно поковырять в исходниках!
pt200, я как раз и показывал свой кейс. Извините, но изучение принципов обмена по TCP даст ответы на все Ваши вопросы. Больше мне добавить нечего.Цитата:
Сообщение от pt200
P.S. Работа велась другая. Заснять обмен - 1 минута дела
Тоже предлагаю закончить эту беседу.
P.S. согласно RFC 6298 таймаут динамический(от "ping'a"), но не менее 1с. Но в среднем у линукса, например, делают от 200мс.
Вот и последние 3 страницы Вам и твердят, что прибор работает быстро, а если есть проблемы надо брать схему сети, сниффер и смотреть конкретно, т.к. проблемы не от прибора, у него секретного гиперканала к ПК фирмы ОВЕН нет, он пользуется Вашей сетью!Цитата:
Сообщение от pt200
А я на последних 3х страницах пытаюсь выяснить как же поведут себя Ваши приборы в нашинской(да и в Вашинской, получается,тоже(раз продаете железки без встроенного гиперканала)) простой земной сети, а слышу только, что:Цитата:
Сообщение от Филоненко Владислав
Наши устройства работают идеально!*
* при условии использования гиперканальной сети
А мы всё хотим схему сети и логи снифера|. Какие мы нехорошие! Нет бы взмахнуть волшебной палочкой!Цитата:
Сообщение от pt200
Перефразирую мое видение нашего плодотворного общения на таблетки:Цитата:
Сообщение от Филоненко Владислав
Я: а можно инструкцию вначале почитать: принцип действия, побочки, ...?
ОВЕН: А ты сначала прими, а потом расскажешь(самим интересно). А там подумаем как это устранять.
P.S. Мне "лечить" нечего(системы то нет). Вернее была давнишняя попытка, которая "слилась" по множеству причин(ОВЕН там тоже "постарался").
Просто пытаюсь добиться истины(что бы знать), на случай, если вдруг еще придется столкнуться.
А как вы потери пакетов мониторите? Собрали на столе из говна и палок и у вас связи нет?Цитата:
Сообщение от pt200
Я никак не мониторю(см. предыдущее сообщение), а вообще для этого в реальной сети используют TAPЦитата:
Сообщение от keysansa
Чем я вызвал Вашу агрессию?Цитата:
Сообщение от keysansa
Если знаете ответы на мои вопросы, ну подскажите убогому то, зачем сразу "на мыло".
т.е. никаких работ (и попыток) понять в чем же проблема, теряются ли пакеты и т.п. даже не предпринималось?
Я что то совсем запутался: так ОВЕН гарантирует 100% сохранность пакетов в их сетях? (только в этот раз четко: ДА / НЕТ)Цитата:
Сообщение от Филоненко Владислав
P.S. у других бывает(но, с другой стороны, они же не ОВЕН): https://www.youtube.com/watch?v=PPyUIuU-U9U
P.S2. просто если ДА, то у меня нет вопросов, кроме: зачем меня терроризировали бестолковыми расспросами последние ХХ страниц темы?
ну а если НЕТ, то зачем меня терроризировали бестолковыми расспросами последние ХХ страниц темы?
:)
Вы действительно запутались. Бывает.Цитата:
Сообщение от pt200
Сеть Ethernet со стеком протоколов TCP/IP не гарантирует ни доставку пакетов до получателя, ни временные характеристики такой доставки. За таким в Ethercat, к примеру.
Также ясно, что Вы лишь пытаетесь разжигать, решение проблемы, по видимому (да и была ли проблема вообще как и приборы ОВЕН у Вас) Вас не интересует. Интересует лишь хайп и антиреклама.
И так: ОВЕН, наконец то, не гарантирует доставку пакетов(не потребовалось и 100 страниц обсуждения), но что будет при потери не скажет(предполагаю, что теперь будет долгая песня про отрицание проблем с латентностью из за этого)Цитата:
Сообщение от Филоненко Владислав
P.S. Я, вроде как, пытаюсь выяснить что меня ждет, если столкнусь с этим(так как мы, наконец то, выяснили что вероятность такого совсем не 0).
Как я писал выше "про таблетки", я скорее из сознательных граждан, которые, по возможности, стараются не совать в рот непонятно чего, а потом бежать с мольбами о помощи к производителю и если это называется "хайп и антиреклама" то прошу пардону.Цитата:
Сообщение от Филоненко Владислав
P.S2 Кстати этот самый Modbus TCP есть не только у ОВЕНА, вроде еще ICP DAS/MOXA/куча китайцев с алика припоминается, а то еще заявите что ОВЕН дискриминирую(у меня скорее от заявления, что "Modbus TCP чудесен для RT" глаз дергаться начинает и все)
P.S3 Так я давно еще предлагал закругляться по этой теме(вроде всем все понятно)?!
Здравствуйте, признание ОВЕН соответствует стандартам сети Ethernet. Ваш телефон не гарантирует Вам доставку сообщений в мессенджерах еще и с детерминированным временем. Для этого великие умы разрабатывают новый стандарт, он называется Time Sensitive Network. (https://ru.wikipedia.org/wiki/TSN). Мы внимательно следим за развитием этих спецификаций и постараемся использовать данную технологию когда она перейдет из статуса draft в статус спецификации.Цитата:
Сообщение от pt200
Так же отвечу Вам что произойдёт при потере пакета. В приборах Мх210 есть параметр: тайм-аут перехода в безопасное состояние. Если прибор не будет получать запросов от мастера более чем преднастроено в тайм-ауте, он перейдёт в безопасный режим. Об этом подробно указано в руководстве эксплуатации.
Здравствуйте, приятно слышать что работаете над ситуацией.Цитата:
Сообщение от Андрей Горский
Насколько помню время это задается в секундах(т.е. минимум 1000мс, да и не особо важно), а в начале темы говорилось(с чего все это и началось) что очень вероятны проблемы при временах единицы-десятки мс(микромир так сказать) и вот с ними имеется боооольшая неопределенность на данный момент:Цитата:
Сообщение от Андрей Горский
1) ретрансмиты от ТСР
2) таймауты от мастера
P.S. То что температуру на улице можно измерять этими модулями без проблем "раз в 5 минут", я никогда и не отрицал.
Я задал вопрос, никакой агрессии. В ответ на ваш вопрос.Цитата:
Сообщение от pt200
Вот, что я процитировал:
Если вы считаете (как из вашего сообщения следует), что пакеты теряются, я решил узнать, как вы измеряете потерю пакетов. Если вы их не измеряете, зачем тут ГАРАНТИРОВАНО?Цитата:
Сообщение от pt200
ЗЫ. Выше "я никак не мониторю", пропущу пока...
Правильно ли я понимаю, что выходит, что при прямом управлении битовой маской, можно без особого труда достигнуть частоты в 10 Гц?Цитата:
Сообщение от e.filatov
Просто у меня пока нет возможности проверить это на живом оборудовании, на объекте идут монтажные работы, а до объекта 200 км. Но в связке на столе плк200+кабель 50 см+мк210-311 стандартным способом при добавлении шаблона устройства у меня не получалось быстрее 4 Гц щёлкать выходами. Просто добавить один регистр битовой маски я ещё не пробовал.
Если вы можете это проверить и достоверно утверждать, что плк200 может щёлкать выходами модуля со скоростью срабатывания реле, то тему можно считать закрытой.
Parovoz, рекомендую, так же, указывать временные параметры сигнала(допуски: скважность, джиттер), а то 10Гц очень расплывчато:
например 9 импульсов по 50/50мс + 1 импульс 90/10мс за секунду устроит?
P.S. Мой ответ(от мимо проходил) МОЖНО, но вот насколько это будет стабильно "обсуждаем" последние ХХ страниц темы