Просмотр полной версии : ПЛК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.
Или создать еще один сокет.
На вопрос не ответили, а так можно порекомендовать еще и на другой контроллер перейти.
Давайте по существу или подождем ответа от техподдержки.
Что-то там явно не так - не должно быть такой задержки перед последующим соединением. Если порт освободили, то значит он должен быть свободным.
Давайте по существу или подождем ответа от техподдержки.
Что-то там явно не так - не должно быть такой задержки перед последующим соединением. Если порт освободили, то значит он должен быть свободным.
а какой ответ Вы ждете от поддержки, для овеновских контроллеров нормальная работа, это один сокет одно постоянное соединение. А этот изврат с постоянным пересоединением, нельзя назвать правильной эксплуатацией. Если Ваши ПК в роли клиентов рвут соединение, как по Вашему сервер об этом узнает, а главное как обрабатывает разрыв? Работайте через библиотеки, будет намного проще, вариант с разными портами и одной областью памяти модбас для N-ого количества клиентов будет намного надежнее
....вариант с разными портами и одной областью памяти модбас для N-ого количества клиентов будет намного надежнее
Полностью согласен.
Можно подключаться и больше чем двумя мастерами к одному ПЛК http://www.owen.ru/forum/showthread.php?t=14199&p=146969&viewfull=1#post146969
И для каждого мастера соединение постоянное будет.
Почему изврат? Я не видел в требованиях протоколах TCP/IP каких-то ограничений на повторное соединение. Поэтому и воспользовался данной возможностью на ПЛК110-30 и все работает. Значит в ПЛК110-60 ошибка в реализации TCP/IP.
Насчет два порта на один слейв - пробовал. Не интересно. Надо каждому клиенту прописывать свои порты, а сейчас одна и та же программа работает без дополнительных настроек. Если бы мне надо было бы панель + скада или что-то типа этого, то наверное воспользовался бы.
Ну и еще: стандартно порт 502, а остальное как раз и есть изврат.
И еще: связь не рвет, а нормально отсоединяется командой. Контроллер должен сразу закрыть соединение.
Кстати, подобная реализация как у меня, как раз имеет право на жизнь. Обычный распределенный доступ. Паузы в программах одинаковые, не прошел первый раз - прошел второй, потом больше ошибок в соединении нет, т.к. дальше пауза фиксированная. Что тут не правильного то???
PS Кстати к разным портам тоже не соединишься - ПЛК не дает, хоть и порт другой.
Почему изврат? Я не видел в требованиях протоколах 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.php?t=12947&p=85927&viewfull=1#post85927
и http://www.owen.ru/forum/showthread.php?t=12729&p=83833&viewfull=1#post83833
Спасибо, потом разберусь. :)
Взял другой ПЛК - все работает как нужно. Так что проблема была в ПЛК. Отправим по гарантии.
Веду вялотекущую переписку с техподдержкой по аналогичной проблеме. Видимо тоже придется менять по гарантии.
Да там походу аппаратная реализация TCP и попалась партия бракованных чипов. У нас два ПЛК из одного заказа - на одном вообще сдох TCP, второй глючный, благодаря которому и появилась эта ветка.
Техподдержка предложила откатиться на 2.14.0 - помогло.
У меня была 2.14.0 из коробки. Когда нарвался на глюк, то обновился на 2.15.0.
Филоненко Владислав
08.08.2016, 13:59
Если ПЛК видит штатный разрыв соединения - 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()
и висит дальше
Powered by vBulletin® Version 4.2.3 Copyright © 2025 vBulletin Solutions, Inc. All rights reserved. Перевод: zCarot