Segnetics

Вернуться   Segnetics > Форум Segnetics > Вопросы о Matrix

Вопросы о Matrix Работа и применение контроллеров Matrix.

Ответ
 
Опции темы Поиск в этой теме Опции просмотра
Старый 31.10.2019, 21:53   #121
ujin
Senior Member
 
Аватара для ujin
 
Регистрация: May 2010
Адрес: Novosibirsk
Сообщения: 762
Благодарил(а): 1 раз(а)
Поблагодарили: 10 раз(а) в 10 сообщениях
По умолчанию Ответ: Функционал

Цитата
Сообщение от Gel Посмотреть сообщение
Кроме этого, свитчи (во всяком случае, обычные), не в курсе ни про какой TCP/IP и не занимаются ожиданиями, TCP-подключениями или чем-то подобным. Задача свичка -- получить Ethernet-пакет с одного порта и тупо переслать его на другой порт или порты.
Я попробовал разбираться с этим, получил информацию, что пакеты дробятся на фреймы, перемешиваются, отправляются в случайном порядке при приеме оправляется квитанция, если фрейм не получен, он повторяется далее фреймы склеиваются назад в пакеты. Получается логично если связь от свича к модулю плохая у него должен забиваться буфер. Так же прямо написано, что если нет физического коннекта так же данные будут попадать в буфер. Просмотр сетевого трафика Wireshark'ом подтверждает, что пакеты в свич отправляются даже при отключенном модуле, при условии что ранее было установлено TCP соединение с этим модулем.
Под ожиданием я подразумеваю не ожидание ответа на TCP запрос, а ожидание квитанции на фреймы. Подробно долго было расписывать. Вам, как специалистам режет глаз.
Плюс такие параметры даже простого промышленного свича вроде IEEE 802.3x flow control, back pressure flow control говорят(?) о том, что поток свичем контролируется.
Далее у нас часто повторяется ситуация - отключаются модули (снимаются вместе с частью оборудования).
При этом если продолжать отправлять запросы по MODBUS TCP при подключении модуля и попытке с ним сделать еще одно соединение модуль не отвечает. Что логично так как для этого мак адреса (или вообще) буфер забит. Физическое соединение компа со свичем не нарушаем.
Как только подаем запрос закрыть ТСP соединение с этим модулем, с этого же компьютера или с другого а затем подаем запрос на новое ТСР соединение, оно всегда выполняется и данные начинают поступать на запросы. Из чего у меня получается только один вывод Свич чуть умнее, и контролирует уже часть 3 уровня. Попытки разобраться заводят в конкретные дебри.
А managed свичи уже прямо пишут Typically the switch detects and recovers from a copper link failure within approximately 20 ms – for the majority of applications a seamless process. Modbus/TCP, Modbus/RTU and OPC supported. При этом считают свичем 2 уровня.
Упрощенное представление в итоге ответ не дает. Но способ работает. даже единичные сбои полностью прекратились после реконнекта при любой ошибке и использования поля Transaction ID в MODBUS TCP.
Вы предлагаете такой же способ. Все должно быть нормально, если ненормально реконнект. В этом пункте я с Вами заранее был согласен.
Но не все так делают.
Много текста, если прореживать, становится непонятно.


Добавлено через 12 минут

Цитата
Сообщение от ATS Посмотреть сообщение
Может это пригодится?
Там и ещё есть на что посмотреть.
Спасибо, но конечно же не мог не видеть.


__________________
В жизни 2 правила успеха:
1 Не говори всего что знаешь
2 ...
ujin вне форума   Ответить с цитированием
Старый 31.10.2019, 23:19   #122
Gel
Senior Member
 
Регистрация: Nov 2017
Сообщения: 563
Благодарил(а): 3 раз(а)
Поблагодарили: 38 раз(а) в 30 сообщениях
По умолчанию Ответ: Функционал

Цитата:
Сообщение от ujin Посмотреть сообщение
Я попробовал разбираться с этим, получил информацию, что пакеты дробятся на фреймы, перемешиваются, отправляются в случайном порядке при приеме оправляется квитанция, если фрейм не получен, он повторяется далее фреймы склеиваются назад в пакеты. Получается логично если связь от свича к модулю плохая у него должен забиваться буфер.
Совсем не логично.

Данные при использовании TCP разбиваются на пакеты (если надо) TCP/IP стеком отправителя, обратно собираются TCP/IP стеком получателя. Между отправителем и получателем в локальной сети данные ходят в виде Ehernet-фреймов, которые имеют MAC-адрес отправителя, MAC-адрес получателя, что-то и контрольную сумму этого чего-то.

Все, задача свитча взять MAC-адрес получателя и отправить в его сторону пакет или выбросить. В "что-то" свитч не лезет от слова совсем. На уровне Ehernet-фреймов никаких квитков нет и отправитель Ehernet-фрейма не в курсе, получил его кто-то или нет.

