Просмотр полной версии : SysSockRecv не работает
Добрый день.
Проблема с SysSockRecv.
Не то чтобы он совсем не работал, перестает работать через час, полтора.
код приёма такой, лишнее убрано
(* ### Чтение из сокета ### *)
IF(diSocket > 0)THEN
diRxCount := SysSockRecv(diSocket, ADR(rxBuf[1]), 255, SOCKET_MSG_OOB);
IF(diRxCount > 0)THEN
diLastRxCount := diRxCount;
(*тут у меня вызов ФБ*)
END_IF
END_IF
Логика работы.
Плк считывает rfid метку и отправляет запрос на сервер для аутентификации карты.
Сервер - мой, написал на java, смотрит по базе кто это и отвечает плк, приведенный код как раз принимает данные от сервера.
Скептикам сразу говорю, я засомневался в себе и хотя в логах выводится после отправки массив я запустил wireshark и убедился что от плк и в плк пакеты идут.
Дальше по логике, если сервер не отвечает, то плк через секунду повторяет запрос, опять же всё вижу, байты приходят на сервер и уходит ответ каждый раз но diRxCount = -1.
В результате плк получает всёравно ответ, но через некоторое время (секунд 5 - 20).
Так как я всё это еще разрабатываю, то перезаписывать программу в плк приходится очень часто, вот и грешу на codesys.
Моё предположение что после N-го количества раз подключения из codesys SysSockRecv перестает корректно работать.
После заводского сброса (из codesys) всё работает как надо и молниеносно.
Еще мысли, ответ от сервера заранее неизвестен, но максимум 15 байт, считывать же я пытаюсь в каждом цикле плк 255 байт, по сути нет функции которая скажет сколько доступно для чтения поэтому так. Может тут что-то упустил?
А какая модель ПЛК у Вас?
минВЦ чему равно, что показывает модуль статистики
А какая модель ПЛК у Вас?
ПЛК 160-24 У М.
минВЦ чему равно, что показывает модуль статистики
Там всё хорошо, мин.цикл 5мс, free 2730, CPU is overloaded не горит.
Изначально писал проект занято было меньше 1мс при мин. 5мс. проблема была.
Нет никаких предположений?
У всех всегда SysSockRecv работал хорошо?
У меня 2.14.0 есть ли смысл перепрошить на 2.15.8?
Дмитрий Артюховский
19.02.2016, 09:05
Лучшая прошивка, по моему мнению, 2.10.9. (хотя не знаю есть ли она для 160) А также сильно рекомендую использовать UDP.
Лучшая прошивка, по моему мнению, 2.10.9. (хотя не знаю есть ли она для 160) А также сильно рекомендую использовать UDP.
udp понизит удобство в моем случае, мне обязательно нужно сохранить данные или отправить, раз в 3 секунды ~15 байт.
в tcp я хоть количество отправленных вижу и если не отправлено складываю в буфер, отправится позже, а с udp еще подтверждение на всё надо будет лепить.
у меня фасовка, и каждая тара должна быть в базе.
С ethernet'ом у овена вроде и работает, и как бы толком не работает, и где эта грань что работает, а что нет и где найти ВСЕ нюансы спустя 8 лет никто так и не знает.
попробуйте 10мс поставить минВЦ
попробуйте 10мс поставить минВЦ
думаете всё таки цикл.
ну попробую, спасибо.
Дмитрий Артюховский
19.02.2016, 17:17
"Плк считывает rfid метку и отправляет запрос на сервер для аутентификации карты.
Сервер - мой, написал на java, смотрит по базе кто это и отвечает плк, приведенный код как раз принимает данные от сервера."
у вас все равно запрос-ответ, а за 3 секунды можно ну очень много повторных сеансов повести - если надо, но udp в одном сегменте весьма надежен и здорово меньше грузит плк... не представляю в чем разница считать отправленные по tcp либо udp.... или сервер настолько медленный?
Андрей Шатохин
19.02.2016, 18:54
"Плк считывает rfid метку и отправляет запрос на сервер для аутентификации карты.
Сервер - мой, написал на java, смотрит по базе кто это и отвечает плк, приведенный код как раз принимает данные от сервера."
у вас все равно запрос-ответ, а за 3 секунды можно ну очень много повторных сеансов повести - если надо, но udp в одном сегменте весьма надежен и здорово меньше грузит плк... не представляю в чем разница считать отправленные по tcp либо udp.... или сервер настолько медленный?
1. на каждый сеанс "запрос-ответ" отдельный коннект?
2. Если грешишь на кодесис рекомендую перед прошивкой закрывать кодсис, удалять все временные файлы которые он создаёт к проекту, после подключения делать "заводской сброс", потом "записать".
3. что ещё делает проект опасного? работает ли с файлами?
4. с рфади как данные получает?
"Плк считывает rfid метку и отправляет запрос на сервер для аутентификации карты.
Сервер - мой, написал на java, смотрит по базе кто это и отвечает плк, приведенный код как раз принимает данные от сервера."
у вас все равно запрос-ответ, а за 3 секунды можно ну очень много повторных сеансов повести - если надо, но udp в одном сегменте весьма надежен и здорово меньше грузит плк... не представляю в чем разница считать отправленные по tcp либо udp.... или сервер настолько медленный?
Считать может разницы нет, а отправка при udp должна подтверждаться от сервера каждый раз, это усложняет логику, но за совет спасибо, подумаю еще.
Насчет сервера
22756
специально купленный для этих задач, никаких бухгалтеров и т.п. на нём нет.
1. на каждый сеанс "запрос-ответ" отдельный коннект?
2. Если грешишь на кодесис рекомендую перед прошивкой закрывать кодсис, удалять все временные файлы которые он создаёт к проекту, после подключения делать "заводской сброс", потом "записать".
3. что ещё делает проект опасного? работает ли с файлами?
4. с рфади как данные получает?
1. нет, соединение постоянное, поддерживается при простое пакетами keepAlive, при разрыве восстанавливается.
2. сегодня весь день отработал нормально, кодесисом подключался раза 3 по пол часа, до этого весь день с кодесисом онлайн, что еще больше вызывает подозрения на кодесис. И если это правда, то очень хорошо т.к. после запуска подключаться нет необходимости, тесты покажут.
3. SysLibCom еще. С файлами никак не работает, даже через конфигуратор, 100% работающий архиватор на 100й линейке у меня не получился, отложил до лучших времен.
4. SysLibCom, писать протокол пришлось для считывателя. Единственное что мне там не нравится - это вычисление LRC в цикле FOR, но до 7 циклов всегда.
Еще бы знать как в точности произвести эту проблему, былоб проще, а так сегодня хорошо, завтра плохо... уволят.
Андрей Шатохин
19.02.2016, 19:49
1. а есть счетчик сколько раз он восстанавливал соединение по keepalive?
2. а на сервере отключена буферизация сокета?
1. а есть счетчик сколько раз он восстанавливал соединение по keepalive?
2. а на сервере отключена буферизация сокета?
1. да, разрыв будет происходить через 11- 15 секунд после последнего действия с сокетом, я отправляю keepalive пакет раз в 3 секунды. Разрывы очень редко происходят, на сервере хорошо видно в логах.
2. при отправке от сервера вызывается flush(). В wireshark, напомню, что я вижу как действительно пакет отправляется ответом в плк, на плк же -1. Через секунду плк опять спрашивает у сервера кто это такой, сервер опять отвечает, всё проснифферил, плк в этом случае в течении секунд 15 - 20 всё таки получает пакет и авторизовывает рабочего, при этом связь не разрывается.
udp понизит удобство в моем случае, мне обязательно нужно сохранить данные или отправить, раз в 3 секунды ~15 байт.
в tcp я хоть количество отправленных вижу и если не отправлено складываю в буфер, отправится позже, а с udp еще подтверждение на всё надо будет лепить.
у меня фасовка, и каждая тара должна быть в базе.
С ethernet'ом у овена вроде и работает, и как бы толком не работает, и где эта грань что работает, а что нет и где найти ВСЕ нюансы спустя 8 лет никто так и не знает.
кстати зря Вы так про UDP, в библиотеке jamod есть режим modbusTCP по UDP, прекрасно работает и с собственными программами и с вейнтековской панелью, отклик для оператора приемлимый
кстати зря Вы так про UDP, в библиотеке jamod есть режим modbusTCP по UDP, прекрасно работает и с собственными программами и с вейнтековской панелью, отклик для оператора приемлимый
протокол свой, со стороны сервера организовать не проблема.
сама логика делать работу в ручную за tcp усложняет.
я не посылаю 10 раз одно и тоже, только тогда когда это необходимо с поддержкой связи пакетами keep alive.
Я сейчас глянул у себя - я sysSockRecv вызываю с diFlags = 0. И вроде проблем не замечал...
Тут (http://forum-ru.codesys.com/viewtopic.php?f=2&t=1789) обсуждение на тему САБЖа...
Я сейчас глянул у себя - я sysSockRecv вызываю с diFlags = 0. И вроде проблем не замечал...
Тут (http://forum-ru.codesys.com/viewtopic.php?f=2&t=1789) обсуждение на тему САБЖа...
Эту тему читал.
Проблема не в том что sysSockRecv вообще не работает, а в том что сегодня работает, завтра нет и причину воссоздать не могу.
Нашел при каких обстоятельствах не работает SysSockRecv - при сбросе программы плк (сброс\холодный сброс\заводской сброс).
Если при запуске плк стоят rfid карты, то он после соединения с сервером сразу делает запрос на сервер и ждет ответных данных и тут они не приходят, пока не сделать переподключение со стороны плк. Если же плк сделает запрос (этот же) через минуту (позже, через 2, 10, неважно) то работает все хорошо, если честно для меня загадка почему, ставил и задержки не делать запрос в течении 15 секунд, не помогло.
Такое поведение на версии v 2.14.0 (http://www.owen.ru/uploads/txtlic.php?url=/uploads/v.2.14.0_plc160.exe)
Поменял плк на аналогичный только с прошивкой 2.15.8 и проблема тут же ушла, данные принимаются всегда и SysSockRecv работает корректно при том же коде.
печально, ушло очень много времени на решение этой мелочи.
где то в оскат библиотеках было, то что они используют системные события и в функции перед стартом закрывают все сокеты
где то в оскат библиотеках было, то что они используют системные события и в функции перед стартом закрывают все сокеты
кстати надо посмотреть как у них это делается
Как мне показалось, с этой прошивкой действительно лучше работает SysSockRecv, но после n-го количества сброса и перезагрузок плк удалось воссоздать проблему и кажется понял что происходит, если не прав поправьте.
Логика моего сокет клиента такова, если дескриптор <= 0, то попробовать создать сокет функцией SysSockCreate которая и возвращает дескриптор.
У меня в конфигураторе есть modbus slave для ип320 с интерфейсом rs232 и тут же еще TCP.
Этот modbus slave tcp занимает тоже свободный сокет и тоже имеет свой дескриптор, у меня он получает 1.
Мой сокет при старте программы создает подключение и получает тот же дескриптор = 1, это мистика, но Send работает, а Recv очень не стабильно при этом часто на стороне сервера ошибки по сути "соединение было прервано со стороны клиента".
В этом случае я в ручную присваиваю моему дескриптору 0, при следующей отправке он вызывает SysSockCreate и получает 2.
Всё работает хорошо, опять присваиваю 0, получаю 3, потом 2, потом 3. Это говорит что соединение завершается по таймауту и сокет освобождается, но 1 больше не получаю, оно и верно, ведь конфигуратор там сидит, но при загрузке почему то проблемы есть.
Меня смутило это сообщение http://www.owen.ru/forum/showthread.php?t=23429&page=2&p=198280&viewfull=1#post198280
(http://www.owen.ru/forum/showthread.php?t=23429&page=2&p=198280&viewfull=1#post198280)
Поэтому начал искать разницу в теории, тут и вышел на конфигуратор.
Еще особенность, обычный сброс не влияет на конфигуратор, поэтому такая проблема появляется после включения плк, после заводского сброса или после холодного сброса.
Это очень не приятный баг, прошу проверить всем заинтересованным лицам, буду благодарен всем отклинувшимся.
Подниму тему с новой проблемой. На плк160 вроде всё работает и данные он принимает, но только на новой прошивке.
Теперь задача - передавать данные в плк 150 и повторю SysSockRecv не работает
(http://www.owen.ru/forum/showthread.php?t=23429&page=3)Код аналогичен в плк160 и показан в начале темы.
Плк принимает данные первые часа 2, потом абсолютно никак не реагирует, плк работает 24\7 и всегда подключен к серверу, сервер в свою очередь когда сочтет нужным, отправляет 5 байт в плк, всё просто.
Удалил из конфигуратора все TCP, даже так пробовал
diRxCount := SysSockRecv(diSocket, ADR(rxBuf[1]), 1536, SOCKET_MSG_OOB);
через некоторое время ПЛК не реагирует, видел фиксы прошивок где мешает гигабитная сеть, может чтото недофиксили или что еще надо?
Я хочу чтобы работал SysSockRecv, покажите пример где ПЛК - клиент и без проблем работает SysSockRecv в любое время суток независящий от фазы луны!
дальше мысли в слух.
На выставках в Москве много компаний называли овен барашком (иногда бараном) с глючными плк и восхваляли свои устройства.
Один мне даже рассказывал о НОВОМ языке программирования CFC, которого ниукого нет, вот IDE несколько сотен баксов только стоит.... слушал я, делая весьма удивленный вид.
Я задавал вопрос, а можно ли к их плк подключать не стандартные устройства или делать с сокетами что душе угодно как у овена, разговор заканчивался обычно.
Я пытался доказывать что овен - это гибко и дешево, но теперь понимаю, что это нихрена не работающие плк и менеджеры (мало понимающие, а некоторые доказывающие что у плк 100 нет ethernet) просто пудрят мозги. Архиватор, есть, только тупой в 32кб с кучей лишней информации. Писать файлы, пожалуйста, только это работает как презерватив, один раз, потом перезагружать.
возможно, но не факт,размерность буффера большую ставите, по сети овеновский плк может передавать не больше 490 байт. Я когда тестил мониторинг температуры дома в поездке, шесть часов проходило и сеть не падала
размерность буффера большую ставите, по сети овеновский плк может передавать не больше 490 байт. Я когда тестил мониторинг температуры дома в поездке, шесть часов проходило и сеть не падала
Это я уже в истории форума нашел, мол помогло.
Ставил и 5 и 10 и 100.
Плк160 с новой прошивкой тоже заработал, а 150 ну ни в какую, неделю бьюсь.
Важная деталь, если плк из кодесиса сбросить и нажать старт, то опять работает без проблем пару часов.
Филоненко Владислав
29.03.2016, 11:48
Код неверен. Где проверка на ошибки, канал что, 100% надёжный? Должна быть проверка на ошибки/таймаут обмена и переинициализация с закрытием и открытием сокета.
Да, интенсивный обмен в сети может приводить к пропаданию части пакетов, но код клиента должен быть самовосстанавливаемым.
Код неверен. Где проверка на ошибки, канал что, 100% надёжный? Должна быть проверка на ошибки/таймаут обмена и переинициализация с закрытием и открытием сокета.
это всё есть.
Плк уже как год стоит на компрессоре, снимает показания датчиков круглосуточно. Связь поддерживается со сторогы плк пакетами по 7 байт 1 раз в 4 секунды.
Плк - клиент, всегда восстанавливает связь при пропадании, за месяц логов не видел разрывов с плк 150, но принимать не хочет и всё тут.
Плк передает данные и дескриптор сокета всегда = 1.
Филоненко Владислав
30.03.2016, 12:47
ну ежели 1 сокет в программе - у него дескриптор и будет == 1.
Проверьте маску и шлюз.
ну ежели 1 сокет в программе - у него дескриптор и будет == 1.
Проверьте маску и шлюз.
Маска одинаковая у всех устройств 255.255.255.0
Шлюз = ПК сервер, с которым и ведётся обмен (хотя я не понимаю причем здесь шлюз, не работало бы совсем, а тут ОТ плк за год всё ОК, а В плк макс. 2 часа).
Код на пкл 160 работает, этот же код (точь в точь, один fb) не работает на плк 150.
Пока реализовал через конфигуратор с modbus tcp, CustomSocket -> server, server --modbus--> Default modbus tcp.
Возник еще такой вопрос.
Логика в программе такая, если дескриптор = 0, то создаем новый сокет и работаем с ним.
На плк 160, после того, как уже всё соединилось и работает мой дескриптор = 3 (первые 2 заняты конфигуратором, писал выше), теперь в ручную присваиваю ему 0, следом создается новый сокет и дескриптор = 4, старое подключение по всей логики должно умереть по таймауту, через 15 секунд обнуляю еще раз, создается вновь новый сокет и дескриптор опять = 3.
Насколько я понимаю это правильная логика.
В плк 150 дескриптор всё время новый на единицу больше предыдущего, дойдя до 15, всё, кранты, идти перезагружать.
Чем это объяснить?
Филоненко Владислав
31.03.2016, 14:06
Логика в программе такая, если дескриптор = 0, то создаем новый сокет и работаем с ним. - неверная логика.
Если сокеты кончились - то всё. Закрывайте сокеты.
еперь в ручную присваиваю ему 0,
Я просто поражён. Перефразируя - и тут я ему вскрываю грудину, меняю сердце - но пациент чего-то умер.
Но помню, один пациент (160) выжил. Почему ваши пациенты такие хлипкие!?
Логика в программе такая, если дескриптор = 0, то создаем новый сокет и работаем с ним. - неверная логика.
Если сокеты кончились - то всё. Закрывайте сокеты.
еперь в ручную присваиваю ему 0,
Я просто поражён. Перефразируя - и тут я ему вскрываю грудину, меняю сердце - но пациент чего-то умер.
Но помню, один пациент (160) выжил. Почему ваши пациенты такие хлипкие!?
Да, вполне возможно неверная.
Я надеялся на таймаут, на плк 160 работает, а на плк 150 нет. Я не понимаю ваших пациентов, они с одной фабрики, код один, а поведение разное, ПОЧЕМУ?
Тем не менее это не решает мою проблему, сокет 1 всегда, ОТ плк всё хорошо, К плк по настроению.
Да, присваиваю 0, чтобы в ручную создать НОВОЕ подключение, вникните, это тестирование сокета и проверка как оно работает, поражаться тут нечему.
Покажите код который я смогу загрузить в плк 150\100\160 где плк клиент, он может принимать данные и это проработает пару суток, я сниму шляпу.
Да, вполне возможно неверная.
Я надеялся на таймаут, на плк 160 работает, а на плк 150 нет. Я не понимаю ваших пациентов, они с одной фабрики, код один, а поведение разное, ПОЧЕМУ?
Тем не менее это не решает мою проблему, сокет 1 всегда, ОТ плк всё хорошо, К плк по настроению.
Да, присваиваю 0, чтобы в ручную создать НОВОЕ подключение, вникните, это тестирование сокета и проверка как оно работает, поражаться тут нечему.
я использовал 160-ые, там всё должно было быть тоже самое, после 15 не закрытых сокетов, больше связи не будет. Либо какая нибудь эксперементальная прошивка у Вас была, либо в системных задачах при каждом пуске запускалась функция закрытия сокета
я использовал 160-ые, там всё должно было быть тоже самое, после 15 не закрытых сокетов, больше связи не будет. Либо какая нибудь эксперементальная прошивка у Вас была, либо в системных задачах при каждом пуске запускалась функция закрытия сокета
Прошивка с сайта. Я понимаю что за собой надо убирать, хотя должно само всё закрыться по таймауту, но нет проблем отследить и вызвать одну функцию закрытия, это мелочи.
Владислав, вы читали о том, что творится когда в конфигураторе есть tcp подключение и создавать с первого цикла свой сокет?
Можете как нибудь прокомментировать?
Прошивка с сайта. Я понимаю что за собой надо убирать, хотя должно само всё закрыться по таймауту, но нет проблем отследить и вызвать одну функцию закрытия, это мелочи.
да небыло никогда такого чтоб само всё закрывалось
да небыло никогда такого чтоб само всё закрывалось
Я описал как работает, создал новое (активное) дескриптор = 3, жду, создаю новое, дескриптор = 2 и так по кругу сколько душе угодно (первый занят конфигуратором), сам ничего не закрываю, отсюда я сделал вывод что оно работает.
Филоненко Владислав
31.03.2016, 19:15
Да, вполне возможно неверная.
Я надеялся на таймаут, на плк 160 работает, а на плк 150 нет. Я не понимаю ваших пациентов, они с одной фабрики, код один, а поведение разное, ПОЧЕМУ?
Тем не менее это не решает мою проблему, сокет 1 всегда, ОТ плк всё хорошо, К плк по настроению.
Да, присваиваю 0, чтобы в ручную создать НОВОЕ подключение, вникните, это тестирование сокета и проверка как оно работает, поражаться тут нечему.
Покажите код который я смогу загрузить в плк 150\100\160 где плк клиент, он может принимать данные и это проработает пару суток, я сниму шляпу.
Ну начнём с того, что 0-й сокет - это сокет CoDeSys - а вы его как-то используете. Как это работает - а х.з.
Во вторых, без закрытия сокетов они кончаются. Внезапно.
В третьих, коли нет закрытия - то нет и контроля коннекта, т.е. правильно: нет обмена/ошибка - закрываем и открываем заново. Этого не происходит, от сюда странное поведение.
Ну ни наконец, почему же работает у Вас на 160-м. А кто его знает, какие ещё ошибки есть в коде. Иногда минус на минус дают плюс.
Работать как описано, не должно!
Филоненко Владислав
31.03.2016, 19:18
Владислав, вы читали о том, что творится когда в конфигураторе есть tcp подключение и создавать с первого цикла свой сокет?
Можете как нибудь прокомментировать?
Трудно это комментировать, т.к. вообще не понятно как это работает. Есть стандарты работы с сокетами, у нас в ПЛК1хх есть некоторые особенности, но в целом всё как в обычных сокетах. Нельзя обращаться к чужому сокету, менять его хендл и делать прочие ужасные вещи :)
Ну начнём с того, что 0-й сокет - это сокет CoDeSys - а вы его как-то используете. Как это работает - а х.з.
Во вторых, без закрытия сокетов они кончаются. Внезапно.
В третьих, коли нет закрытия - то нет и контроля коннекта, т.е. правильно: нет обмена/ошибка - закрываем и открываем заново. Этого не происходит, от сюда странное поведение.
Ну ни наконец, почему же работает у Вас на 160-м. А кто его знает, какие ещё ошибки есть в коде. Иногда минус на минус дают плюс.
Работать как описано, не должно!
Вы меня не поняли, 0й никак не пользую.
Про создание\закрытие сокета можно забыть, не в этом суть.
Вы скажите мне прямо, SysSockRecv для Вас работает на 100% при продолжительном коннекте в пару суток на плк 100\150\160?
Трудно это комментировать, т.к. вообще не понятно как это работает. Есть стандарты работы с сокетами, у нас в ПЛК1хх есть некоторые особенности, но в целом всё как в обычных сокетах. Нельзя обращаться к чужому сокету, менять его хендл и делать прочие ужасные вещи :)
Да, стандарты есть, эти некоторые особенности надо собрать в кучу, это давно пора сделать.
Хендл назначается САМ!
Еще один вопрос.
Если в конфигураторе есть tcp и самому через библиотеки работать с сокетами есть какие нибудь особенности на плк 100\150\160?
Мешает ли конфигуратор работать со своим сокетом созданным через библиотеки?
Дайте мне однозначный ответ, я вам поверю на слово и буду разбираться дальше.
Если причина проблемы у меня, буду благодарен за тыканье носом в ошибку, если проблема на вашей стороне, давайте как то обходить её и предупреждать народ.
Филоненко Владислав
01.04.2016, 09:16
Вы меня не поняли, 0й никак не пользую.
Про создание\закрытие сокета можно забыть, не в этом суть.
Вы скажите мне прямо, SysSockRecv для Вас работает на 100% при продолжительном коннекте в пару суток на плк 100\150\160?
Понятие продолжительный коннект и ethernet - несовместимы. Пакеты теряются, возможности по восстановлению обмена в протоколе TCP не бесконечны. Т.о. обрывы вполне вероятны. И при обрыве надо просто переконектится.
Филоненко Владислав
01.04.2016, 09:18
Да, стандарты есть, эти некоторые особенности надо собрать в кучу, это давно пора сделать.
Хендл назначается САМ!
Мешает ли конфигуратор работать со своим сокетом созданным через библиотеки?
Это Вы вообще о чём? Какой конфигуратор, с каким сокетом? Что значит назначается сам? Я вообще перестал понимать что у Вас происходит в программе.
Клиент TCP - это простая, регулярно используемая в тысячах ПЛК штука. Тот же ModBus TCP прекрасно фурычит. Если написан верно!
Это Вы вообще о чём? Какой конфигуратор, с каким сокетом? Что значит назначается сам? Я вообще перестал понимать что у Вас происходит в программе.
Клиент TCP - это простая, регулярно используемая в тысячах ПЛК штука. Тот же ModBus TCP прекрасно фурычит. Если написан верно!
Я понял вас, аккуратно отходите от ответа.
Освободится чуть времени у меня, напишу код, будем тестировать и изучать ваш плк вместе.
Я понял вас, аккуратно отходите от ответа.
Освободится чуть времени у меня, напишу код, будем тестировать и изучать ваш плк вместе.
так и Вы опишите правильно, если на разные порты настроены сокеты то не влияет, если мучаете один и тот же то будут проблемы
Powered by vBulletin® Version 4.2.3 Copyright © 2024 vBulletin Solutions, Inc. All rights reserved. Перевод: zCarot