ПЛК110-60 TCP/IP проблемы

Всем привет!

Недавно сделал один проект, в котором вместо скады использовал самописную прогу на C#. Тот проект был на 110-30. Данные забирает по TCP/IP через библиотеку EasyModbus. Забор данных из ПЛК происходит раз в секунду. Перед чтением комп каждый раз соединяется с ПЛК, после чтения - отсоединяется. Для чего сделано: кроме оператора еще можно зайти с другого компа с этой же программой. Если "скада" не может считать данные, то делает небольшую паузу, после которой соединяется еще раз. Получается этакий Modbus с двумя мастерами. Все работает просто идеально. Причем оба компа могут и читать и записывать без проблем.
Решил сделать так же на ПЛК110-60... После отсоединения от ПЛК к нему невозможно соединиться повторно. Опытным путем было установлено, что это время должно быть больше 4,5 секунд, что вообще никак не подходит...
Прошивка была 2.15.8, прошил 2.15.9 - работает так же.

Можно сделать так, чтобы работало так же как и на ПЛК110-30? Ну очень надо, но переходить на него не вариант...
И переход на OPC-сервер тоже не предлагать. :)

Использовать UDP.
Или создать еще один сокет.

На вопрос не ответили, а так можно порекомендовать еще и на другой контроллер перейти.
Давайте по существу или подождем ответа от техподдержки.

Что-то там явно не так - не должно быть такой задержки перед последующим соединением. Если порт освободили, то значит он должен быть свободным.

Цитата:

---

Сообщение от JIexa21

Давайте по существу или подождем ответа от техподдержки.

Что-то там явно не так - не должно быть такой задержки перед последующим соединением. Если порт освободили, то значит он должен быть свободным.

---

а какой ответ Вы ждете от поддержки, для овеновских контроллеров нормальная работа, это один сокет одно постоянное соединение. А этот изврат с постоянным пересоединением, нельзя назвать правильной эксплуатацией. Если Ваши ПК в роли клиентов рвут соединение, как по Вашему сервер об этом узнает, а главное как обрабатывает разрыв? Работайте через библиотеки, будет намного проще, вариант с разными портами и одной областью памяти модбас для N-ого количества клиентов будет намного надежнее

Цитата:

---

Сообщение от capzap

....вариант с разными портами и одной областью памяти модбас для N-ого количества клиентов будет намного надежнее

---

Полностью согласен.
Можно подключаться и больше чем двумя мастерами к одному ПЛК http://www.owen.ru/forum/showthread....l=1#post146969
И для каждого мастера соединение постоянное будет.

Почему изврат? Я не видел в требованиях протоколах TCP/IP каких-то ограничений на повторное соединение. Поэтому и воспользовался данной возможностью на ПЛК110-30 и все работает. Значит в ПЛК110-60 ошибка в реализации TCP/IP.
Насчет два порта на один слейв - пробовал. Не интересно. Надо каждому клиенту прописывать свои порты, а сейчас одна и та же программа работает без дополнительных настроек. Если бы мне надо было бы панель + скада или что-то типа этого, то наверное воспользовался бы.
Ну и еще: стандартно порт 502, а остальное как раз и есть изврат.
И еще: связь не рвет, а нормально отсоединяется командой. Контроллер должен сразу закрыть соединение.
Кстати, подобная реализация как у меня, как раз имеет право на жизнь. Обычный распределенный доступ. Паузы в программах одинаковые, не прошел первый раз - прошел второй, потом больше ошибок в соединении нет, т.к. дальше пауза фиксированная. Что тут не правильного то???

PS Кстати к разным портам тоже не соединишься - ПЛК не дает, хоть и порт другой.

Цитата:

---

Сообщение от JIexa21

Почему изврат? Я не видел в требованиях протоколах TCP/IP каких-то ограничений на повторное соединение. Поэтому и воспользовался данной возможностью на ПЛК110-30 и все работает. Значит в ПЛК110-60 ошибка в реализации TCP/IP.

---

Ну допустим дело в реализации конфигуратора, ну допустим не хотите/не удобно два порт держать, сделайте через бибку на один порт

ЗЫ

Цитата:

---

Кстати, подобная реализация как у меня, как раз имеет право на жизнь

---

перечитайте про TCP/IP на опеннет статьи как закрывается соединение, про флаг FIN.

Да знаю я про флаг.
Я использую EasyModbus.
У меня сделано так:
modbusClient.Disconnect();

Смотрим ModbusClient:

Код:

---

                public void Disconnect()
                {
                        if (this.serialport != null) {
                                if (this.serialport.IsOpen) {
                                        this.serialport.Close();
                                }
                        }
                        else {
                                if (this.stream != null) {
                                        this.stream.Close();
                                }
                                if (this.tcpClient != null) {
                                        this.tcpClient.Close();
                                }
                        }
                }

---

Смотрим что за tcpClient:
private TcpClient tcpClient;

А вот что юзает ModbusClient:
using System;
using System.IO.Ports;
using System.Net;
using System.Net.Sockets;
using System.Threading;

Так что причем тут FIN? Что-то подозреваю, что майкрософтовский Net работает без ошибок...