Буферов у свитча два типа: 1) для хранения базы MAC-адресов; 2) для очереди отправки пакетов. На эту очередь отправки плохая связь не влияет, потому что свитчу (как и сетевой карте) все равно, получил ли кто-то переданный пакет или нет.

Цитата Так же прямо написано, что если нет физического коннекта так же данные будут попадать в буфер.
Где такое написано?

Цитата Просмотр сетевого трафика Wireshark'ом подтверждает, что пакеты в свитч отправляются даже при отключенном модуле, при условии что ранее было установлено TCP соединение с этим модулем.
Пакеты отправляются, потому что сетевая карта и TCP/IP стек не знает, что получатель пропал или что-то с ним случилось.

Цитата Под ожиданием я подразумеваю не ожидание ответа на TCP запрос, а ожидание квитанции на фреймы.
Никаких квитанций на Ethernet-фреймы нет.

Цитата Плюс такие параметры даже простого промышленного свича вроде IEEE 802.3x flow control, back pressure flow control говорят(?) о том, что поток свичем контролируется.
Это контролируется скорость отправки, а не доставка данных. Это вообще другое.

Цитата Далее у нас часто повторяется ситуация - отключаются модули (снимаются вместе с частью оборудования).
При этом если продолжать отправлять запросы по MODBUS TCP при подключении модуля и попытке с ним сделать еще одно соединение модуль не отвечает. Что логично так как для этого мак адреса (или вообще) буфер забит. Физическое соединение компа со свитчем не нарушаем.
Тут я не понял. Отключили модуль и пытаетесь к нему подключиться, не получается, и вы вините в этом мифический буфер?

Так если модуль отключен, с чего вдруг с ним будет соединение?

Если, на самом деле, с модулем нельзя установить два соединения, то это особенность реализации TCP/IP стэка этого модуля. Вот такая простая реализация, что поддерживает только одно соединение. Возможно, устройство содержит "аппаратную реализацию" TCP/IP, например, в виде микросхемы W5500, которая имеет ограничение по количеству подключений.

Никакого отношения это к свитчу не имеет.

Цитата А managed свитчи уже прямо пишут Typically the switch detects and recovers from a copper link failure within approximately 20 ms – for the majority of applications a seamless process. Modbus/TCP, Modbus/RTU and OPC supported.
Так а вы откуда знаете, что здесь имеется в виду, если это не описано? Может быть все, что угодно.

"Modbus/TCP, Modbus/RTU and OPC supported." -- это что, про настройку свитча? Какое разница, как настраивается свитч?
Gel вне форума   Ответить с цитированием
Старый 01.11.2019, 00:46   #123
ujin
Senior Member
 
Аватара для ujin
 
Регистрация: May 2010
Адрес: Novosibirsk
Сообщения: 762
Благодарил(а): 1 раз(а)
Поблагодарили: 10 раз(а) в 10 сообщениях
По умолчанию Ответ: Функционал

