Просмотр полной версии : Порт 1200 на ПЛК110
Столкнулся тут с одной особенностью: если из какой-нибудь проги (например, телнетом) открыть и закрыть порт ТСР 1200 на ПЛК110, то больше он не открывается и из Кодесиса невозможно подключиться к ПЛК. Помогает только перезагрузка по питанию.
Получается, что если просто просканировать порты на ПЛК, то после этого нельзя будет к нему подключиться?
Пробовал на ПЛК110-30.Р-М, прошивки 2.15.9 и 2.16.0.
Может кто-нибудь это у себя проверить, действительно ли это так?
Или у меня тут какие-то глюки...
На 1200 сам КДС. Чего ожидаете-то ?
Ожидаю, что если на ПЛК порт 1200 открыт, то его можно открывать и закрывать без проблем.
Я имею ввиду, что если к конкретному врачу открыть дверь и тут же закрыть, то больше её уже не откроешь.
Если кто-то пробежит по коридору открывая и закрывая двери, то для тебя уже дверь не откроется. Только со слесарем.
У меня сейчас проблема: на удалённый ПЛК я могу подключиться Кодесисом только один раз. После отключения (штатного или нет - без разницы) подключиться больше не удаётся. Помогает только сброс по питанию. Поэтому и стал "изучать" этот вопрос...
Ещё раз прошу попробовать открыть-закрыть порт ТСР 1200 несколько раз (только не кодесисом). Получится у кого-нибудь?
Я вот и пробую искать... Широким фронтом)
При повторном подключения кодесиса, на SYN ПЛК сразу даёт RST. Как будто порт занят...
Пробовал на ПЛК с пустым проектом.
Дома, на столе, съымитировал это только телнетом.
При невозможности повторного подключения по ТСР, по ЮСБ подключаюсь без проблем.
Похоже, что портом 1200 на ПЛК заведует не ТСР сервер, который бы сам отслеживал клиентов и закрывал коннекты по таймаутам, а сам плк-шный кодесис, который открывает порт 1200, делает коннект для клиента и ждёт какие-то кодесисные данные. Если клиент - кодесис, то при откючении, он на своём языке говорит, что уходит, и ПЛК закрывает порт 1200. А если клиент НЕ кодесис, то коннект произойдёт, а отключение - нет!
Пока вижу это вот так...
настроил проброс порта на свой ПЛК 100, стукнулься телнетом несколько раз, дома проверю подключиться через CDS и вечером отпишусь...
Окрыли закрыли 1200
Закрыли КДС
Вынесли гейтвей
покурили
Занесли гейтвей
Запустили КДС
Соединились без проблем
Соединяюсь с ПЛК
Гружу проект
Отключаюсь
Подключаюсь - облом
Подключаюсь - ок
Отключаюсь
Подключаюсь - облом
Подключаюсь - ок
(и так через раз)
Отключаюсь
Открываю и закрываю порт 1200
Подключаюсь - облом
Подключаюсь - облом
Подключаюсь - облом
...
Закрываю кодесис
закрываю гейтвей
Открываю кодесис
Подключаюсь (гейтвей запускается сам) - Облом
Подключаюсь - облом
Подключаюсь - облом
...
ерунда, даже если её исследовать с помощью tcpdump, чем то другим не станет, так же останется пустой тратой времени. В плк нет тсп-сервера, если его не залить в коде, если Вы не правильно закрываете сокеты, то после 15 открытых соединений к плк не возможно подключиться, потому что превышен лимит.
надо пробовать не с пустым проектом а на другом контроллере, к примеру на plcwinnt
Да, но у меня нет 15 одновременно открытых соединений. У меня одно.
И эти 15 - только если сам напишешь. На порт 1200 два кодесиса не повесишь.
А у меня - пустой проект, никаких операций с сокетами нету.
Это всё происходит на уровне фирмваре.
Какая разница - из магазина или нет?
Специально, чтобы исключить влияние чего-то самописного, потёр проект в ПЛК.
Гружу в ОЗУ пустой проект.
Могу и не грузить - результат тот же. После открытия-закрытия порта 1200 - не подключается.
Если б можно было из проекта как-то переинициализировать встроенный "тср-сервер"?
PLCInfo
PLC model MODEL PLC 110-30 Версия ПО метр: 2.0
Binary VERSION 2.15.9
Need Target version 2.10
Compiled: 11:05:45 Feb 19 2016
MAC 6A:77:00:FF:E7:E2
IP 172.16.22.20
GATE 172.16.22.222
MASK 255.255.255.0
PIC upper version is 15
Licence unlimited
Второе и последующие подключения:
43295
С PLCWinNT проверить не могу.
Не пользуюсь - всегда есть плк под рукой.
В боевом проекте есть сервер ModbusTCP.
При отваливании кодесиса, он продолжает работать.
Есть большое желание через него сделать перезагрузку ПЛК, чтоб восстановить связь по 1200 порту...
ну тогда диагностируйте сами свои проблемы
Я просто попросил воспроизвести мои действия.
Если результат такой же - то и диагностировать нечего, ещё один глюк в ПЛК.
Если у кого-то порт 1200 открывается-закрывается несколько раз без проблем - проблема в моих железках.
Если у вас нет возможности это проверить - так и скажите. Может у кого-нибудь ещё эта возможность будет.
CAPZAP, похоже вы совсем не читаете, о чём я пишу.
То, что я на объекте не могу второй раз открыть онлайн режим - это отдельная песня.
Сейчас речь идёт (с первого поста!) о невозможности открыть онлайн режим после открытия-закрытия порта 1200.
Мне хотелось, чтоб форумчане, имеющие в доступности живые ПЛК, либо подтвердили либо опровергли мой результат.
Прям, сказка про белого бычка получается...
Сканирование портов осуществляется nmap-ом, а не телнетом
А телнет - для открытия-закрытия порта.
да, КДС сразу после этого не подключается, Вы решили свою проблему на основании этой информации?
Одну из проблем решил - понял, что это всё-таки глюк ПЛК и без очередной заплатки не обойтись. И уже её сделал - перезапуск ПЛК через ModbusTCP.
Я открыл/закрыл порт 1200 при онлайн-сессии КДС.
Как можно открыть порт 1200 при открытой онлайн-сессии?
Тогда ваш ПЛК должен позволять открывать с ним 2 сессии?
Как-то слабо верится...
На моём ПЛК порт 1200 не откроешь, пока он занят онлайн-сессией.
ну ни кто ни когда не запрещал и лук в женских чулках хранить, но производитель разве для овощей выпускает чулки?
Телнет всегда был инструментом пощупать порт. В чём сарказм?
Ну вот так.
Онлайн-сессия КДС (счетчики бегутъ)
Рядом старый добрый Client : TClientSocket делает Open. И ..
OnConnecting..
OnConnect..
OnWrite..
При этом Client.Socket.Connected = true. Счетчики бегутъ.
Чудеса! И это на каком ПЛК? С какой прошивкой?
Филоненко Владислав
25.06.2019, 20:22
Соединяюсь с ПЛК
Гружу проект
Отключаюсь
Подключаюсь - облом
Подключаюсь - ок
Отключаюсь
Подключаюсь - облом
Подключаюсь - ок
(и так через раз)
Отключаюсь
Открываю и закрываю порт 1200
Подключаюсь - облом
Подключаюсь - облом
Подключаюсь - облом
...
Закрываю кодесис
закрываю гейтвей
Открываю кодесис
Подключаюсь (гейтвей запускается сам) - Облом
Подключаюсь - облом
Подключаюсь - облом
...
Там внезапно есть достаточно большой таймаут.
Филоненко Владислав
25.06.2019, 20:25
Ну вот так.
Онлайн-сессия КДС (счетчики бегутъ)
Рядом старый добрый Client : TClientSocket делает Open. И ..
OnConnecting..
OnConnect..
OnWrite..
При этом Client.Socket.Connected = true. Счетчики бегутъ.
хе-хе. Вот только ответа нету :) Сессия занята. А то, что стек позволяет несколько попыток подключения - так это обычная фишка сокетов.
сарказм в том, зачем использовать инструменты там где они не нужны.
Конечно, если инструмент позволяет выявить очередной косяк в ПЛК, то, естественно, он не нужен.
Вы создали сброс контроллера, только ради того что полезли в порт не предназначенный для подключения сторонним ПО, кроме как самой КДС,
Да, но если бы КДС сам всегда стабильно подкючался к ПЛК, то я бы не полез в порт, не стал бы пытаться эмулировать отказ в подключении, не стал бы городить заплатку в виде сброса ПЛК. Да и топика бы этого вообще не было.
Вы этим решили проблему повторного подключения, а если будет идти техпроцесс который нельзя будет остановить, что тогда, а посмотреть нужно срочно именно сейчас.
Да, я решил проблему повторного подключения. Благо, на этом объекте техпроцесс довольно инерционный и позволяет перегрузить ПЛК без ущерба для дела. А подключения КДС нужны исключительно для модернизации проекта. Для "посмотреть" есть скада.
Пользовательской программе нужен рефакторинг, оптимизация и код-ревью
Ну да, только речь здесь идёт не о пользовательской программе.
заниматься ерундой в поисках как оригинальнее потерять соединение
По вашему, все софт/хард тестеры ерундой занимаются.
И как-то странно получается. То, что в ПЛК стек ТСР работает некорректно - это нормально. А то, что я на это наступил и пытаюсь как-то выкарабкаться - сплошная критика...
Короче, резюме такое:
1. Возможность искусственного создания отказа в подключении КДС к ПЛК - существует (вопросы безопасности, области применения...).
2. Создать искусственный отказ - проще простого (уровень квалификации вредителя - пионер ).
3. Восстановить возможность связи можно только через перезапуск ПЛК (неприемлемо для некоторых техпроцессов).
Я, наверное, тут немного сгустил краски. Отказ в подключении - конечно, не смертельно.
Но очень неудобно. По крайней мере, для меня.
Всё. Белый бычок помер. Сказке конец.
Столкнулся с похожей проблемой. Работаю по Ethernet. К свитчу подключено: ноутбук с Codesys 2.3.8 + ПЛК150 прошивка v.2.17 + сеть предприятия (примерно 300 ПК). Включаю ПЛК, (шаг 1) делаю логин, загружаю проект, делаю RUN... реакции нет, через несколько секунд - сообщение об ошибке: "Communication Error (#0) Logout Performed". Пробую переподключиться... несколько секунд соединение есть (успеваю запустить PLCInfo) и снова пропадает соединение с сообщением об ошибке (#0). Через несколько таких попыток это же сообщение появляется сразу уже без подключения к ПЛК. Перезагружаю ПЛК, далее всё повторяется с шага 1.
Отключаю сеть предприятия, перезагружаю ПЛК - всё работает без проблем!!! Подключаю сеть предприятия - снова начинаются проблемы, описанные выше.
При этом ПЛК из сети нормально откликается на пинг. Потерь пакетов нет.
IP адрес ПЛК входит в сеть предприятия. Сеть: 192.168.0.0, маска: 255.255.248.0, шлюз: 192.168.2.1, бродкаст: 192.168.7.255.
Проблема явно в ПЛК. Может кто-то знает - как её побороть?
ну Вы как бы изучали принцип работы ЛВС? Каждый хост ждет своей очереди передать информацию, совершенно любую, даже просто отметится что хост в сети, у Вас таких объектов под 300, там задержки несовместимы с работой "тяжелых" протоколов. Тот же сименс пишет что контроллеры должны работать в отдельной сети, а Вы со всеми вместе, даже с теми кто fullHD смотрит, но в маааленком экранчике
ну Вы как бы изучали принцип работы ЛВС? Каждый хост ждет своей очереди передать информацию, совершенно любую, даже просто отметится что хост в сети, у Вас таких объектов под 300, там задержки несовместимы с работой "тяжелых" протоколов. Тот же сименс пишет что контроллеры должны работать в отдельной сети, а Вы со всеми вместе, даже с теми кто fullHD смотрит, но в маааленком экранчике
Это Ваше субъективное мнение или Вы можете сослаться на RFC, где это написано? Или какие-то ограничения по TCP указаны в документации owen? Мы говорим о протоколе TCP/IP, который гарантирует доставку пакетов... При 1000 пакетов ICMP (пинга), 0% потерь с временем ответа от ПЛК меньше 1 мс. А вот ARP-таблица ПЛК может "забиваться" - это как вариант.
Это Ваше субъективное мнение или Вы можете сослаться на RFC, где это написано? Или какие-то ограничения по TCP указаны в документации owen? Мы говорим о протоколе TCP/IP, который гарантирует доставку пакетов... При 1000 пакетов ICMP (пинга), 0% потерь с временем ответа от ПЛК меньше 1 мс. А вот ARP-таблица ПЛК может "забиваться" - это как вариант.
ну Вы заходите когда изучите модель OSI, чтоб разговаривать о каком то одном уровне, а не обо всем в куче
Мы говорим о протоколе TCP/IP, который гарантирует доставку пакетова чем достигается эта особенность, уж не потерей ли времени, а еще там есть время жизни, ну и т.д.
ну Вы заходите когда изучите модель OSI, чтоб разговаривать о каком то одном уровне, а не обо всем в куче
а чем достигается эта особенность, уж не потерей ли времени, а еще там есть время жизни, ну и т.д.
Вообще-то мы выше 4-го уровня OSI не поднимаемся. На эзернет протоколе (ARP, 2-уровень) строится ICMP (3 уровень) и TCP (4 уровень). Если Вас смущает 3-ий уровень ICMP, то я эту же проверку делал с помощью arping на том же 2-ом уровне - результат аналогичный. Проблема не в уровнях OSI и не в транспортных протоколах и уж тем более не в TTL. Мы говорим об одноранговой сети... какие тут могут быть хопы? Всё передо мной на одном столе.
Кстати, в этой же сети, без проблем работает с полсотни Siemens S7 и 1200 и другие разные железяки с процессорами явно слабее, чем у ПЛК150.
Ваши обоснования с ожиданиями и "тяжёлыми" протоколами - это всё выдумки. Спасибо.
Вообще-то мы выше 4-го уровня OSI не поднимаемся.
да ладно, а на каком уровне тогда протокол CoDeSys? Вангую, что modbusTCP у Вас летает без проблем, не можете только онлайн подключаться к плк.
И смешно читать, когда пытаетесь сравнивать сименсы с бюджетным плк150/ Причем тут процессор, если обсуждаете проблемы ethernet, тогда уж надо оценивать сетевую карту на борту, удивите меня если смогли закольцевать овеновский контроллер
да ладно, а на каком уровне тогда протокол CoDeSys? Вангую, что modbusTCP у Вас летает без проблем, не можете только онлайн подключаться к плк.
И смешно читать, когда пытаетесь сравнивать сименсы с бюджетным плк150/ Причем тут процессор, если обсуждаете проблемы ethernet, тогда уж надо оценивать сетевую карту на борту, удивите меня если смогли закольцевать овеновский контроллер
CoDeSys общается с ПЛК Овен по протоколу TCP/IP, через порт 1200/tcp на ПЛК. Modbus ставить не планировал. Мне нужен именно базовый функционал, который заявляет фирма ОВЕН, без дополнительных библиотек.
Мне тоже вчера было смешно читать Ваши выдумки: "Тот же сименс пишет что контроллеры должны работать в отдельной сети."
Вот я Вам и пишу: Не важно какой контроллер, какой у него процессор и какой у него сетевой чип... Если ПЛК анонсирован для работы в сети эзернет, разработчики должны учитывать все нюансы в связанных RFC и других документах.
Похоже, что ПЛК сам себя "закольцовывает"... мне бы его "раскольцевать"... В ПЛК чип процессора AT91RM9200-QU, ethernet на борту...
Беру Raspberry pi 3, ставлю на него CoDeSys, подключаю к той же сети предприятия - всё работает, ничего не отваливается. Можно работать удалённо через NAT или VPN - без проблем! И это ещё бюджетней, чем ПЛК ОВЕН. Есть сетевые реле за $10, которые в этой же сети работают, как WEB-сервера - тоже проблем нет.
Почему у ОВЕН-а поблемы? Здесь явная недоработка разработчиков ПЛК ОВЕН.
Ладно, буду разбираться дальше...
CoDeSys общается с ПЛК Овен по протоколу TCP/IP, через порт 1200/tcp на ПЛК. Modbus ставить не планировал. Мне нужен именно базовый функционал, который заявляет фирма ОВЕН, без дополнительных библиотек.
Мне тоже вчера было смешно читать Ваши выдумки: "Тот же сименс пишет что контроллеры должны работать в отдельной сети."
Вот я Вам и пишу: Не важно какой контроллер, какой у него процессор и какой у него сетевой чип... Если ПЛК анонсирован для работы в сети эзернет, разработчики должны учитывать все нюансы в связанных RFC и других документах.
Похоже, что ПЛК сам себя "закольцовывает"... мне бы его "раскольцевать"... В ПЛК чип процессора AT91RM9200-QU, ethernet на борту...
Беру Raspberry pi 3, ставлю на него CoDeSys, подключаю к той же сети предприятия - всё работает, ничего не отваливается. Можно работать удалённо через NAT или VPN - без проблем! И это ещё бюджетней, чем ПЛК ОВЕН. Есть сетевые реле за $10, которые в этой же сети работают, как WEB-сервера - тоже проблем нет.
Почему у ОВЕН-а поблемы? Здесь явная недоработка разработчиков ПЛК ОВЕН.
Ладно, буду разбираться дальше...
протокол CoDeSys и среда разработки CoDeSys это ни одно и тоже. И как правильно заметил Валенок есть еще проект в котором в конфигураторе возможно слишком много комуникаций, что так же влияет на обмен онлайна со средой разработки
А так, те ресурсы по вводам/выводам плк150 дешевле взять етешку и любой 300-ый вполне сможет выполнять поставленные задачи, думаю цикл увеличенный на 2мс ни как не скажется
по поводу малины, кдс2 и кдс3 так же не одно и тоже
raspbery считается промышленным контроллером чтоб сравнивать их по цене с плк?
Проблема, скорее всего, в какой-то внутренней таблице. Я подозреваю, что в таблице MAC-адресов. Когда уменьшаю маску с /21 до /24 - обмен CoDeSys с ПЛК начинает работь стабильно (за 2 часа обрывов не было), ставлю маску /22 - обмен работает до 20 минут (с параллельным пингом до 1 часа), ставлю маску /21 - обмен работает до 1 минуты и параллельный пинг не сильно помогает. В принципе, использовать маску /24 для моих задач вполне допустимо. Для себя вопрос закрыл. Всем успехов.
Филоненко Владислав
18.09.2020, 09:20
Порт открывается и закрывается и в ходе подключения кодесиса. Той же функцией.
Вероятно вы его недозакрываете и коннект поддерживается.
Подключите снифер или перезагрузите КОМПЬЮТЕР
Powered by vBulletin® Version 4.2.3 Copyright © 2024 vBulletin Solutions, Inc. All rights reserved. Перевод: zCarot