на флаг FIN должен прийти ответ FIN,ACK, Вы видели что он приходит? В таких соединениях участвуют две стороны, Вы уверены что до плк дошло что надо выключится и он это сделал? Третий раз пишу, напишите в плк реализацию работы с сокетом через библиотеку и сравните результат

Да. Специально проверил снифером:
SYN
ACK
FIN
ACK
И потом одни SYN - ПЛК уже не видит запросов какое-то время.

И не могу нормальных примеров найти для работы через библиотеки...

а ID посылки и подтверждения совпадают для закрытия соединения и подтверждения на закрытие, просто ACK может быть от чего угодно, я как бы про это и писал что необязательно последующая в ответ посылка уже подтверждение закрытия

Да все совпадает...
Библиотека виндовая, с другим ПЛК работает...
Есть еще один ПЛК - после обеда попробую забрать и протестировать.
Кстати из этой партии мы один ПЛК отправили по гарантии и тоже с проблемой сети. Там панель Weintek постоянно отваливалась. Заменили и больше такой проблемы не было.

ну так если вейнтек, тогда вобще проблем не должно быть :)

Код:

---

IF mbus THEN
        IF diRecvSocket = SOCKET_INVALID THEN
                diRecvSocket := UdpOpenReceiveSocket(502);
        ELSE
                Reply := UdpReceiveData(diRecvSocket, ADR(byRecv),12);
                byRecv[5]:=67;
                byRecv[8]:=64;
                ptr:=ADR(byRecv[9]);
                ptr^:=visu;
                IF byRecv[6]=1 AND byRecv[7]=3 THEN
                        result:=UdpSendData(diRecvSocket,ADR(byRecv), SIZEOF(byRecv),Reply.sa);
                        byRecv[6]:=0;
                END_IF;
        END_IF;
ELSE
        IF diRecvSocket <> SOCKET_INVALID THEN
                SysSockClose(diSocket:=diRecvSocket);
                diRecvSocket := SOCKET_INVALID;
        END_IF;
END_IF;

---

панель перевожу в режим UDP, в контроллере вышеизложенный код

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

В примере пока ничего не понял. :))
Пример бы рабочий. Тут нашел какой-то архив, но в нем не понятно что за ПЛК и не вижу конфигурации - пусто.

http://www.owen.ru/forum/showthread....ll=1#post85927
и http://www.owen.ru/forum/showthread....ll=1#post83833

Спасибо, потом разберусь. :)

Взял другой ПЛК - все работает как нужно. Так что проблема была в ПЛК. Отправим по гарантии.

Веду вялотекущую переписку с техподдержкой по аналогичной проблеме. Видимо тоже придется менять по гарантии.

Да там походу аппаратная реализация TCP и попалась партия бракованных чипов. У нас два ПЛК из одного заказа - на одном вообще сдох TCP, второй глючный, благодаря которому и появилась эта ветка.

Техподдержка предложила откатиться на 2.14.0 - помогло.

У меня была 2.14.0 из коробки. Когда нарвался на глюк, то обновился на 2.15.0.

Если ПЛК видит штатный разрыв соединения - Slave сразу же готов к соединению.
Если разрыв нештатный - срабатывает таймаут и после него slave готов к новому соединению.
Мультипортового slave из коробки в принципе не будет, т.к. это нарушает саму концепцию master-slave.
Но вручную Вы можете обойти это ограничение.

Ну вот если я штатно разорвал соединение, то сразу же готов принять, но если не работает, то это неисправность ПЛК.
Кстати у свежеполученных сегодня М02 такая же ерунда - не разрывают соединение. :(
Приплыли...
Овеновцы, вы на аллиэкспрессе чипов по дешевке набрали? :)))

Проблему с "неотключением" TCP/IP решать то будете?
А то проекты переделывать долго, да и логика вся нарушается.
Есть какая-нибудь прошивка под М02 с рабочим TCP? Была 0.3.52. Залил 0.3.53 - те же яйца. После дисконнекта долго не принимает входящее подключение.

Вы же писали что отдельно взятая железка виновата

Ну выше написали что проблема решилась откатом прошивки...
Да и времени менять эти ПЛК уже нет - сроки поджимают. :(
И так я тот ПЛК брал "взаймы", поменял на другой рабочий. Теперь пришло два М02 и один вместо отдал вместо "заемного".
Второй у меня на столе "свистит" - блок питания походу в нем тоже отстой.Специально засекал время: если прошло больше 15 секунд после дисконнекта, то соединяется нормально, если больше, то висит все это время.
Никаких сторонних библиотек не использовал - только System.Net.Sockets. Все ответы и тд по стандарту - так же проверил сниффером.

Разочарован...

интересно больше это сколько,если уже больше 15 секунд
а в плк тг что, голый конфигуратор и всё?

Висит не ПЛК - висит прога на C#. ПЛК, соединенный с кодесисом продолжает работать в штатном режиме.
Программа частично написана. Пока идет отладка "на стенде" (на столе все собрал и гоняю), но с учетом того что приходится переделывать АРМ, монтаж затягивается...

Я в яве не силен. Запустил. Просто висит с последним сообщением: Load file:tcpmast.mls
Адрес в скрипте сменил на адрес своего ПЛК.
А вот через минуту написало: connect()
и висит дальше