Цитата
Сообщение от Gel Посмотреть сообщение
Где такое написано?
Когда разбирался ссылка была на книгу Методы передачи данных канального уровня. Получается общие примеры
Цитата
Сообщение от Gel Посмотреть сообщение
Тут я не понял. Отключили модуль и пытаетесь к нему подключиться, не получается, и вы вините в этом мифический буфер?
Так если модуль отключен, с чего вдруг с ним будет соединение?
Подключаю модуль, соединяюсь по TCP. Отключаю модуль от свича (имитирую нарушение соединения). Подключаю обратно. Пытаюсь сделать еще одно TCP соединение с модулем. Соединение не устанавливается. Делаю запрос на закрытие TCP соединения.
Повторное соединение устанавливается.
В нормальном режиме устанавливается не менее десяти TCP соединений с разных компьютеров, и не менее 3х с одного.
Один запрос на закрытие TCP соединения волшебным образом все сбрасывает и это мне непонятно как если не анализировать пакеты.
Так же если подождать примерно 3 минуты без обмена (не передавая запрос на закрытие TCP соединения так же все сбрасывается. И опять можно соединяться. Можно объяснить TTL или ?.
Перепутывание пакетов. Ответ на первый TCP запрос приходит вторым. Это можно объяснить потерей пакета и повторной передачей в то время как второй пакет прошел без задержки.
Придется еще раз перепроверять.


__________________
В жизни 2 правила успеха:
1 Не говори всего что знаешь
2 ...
ujin вне форума   Ответить с цитированием
Старый 01.11.2019, 08:56   #124
Gel
Senior Member
 
Регистрация: Nov 2017
Сообщения: 563
Благодарил(а): 3 раз(а)
Поблагодарили: 38 раз(а) в 30 сообщениях
По умолчанию Ответ: Функционал

Цитата:
Сообщение от ujin Посмотреть сообщение
Когда разбирался ссылка была на книгу Методы
передачи данных канального уровня. Получается общие примеры
Перечитайте еще раз, видимо, не так поняли. Или приведите фрагмент или ссылку, разберем вместе.

Цитата Подключаю модуль, соединяюсь по TCP. Отключаю модуль от свича (имитирую нарушение соединения). Подключаю обратно. Пытаюсь сделать еще одно TCP соединение с модулем. Соединение не устанавливается.
Не должно такого быть.

Или вы что-то важное не договариваете, или в реальности такого просто нет.

Цитата Можно объяснить TTL или ?.
TTL -- это вообще из другой оперы и не имеет отношение к таймаутам или времени (хотя в аббревиатуре одна из T -- time, но time в английском языке имеет и другие значения, не только "время").

Я вижу, что вы в тех местах, где что-то не поняли, много себе нафантазировали.
Gel вне форума   Ответить с цитированием
Старый 01.11.2019, 10:28   #125
ujin
Senior Member
 
Аватара для ujin
 
Регистрация: May 2010
Адрес: Novosibirsk
Сообщения: 762
Благодарил(а): 1 раз(а)
Поблагодарили: 10 раз(а) в 10 сообщениях
По умолчанию Ответ: Функционал

Цитата
Сообщение от Gel Посмотреть сообщение
Перечитайте еще раз, видимо, не так поняли. Или приведите фрагмент или ссылку, разберем вместе.
Из этого источника только Методы передачи данных канального уровня. главы Дискретное кодирование данных и Обнаружение и коррекция ошибок. Пять листов. Там могут быть просто теоретические данные.
Проверил современные источники
"...Канальный уровень (англ. data link layer) предназначен для обеспечения взаимодействия сетей на физическом уровне и контроля ошибок, которые могут возникнуть. Полученные с физического уровня данные, представленные в битах, он упаковывает в кадры, проверяет их на целостность и, если нужно, исправляет ошибки (формирует повторный запрос повреждённого кадра) и отправляет на сетевой уровень. Канальный уровень может взаимодействовать с одним или несколькими физическими уровнями, контролируя и управляя этим взаимодействием...
На этом уровне работают коммутаторы, мосты и другие устройства. Эти устройства используют адресацию второго уровня (по номеру уровня в модели OSI). ..."
Трудно интерпретировать иначе как на этом уровне есть подтверждение получения
https://ru.wikipedia.org/wiki/Сетевая_модель_OSI

"...Буфер памяти может использовать два метода хранения и отправки фреймов: буферизация по портам и буферизация с общей памятью. При буферизации по портам пакеты хранятся в очередях (queue), которые связаны с отдельными входными портами. Пакет передаётся на выходной порт только тогда, когда все фреймы, находившиеся впереди него в очереди, были успешно переданы. ..."
https://ru.wikipedia.org/wiki/Сетевой_коммутатор
На мой взгляд подтверждает правильность моего вольного изложения.
Ваше описание более упрощенное. В нем не просматривается возможность ошибок.
Цитата
Сообщение от Gel Посмотреть сообщение
Не должно такого быть.
Или вы что-то важное не договариваете, или в реальности такого просто нет.
Я точно что-то недоговариваю. Это все по памяти. Буду перепроверять.
Цитата
Сообщение от Gel Посмотреть сообщение
Я вижу, что вы в тех местах, где что-то не поняли, много себе нафантазировали.
Согласен. Подправлю знания с Вашей помощью. За это спасибо. Здесь главное, что Ethernet можно и нужно использовать. Есть промышленные протоколы на его основе. Чтобы использовать не нужно лезть глубоко. Главное иметь правильное оборудование и правильное ПО.
Кстати Вы упоминали про дуракоустойчивость. На этом форуме не припомню, чтобы обсуждалось как обжать RJ-45. А как подключить RS-485 много раз.


__________________
В жизни 2 правила успеха:
1 Не говори всего что знаешь
2 ...
ujin вне форума   Ответить с цитированием
Старый 01.11.2019, 11:30   #126
Gel
Senior Member
 
Регистрация: Nov 2017
Сообщения: 563
Благодарил(а): 3 раз(а)
Поблагодарили: 38 раз(а) в 30 сообщениях
По умолчанию Ответ: Религиозные споры про то и про сё

Цитата "...Буфер памяти может использовать два метода хранения и отправки фреймов: буферизация по портам и буферизация с общей памятью. При буферизации по портам пакеты хранятся в очередях (queue), которые связаны с отдельными входными портами. Пакет передаётся на выходной порт только тогда, когда все фреймы, находившиеся впереди него в очереди, были успешно переданы. ..."

https://ru.wikipedia.org/wiki/Сетевой_коммутатор

На мой взгляд подтверждает правильность моего вольного изложения.
Здесь имеется в виду совсем не то, что вы подумали.

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

Понятно, что данные в очереди расходуются со скоростью отправки данных, т.е. для сети 100 мегабит это будет примерно от 8000 тыс. до 100 тысяч пакетов в секунду, в зависимости от их размера.

Это совсем не то, что "свитч держит пакет в памяти, пока не убедится, что его принял получатель". Ничего подобного в свитче нет.
Gel вне форума   Ответить с цитированием
Старый 05.11.2019, 00:06   #127
Gromov
Уволен из Сегнетикс
 
Регистрация: Nov 2015
Адрес: CПб/ВЛГ
Сообщения: 0
Благодарил(а): 0 раз(а)
Поблагодарили: 1 раз в 1 сообщении
По умолчанию Ответ: Религиозные споры про то и про сё

ОМГ Вот это жирную тему я пропустил! =)
Вообще, не буду, конечно, тыкать пальцами, и кого-то в чём-то обвинять. В моих словах каждый найдёт что-нибудь про себя. За исключением людей, кого я назову по именам.

