SysSockCreate

[Scream]

Спасибо.
Здесь видно что держится, но plcWinNT, потом если будет возможно на реальном овен плк проверить бы.

[Scream]

Хочу поднять тему снова.
Я ранее писал о том что при установлении связи ПЛК (socketClient) <----> ПК (socketServer), плк отключается если в течении ~15 секунд ничего не принято\отправлено.
Это действительно так, но заметил еще вот что.
Время, через которое происходит отключение зависит от времени цикла установленного в конфигураторе MinCycleLength ms...
Так у меня в ПЛК160 при:
1ms отключение через 10 сек
2ms отключение через 11,1 сек
3ms отключение через 11,1 сек
4ms отключение через 11,2 сек
5ms отключение через 13,8 сек
6ms отключение через 11,2 сек
7ms отключение через 13,0 сек
50ms отключения не долждался.

Какие у кого мысли насчет этого?

P.s. читал как то книжку, если не ошибаюсь Хортсман (java). Так вот, он пишет что сокет действительно может так себя вести и предлагает делать так как я писал в посте №65 данной темы.

[vooodooo22]

За POU не скажу, достаточно двух FB ) Сокеты открываюцо "системой". Вылоняецо первый POU затем второй. Это все один цикл ПЛК ) я канеш могу ошибацо ибо таких огородов (с несколькими POU) не горожу ) Напиши один работающий FB а дальше юзай его экземпляры )

Доброго времени суток

Подскажите пожалуйста, я по вышеописанному принципу создал "один работающий FB" для обмена данными по UDP:
итерация 1. Сокет открыл, посылку отправил
итерация 2. жду ответа (n := n + 1; (*счетчик итераций*) далее просто проверяем если счетчик равен заданному количеству или пакет получен, закрываем сокет)

Если я использую один экземпляр данного FB, все хорошо.

Но если экземпляров становится больше (например 2) и один экземпляр обращается к несуществующему устройству Dev1 (сокет открывается, посылка идет, но ответа нет), а другой экземпляр к существующему Dev2 (ответы приходят), то ответные пакеты от устройства Dev2 начинаются теряться, либо приходят но с очень большим запозданием.

В коде использовал функцию SysSockSelect(), в которой указывал тайм-аут 1 сек. Но даже закомментив данный кусок кода все равно получаю такую бяку =(
Пробовал в SysSockSelect() выставить тайм-аут = 0, ситуация улучшилась, количество потерянных пакетов уменьшилось, но все равно полностью от этого избавиться пока не смог.

1. Такое ощущение, что функция SysSockRecvFrom() устройства Dev1 блокирует поток на N-ое время, за которое SysSockRecvFrom() устройства Dev2 теряет ответный пакет. Возможно ли такое?

2. Есть ли у функции SysSockRecvFrom() какое-то ограничение по времени по принятию пакета?

3. Или может быть эту функцию тоже как и открытие сокета нельзя вызывать в одной итерации ПЛК (хотя в ней же указывается с какого сокета принимать)?

4. Может ли влиять на эту ситуацию тот факт, что экземпляры выше описанного FB вызываются в программе PLC_PRG друг за другом в одной итерации, т.е. получается, что сокеты этих экземпляров открываются в одной итерации?


Спасибо большое всем откликнувшимся!

[Филоненко Владислав]

Хочу поднять тему снова.
Я ранее писал о том что при установлении связи ПЛК (socketClient) <----> ПК (socketServer), плк отключается если в течении ~15 секунд ничего не принято\отправлено.
Это действительно так, но заметил еще вот что.
Время, через которое происходит отключение зависит от времени цикла установленного в конфигураторе MinCycleLength ms...
Так у меня в ПЛК160 при:
1ms отключение через 10 сек
2ms отключение через 11,1 сек
3ms отключение через 11,1 сек
4ms отключение через 11,2 сек
5ms отключение через 13,8 сек
6ms отключение через 11,2 сек
7ms отключение через 13,0 сек
50ms отключения не долждался.

Какие у кого мысли насчет этого?

P.s. читал как то книжку, если не ошибаюсь Хортсман (java). Так вот, он пишет что сокет действительно может так себя вести и предлагает делать так как я писал в посте №65 данной темы.

Таймаут на закрытие соединения без данных - это штатная функция стека TCP/IP. Просто у Windows это время по умолчанию - 2 часа.
Также в ПЛК это время зависит от времени цикла, это штатное поведение.

[Филоненко Владислав]

Доброго времени суток

Подскажите пожалуйста, я по вышеописанному принципу создал "один работающий FB" для обмена данными по UDP:
итерация 1. Сокет открыл, посылку отправил
итерация 2. жду ответа (n := n + 1; (*счетчик итераций*) далее просто проверяем если счетчик равен заданному количеству или пакет получен, закрываем сокет)

Если я использую один экземпляр данного FB, все хорошо.

Но если экземпляров становится больше (например 2) и один экземпляр обращается к несуществующему устройству Dev1 (сокет открывается, посылка идет, но ответа нет), а другой экземпляр к существующему Dev2 (ответы приходят), то ответные пакеты от устройства Dev2 начинаются теряться, либо приходят но с очень большим запозданием.

В коде использовал функцию SysSockSelect(), в которой указывал тайм-аут 1 сек. Но даже закомментив данный кусок кода все равно получаю такую бяку =(
Пробовал в SysSockSelect() выставить тайм-аут = 0, ситуация улучшилась, количество потерянных пакетов уменьшилось, но все равно полностью от этого избавиться пока не смог.

1. Такое ощущение, что функция SysSockRecvFrom() устройства Dev1 блокирует поток на N-ое время, за которое SysSockRecvFrom() устройства Dev2 теряет ответный пакет. Возможно ли такое?

2. Есть ли у функции SysSockRecvFrom() какое-то ограничение по времени по принятию пакета?

3. Или может быть эту функцию тоже как и открытие сокета нельзя вызывать в одной итерации ПЛК (хотя в ней же указывается с какого сокета принимать)?

4. Может ли влиять на эту ситуацию тот факт, что экземпляры выше описанного FB вызываются в программе PLC_PRG друг за другом в одной итерации, т.е. получается, что сокеты этих экземпляров открываются в одной итерации?


Спасибо большое всем откликнувшимся!

Select - блокирующая функция. Использовать её я не рекомендую именно из-за блокирования. Гораздо правильнее будет по очереди попробовать прочитать из сокета и проанализировать код ошибки или просто по таймауту при отсутствии данных.