Не понимаю предъяв в сторону Арсения и идеологии/вектора развития лоджика или ещё чего-то. Я с ним работал достаточно, чтобы понимать, когда он спрашивает вас "зачем вам это нужно" - это не подразумевает "вам это не нужно". Я уверен, за этими вопросам где-нибудь ещё теплится надежда, что может быть хотя бы в этот раз будет действительно веская причина. Но в миллионный раз оказывается, что это не так уж и нужно.
Более того, я видел несколько случаев, за время работы в техподдержке, когда клиент объяснял, зачем ему это нужно, и это делали. Либо внедряли в функционал, либо делали специально для него что-то. Это редкие случаи, потому что большинству людей нечего ответить на вопрос "зачем?".

Читал про лабвью, и думал "наверное, солидный софт, много хорошего.". Потом увидел видео, пошел - посмотрел ещё, и теперь думаю "ну и дер....". Как будто школьники делали. И за это ещё деньги просят. Поразительно. В сфере промышленной автоматизации не хватает новых технологий. Лабвью застрял в 98ом году. Моё мнение, конечно.

Что касается протягивания связей. Ну а как вы хотите построить большую систему? Вы рассуждаете тут про считывание сигналов с миллиона квадриллионов датчиков и какое-то там логгирование. А кто все эти датчики подключать будет? А кто их купит? А кто дуодециллион проводов обожмёт? Так неужели вам сложно тыщу раз ткнуть мышкой?
А, я забыл "время программиста дороже времени <кого угодно>". Время разработки и так далее. Да-да. Не надо переоценивать свою важность. Программировать может каждый. А провода подключать нет.

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

Протянуть тысячу связей - не проблема. Наливается чай, включается музыка, 20 минут медитации и готово. За это время можно как следует подумать, всё ли у вас хорошо в архитектуре, если приходится протягивать такое количество связей. Потому что если не хорошо - придётся удалить и протянуть другую тысячу.

Циклы, массивы, строки... Циклы, де факто, есть. Де юре, конечно, нету, но посмотрите в макросы конструктора хвак и увидите их. Это запрещённые технологии. Кому они нужны - тот знает как их достать. Если человек знает, как их достать, я считаю, он достоин их использовать. Т.е. он не "пьёт из лужи" и ногу себе не отстрелит этими циклами. Может быть. Если нет понимания, как их заполучить - то и применять их рано. Простой фильтр, но работает. За время работы в техподдержке я видел огромную кучу "инженеров-программистов", которым лучше бы вообще держаться по дальше от компьютеров. Но они, к сожалению, вынуждены программировать контроллеры. Если в их руках окажутся циклы, то живые позавидуют мёртвым.
Массивы - сложнее. В том виде, в котором о них говорится (множество связей в одну) они точно не нужны. В некотором ничё так виде - они есть в smhistory ну или просто в array.
Со строками - соглашусь. С развитием экранов и сенсорного ввода, лично мне, уже довольно часто приходится делать программы с видимым ограничением, выраженном в отсутствии динамических строк. В рамках местечковой автоматизации (автоматизация конкретной установки) - можно и без этого обойтись, можно просто заготовить сотню-другую строк на любой вкус и вкидывать нужную. Но в рамках адаптивных проектов, где желательно поменять название того или иного элемента, потому что объект может быть один или другой, или где надо вводить имя пользователя, или вести учёт пользователей с именами собственными - приходится уходить от лоджика или от сегнетикса. А жаль, ведь трим, так-то, может и с этим справиться.

Ну и особенно меня повеселили фразы типа "тогда покажите, как в лоджике/матриксе сделать вот так и вот так!". Во-первых, многое из этого реально можно сделать на матриксе, вопрос всё тот же - зачем? Во-вторых, тут уже говорили об этом, для всего есть свои инструменты. У матрикса свои задачи и он с объявленными цифрами справится (скорее всего).

А подход "я собрал из блоков, пока работает" - очень опасный. Ракета Ариан 5 взорвалась при взлёте из-за того, что программисты собрали программу из готовых блоков, где "чему тут ломаться?". Блоки от ракеты ариан 4. Но в какой-то момент использовали преобразование double в int, а этот int переполнился и горизонтальная скорость ракеты стала отрицательной. Блок инерциальной системы ориентирования решил срочно маневрировать и на 37ой секунде полёта вывел ракету на запредельную траекторию. Корпус попал под воздействие чрезвычайных аэродинамических нагрузок и стал разрушаться. На 40 секунде произошло самоуничтожение ракеты. Это был первый запуск Ариан-5. Это событие названо одной из крупнейших компьютерных ошибок в истории. Только материальные потери составили около $500 млн. И это в 1996ом году. На современные деньги будет ещё печальнее.


__________________
В сегнетиксе не работаю с самого начала 2019 года.

Последний раз редактировалось Arsie, 03.12.2020 в 12:59
Gromov вне форума   Ответить с цитированием
Старый 05.11.2019, 08:29   #128
gcvdsv
Senior Member
 
Регистрация: Dec 2015
Сообщения: 119
Благодарил(а): 23 раз(а)
Поблагодарили: 4 раз(а) в 4 сообщениях
По умолчанию Ответ: Религиозные споры про то и про сё

Цитата
Сообщение от Gromov Посмотреть сообщение
Что касается протягивания связей. Ну а как вы хотите построить большую систему? Вы рассуждаете тут про считывание сигналов с миллиона квадриллионов датчиков и какое-то там логгирование. А кто все эти датчики подключать будет? А кто их купит? А кто дуодециллион проводов обожмёт? Так неужели вам сложно тыщу раз ткнуть мышкой?
А, я забыл "время программиста дороже времени <кого угодно>". Время разработки и так далее. Да-да. Не надо переоценивать свою важность. Программировать может каждый. А провода подключать нет.
Суть просьб заключается в том, что бы сделать процесс проще. А самое главное что эти просьбы хотя бы читают, ведь если не просить то ничего не получишь. Почему бы и нет, что бы соединить структуры,макросы одной связью ? Даже если их придется куда то завести первый раз, один раз 1000 связей сделать проблем нет, а как вы написали, в случае ошибки придется делать заново.
1000 связей же откуда то выходят и куда то входят, а дальше надо эти 1000 еше куда то вывести. То есть есть вероятность что количество связей только увеличится

В конфигураторе FMR например можно выбрать все AIN и сразу для всех задать нужный режим, время фильтрации, тип датчика. С такой идеологией можно было бы убрать групповые операции и оставить только конфигурацию по одному.

Сравнивать с подключением этих самых проводов некорректно, так как такие объемы монтажа делает не один человек, да и делается это один раз.
Тоже самое и с покупкой, в запросе на счет указывают количество, хотя можно конечно и по одному датчику запрашивать счет
gcvdsv вне форума   Ответить с цитированием
Старый 05.11.2019, 11:01   #129
Ilya J.
Сотрудник Сегнетикс
 
Аватара для Ilya J.
 
Регистрация: Mar 2016
Адрес: SPb
Сообщения: 4 302
Благодарил(а): 0 раз(а)
Поблагодарили: 254 раз(а) в 250 сообщениях
По умолчанию Ответ: Религиозные споры про то и про сё

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


__________________
Если ничто другое не помогает, прочтите, наконец, инструкцию
Ilya J. вне форума   Ответить с цитированием
Старый 05.11.2019, 15:32   #130
ujin
Senior Member
 
Аватара для ujin
 
Регистрация: May 2010
Адрес: Novosibirsk
Сообщения: 762
Благодарил(а): 1 раз(а)
Поблагодарили: 10 раз(а) в 10 сообщениях
По умолчанию Ответ: Религиозные споры про то и про сё

Цитата
Сообщение от Gel Посмотреть сообщение
Здесь имеется в виду совсем не то, что вы подумали.

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

Понятно, что данные в очереди расходуются со скоростью отправки данных, т.е. для сети 100 мегабит это будет примерно от 8000 тыс. до 100 тысяч пакетов в секунду, в зависимости от их размера.

Это совсем не то, что "свитч держит пакет в памяти, пока не убедится, что его принял получатель". Ничего подобного в свитче нет.
Спасибо. Начинаю помаленьку разбираться
Разделил циклы записи запроса MODBUS TCP (такт 100 мс) и чтения ответа (такт 50 мс)
При отключении кабеля от модуля ввода вывода данные сразу перестают поступать. Запись продолжается еще примерно 20 с.
Далее запись в порт прекращается.
Если в течении 15 с подключить кабель, передача данных восстанавливается.
При отключении чтения ответов запись запросов идет еще некоторое время (минуты).
Примерно через 1,5 минуты происходит сбой обмена по 2 параллельному каналу. Чтение по этому каналу не отключалось.
Примерно через 3 минуты происходит сбой и по 1 каналу.
Если не доводить до сбоя, то при включении чтения данные приходят старые, пока не вычитать все данные из буфера. Фокус в том, что если данные читать симметрично с запросами они всегда будут старые.

Вывод все-равно остается тот-же. Сбои обмена возможны.
Свич так же может задержать данные по причине неуспешности доставки. Это точно либо потеря несущей либо ошибка в CRC пакета.
Плюс сетевая карта модуля (согласно описания) может запросить повтор пакета от свича при ошибке CRC это как раз функции 2 уровня.
Буфер свича в данном случае ни при чем. Задержку дает скорее всего буфер сетевой карты или драйвера.
Старые данные приходить могут. Данные перепутываться могут. Задержка накапливаться может.
Transaction ID запроса контролировать нужно.
Способ закрыть TCP соединение открыть снова при любом сбое, ошибке таймаута и несовпадении Transaction ID правильный.
Не смог повторить сбой повторного соединения.
Видимо в заводском OPC сервере при неустановлении TCP соединения не производится посылка закрытия TCP соединения (несмотря на неуспешность). В этом случае возможно (учитывая буфер) полностью заблокировать модуль ввода вывода.

Неправильно определен источник в виде свича. И неправильно думал, что на 2 уровне есть квитанции на подтверждение получения пакета.

В этом описании ошибки больше не вижу. Инструмент под рукой, можно еще потестировать.


__________________
В жизни 2 правила успеха:
1 Не говори всего что знаешь
2 ...
ujin вне форума   Ответить с цитированием
Старый 05.11.2019, 16:46   #131
Gel
Senior Member
 
Регистрация: Nov 2017
Сообщения: 563
Благодарил(а): 3 раз(а)
Поблагодарили: 38 раз(а) в 30 сообщениях
По умолчанию Ответ: Религиозные споры про то и про сё

Если бы мне пришлось что-то делать интенсивное и критичное ко времени с использованием MODBUS поверх Ethernet, то я бы в первую очередь сделал реализацию на MODBUS/UDP.

Это, с точки зрения логики алгоритма, получается гораздо проще:

1. Нет никаких коннектов.

2. Два основных случая: либо мы получаем ответ максимально быстро, либо совсем не получаем.

3. Если какой-то процент данных не будет доходить, то этим можно не заморачиваться (все равно идет интенсивный опрос).

В случае ошибки, приведшей к повторной передаче данных с использованием TCP (и без поддержки штампа времени со стороны устройства) все равно не определить, а какому-же они моменту времени соответствуют.

Поэтому подумайте. Возможно, с использованием MODBUS/UDP у вас система будет намного-намного проще и предсказуемее.

Последний раз редактировалось Gel, 05.11.2019 в 17:01
Gel вне форума   Ответить с цитированием
Старый 05.11.2019, 16:51   #132
ujin
Senior Member
 
Аватара для ujin
 
Регистрация: May 2010
Адрес: Novosibirsk
Сообщения: 762
Благодарил(а): 1 раз(а)
Поблагодарили: 10 раз(а) в 10 сообщениях
По умолчанию Ответ: Религиозные споры про то и про сё

Цитата
Сообщение от Gromov Посмотреть сообщение
"зачем?"...
Читал про лабвью...
увидел видео...Лабвью застрял в 98ом году.
...в кратчайшие сроки,
...Если в их руках окажутся циклы, то живые позавидуют мёртвым.
А подход "я собрал из блоков, пока работает" - очень опасный. Ракета Ариан 5 взорвалась .
1. Предложение учесть возможные ошибки при преобразованиях из беззнаковых в знаковые типы с меньшей разрядностью.
2. Возможно стоит ввести тип string
3. Не стоит внедрять мои предложения так как это никому не нужно и, более того, опасно.
Извините, но это вся полезная информация. Никто скорее всего и не собирается ничего внедрять. Так пустая болтовня не первый раз.
Польза похоже только для меня: много хорошей критики, выявлены ошибки, недостатки в знаниях. Несколько новых идей.
Ваше представление о Labview точно ошибочно. Думаю стоит уделить ознакомлению по форумам и на сайте NI хотя бы пару дней. Много новых идей. Не призываю использовать, это как источник некоторых полезных идей для ускорения внедрения новых нестандартных изделий. А это фактически все, что не охватывается конструктором.


__________________
В жизни 2 правила успеха:
1 Не говори всего что знаешь
2 ...
ujin вне форума   Ответить с цитированием
Старый 06.11.2019, 05:49   #133
ujin
Senior Member
 
Аватара для ujin
 
Регистрация: May 2010
Адрес: Novosibirsk
Сообщения: 762
Благодарил(а): 1 раз(а)
Поблагодарили: 10 раз(а) в 10 сообщениях
По умолчанию Ответ: Религиозные споры про то и про сё

Цитата
Сообщение от Gromov Посмотреть сообщение
Протянуть тысячу связей - не проблема. Наливается чай, включается музыка, 20 минут медитации и готово. За это время можно как следует подумать.
Предложите кому-нибудь на С заменить double a[]; на double a1, a2, a3, ... a1000;
И какую либо функцию повторить 1000 раз копипастом. С заменой названия переменной.
Кроме Майка Науменко с его
"Ежели у вас чагой-то там не так,
То медитация уж враз поможет вам"
на ум больше ничего не приходит.
Цитата
Сообщение от Gromov Посмотреть сообщение
справится (скорее всего).
Осталось попробовать такие цифры несколько раз на реальном объекте.
Вот тут философия закончится. И начнут западать кнопки Ctrl, c, v.
Цитата
Сообщение от Gromov Посмотреть сообщение
А подход "я собрал из блоков, пока работает" - очень опасный.
double в int, а этот int переполнился
Проверил преобразование из double в int работает корректно. При любом положительном числе больше чем 2147483647 выдает 2147483647
при отрицательном числе -2147483648
Вертикальное ускорение в кочегарке останется в норме (0).
Я Вам про приточки, ИТП, максимум котельные. SIL0


__________________
В жизни 2 правила успеха:
1 Не говори всего что знаешь
2 ...
ujin вне форума   Ответить с цитированием
Старый 06.11.2019, 16:22   #134
Gromov
Уволен из Сегнетикс
 
Регистрация: Nov 2015
Адрес: CПб/ВЛГ
Сообщения: 0
Благодарил(а): 0 раз(а)
Поблагодарили: 1 раз в 1 сообщении
По умолчанию Ответ: Религиозные споры про то и про сё

Цитата:
Сообщение от ujin Посмотреть сообщение
Предложите кому-нибудь на С заменить double a[]; на double a1, a2, a3, ... a1000;
И какую либо функцию повторить 1000 раз копипастом. С заменой названия переменной.
На то оно и графическое программирование, а не текстовое. Это же не абстрактные какие-то данные. Это результаты измерений, датчиков или ещё чего-то. И всё это, на каком-то этапе, существует отдельно. И вообще это могут быть вполне себе отдельные сущности.
Я сейчас делаю программу, в которой 10 фмров используется, с каскадом, т.е. по сути, 20. Выходит 16 входов и 8 +24 выхода, итого 48 на блок. 480 входов/выходов. И да, эти связи надо протягивать. Более того, в моей программе каждый вход и каждый выход может иметь назначаемую функцию с экрана трима. Так что связей ещё несколько больше. Ну а что поделать? Модули-то настоящие.


Цитата:
Сообщение от ujin Посмотреть сообщение
Проверил преобразование из double в int работает корректно. При любом положительном числе больше чем 2147483647 выдает 2147483647
при отрицательном числе -2147483648
Вертикальное ускорение в кочегарке останется в норме (0).
У вас int 32-разрядный, а у них было преобразование в 16-разрядный int, который не может принять значение в 2 миллиарда. максимум 65535 для беззнакового и 32767 для знакового.


__________________
В сегнетиксе не работаю с самого начала 2019 года.
Gromov вне форума   Ответить с цитированием
Старый 14.11.2019, 10:00   #135
Shurion
Senior Member
 
Регистрация: Sep 2019
Адрес: SPb
Сообщения: 176
Благодарил(а): 12 раз(а)
Поблагодарили: 18 раз(а) в 18 сообщениях
По умолчанию Ответ: Религиозные споры про то и про сё

Это конец моего любимого сериала или затишье перед бурей?
Shurion вне форума   Ответить с цитированием
Старый 14.11.2019, 11:09   #136
Ilya J.
Сотрудник Сегнетикс
 
Аватара для Ilya J.
 
Регистрация: Mar 2016
Адрес: SPb
Сообщения: 4 302
Благодарил(а): 0 раз(а)
Поблагодарили: 254 раз(а) в 250 сообщениях
По умолчанию Ответ: Религиозные споры про то и про сё

Цитата
Сообщение от Shurion Посмотреть сообщение
Это конец моего любимого сериала или затишье перед бурей?
Это конец первого акта)


__________________
Если ничто другое не помогает, прочтите, наконец, инструкцию
Ilya J. вне форума   Ответить с цитированием
Старый 21.03.2020, 12:26   #137
ujin
Senior Member
 
Аватара для ujin
 
Регистрация: May 2010
Адрес: Novosibirsk
Сообщения: 762
Благодарил(а): 1 раз(а)
Поблагодарили: 10 раз(а) в 10 сообщениях
По умолчанию Ответ: Религиозные споры про то и про сё

Цитата
Сообщение от Gromov Посмотреть сообщение
Читал про лабвью, и думал "наверное, солидный софт, много хорошего.". Потом увидел видео, пошел - посмотрел ещё, и теперь думаю "ну и дер....". Как будто школьники делали. И за это ещё деньги просят. Поразительно. В сфере промышленной автоматизации не хватает новых технологий. Лабвью застрял в 98ом году. Моё мнение, конечно.
В преддверии 22 апреля (день рождения вождя мировой революции) Учиться, учиться и учиться как завещал ...
Хорошая новость для Вас:
https://learn.ni.com/training/resources
In response to COVID-19, all online courses are available for free to all NI customers until the end of April.
Вы можете
1. Бесплатно познакомиться с передовыми способами графического программирования при помощи курсов от производителя. 19 курсов каждый из которых отдельно стоит по 549$. Полугодовая подписка на 1 специалиста около 6000$
2. Бесплатно освоить инструмент для быстрого тестирования решений для графических языков например FBD и SMLogix. Не секрет, что в SMLogix пока нет отладки и пошагового выполнения и не у всех есть под рукой контроллер. Даже если есть контроллер все равно нет пошаговой отладки. Есть альтернатива - Ваше решение быстро накидать в LabVIEW, отладить, затем просто перенабить в SMLogix.
3. Сотрудникам Сегнетикс поможет в развитии SMLogix.
4. Всем пользователям поможет повысить свой профессиональный уровень и предлагать заказчику лучшее решение.
Как специалист, имеющий сертификат Certified LabVIEW Associate Developer (CLAD) всем очень рекомендую. Как минимум пригодится в программировании на SMLogix.
Это не альтернатива контроллерам от Segnetics и ПО SMLogix. Это помощь в Вашем профессиональном развитии.
Есть мегаспециалисты, которые думают, что и так достигли всех возможных вершин в программировании. Для них эти курсы будут особенно полезны.


__________________
В жизни 2 правила успеха:
1 Не говори всего что знаешь
2 ...
ujin вне форума   Ответить с цитированием
Старый 26.03.2020, 02:12   #138
АндрейХ
Member
 
Регистрация: Feb 2009
Сообщения: 50
Благодарил(а): 0 раз(а)
Поблагодарили: 9 раз(а) в 5 сообщениях
По умолчанию Ответ: Религиозные споры про то и про сё

Цитата:
Сообщение от ujin Посмотреть сообщение
В преддверии 22 апреля (день рождения вождя мировой революции) Учиться, учиться и учиться как завещал ...
Хорошая новость для Вас:
https://learn.ni.com/training/resources
In response to COVID-19, all online courses are available for free to all NI customers until the end of April.
LabView вещь интересная, когда то я на нём даже сделал RAW конвертор для конвертации снимков с Олимпуса...
Но есть куда более простая прога от Бауманцев для моделирования процессов. Прямого отношения к ПЛК она не имеет, но для понимания ТАУ очень даже... жаль что давно не развивается, но работает даже на Windows 10.
Вот ссылки:
https://yadi.sk/d/1Mh_NJprGKZlog
https://yadi.sk/d/w_Dibss7QY-Q5w
АндрейХ вне форума   Ответить с цитированием
Благодарность от:
Старый 26.03.2020, 02:14   #139
младшой
Senior Member
 
Регистрация: May 2010
Адрес: Москва
Сообщения: 857
Благодарил(а): 4 раз(а)
Поблагодарили: 85 раз(а) в 66 сообщениях
По умолчанию Ответ: Религиозные споры про то и про сё

(чет ссылки не работали)
младшой вне форума   Ответить с цитированием
Старый 26.03.2020, 02:51   #140
LordN
Senior Member
 
Регистрация: Dec 2007
Адрес: Томск
Сообщения: 4 125
Благодарил(а): 239 раз(а)
Поблагодарили: 161 раз(а) в 153 сообщениях
По умолчанию Ответ: Религиозные споры про то и про сё

Цитата
Сообщение от младшой Посмотреть сообщение
(чет ссылки не работали)
у меня открылись


__________________
C уважением, LordN
LordN вне форума   Ответить с цитированием
Ответ

Опции темы Поиск в этой теме
Поиск в этой теме:

Расширенный поиск
Опции просмотра

Ваши права в разделе
Вы не можете создавать темы
Вы не можете отвечать на сообщения
Вы не можете прикреплять файлы
Вы не можете редактировать свои сообщения

BB code is Вкл.
[IMG] код Вкл.
HTML код Выкл.



Часовой пояс GMT +4, время: 03:33.


Версия vBulletin: 3.8.3
Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
Segnetics 2005 - 2023