ПЛК110-60 сетевая функциональность

Новый проект.
В настройка целевой платформы, пункт сетевая функциональность прописываю работу по UDP.
Компилирую пустой проект, записываю программу в ПЛК.
Уже после этих манипуляций невозможно перевести контроллер в "СТОП".
При нажатии кнопки стоп в CoDeSys или на самом ПЛК, ПЛК зависает и перезагружается.

Вналиичии 2 ПЛК 100-60 КМ, на обоих такая проблема присутствует,а на ПЛК 100 КМ такой проблемы нет.

Впринципе сетевой обмен работает, но то что при остановке ПЛК, он виснет и перезагружается......

Можно ли передавать данные не широковещательным адресом, а на конкретный IP адрес ?

Цитата:

---

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

используя не метод сетевых переменных, а системную библиотеку SysLibSocet можно организовать по UDP недурственную связь между двумя ПЛК

---

Хотелось поменьше заморачиваться.
Данной библиотекой пользовался, только исспользовал TCP, UDP пробовал, но что-то не получилось.
Не могли бы Вы выложить пример обмена по UDP с помощью SysLibSockets.lib.

Спасибо!
Попробую разобраться.

Куда пропали представители техподдержки?

Цитата:

---

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

объяснять сил нет, сами разберетесь, где что

---

Спасибо, еще раз! Все получилось!
Возник вопрос, какой и вкаких случаях лучше исспользовать протокол, TCP или UDP?

Цитата:

---

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

мое мнение что во всех случаях при работе с плк достаточно одного UDP

---

Почему ? Меньше грузит процессор ?

Смущает что в ПЛК всего 4 UDP сокета, или вы настраиваете прием с любого адреса, а потом сортируете принятые данные по ip адресу принятого сообщения ?
Кстати пробовал настроить UDP сокет на прием от конкретного ip адреса, а он почему-то принимал данные с разных ip.

Цитата:

---

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

Адрес Вы не получите и через ТСР

---

Так ведь уже получаю, в структуру CLIENT_REPLY из функции UdpReceiveData. Правда пришлось ее немного подшаманить.


FUNCTION UdpReceiveData : CLIENT_REPLY

UdpReceiveData.diBytesReceived:=SysSockRecvFrom(di Socket, pbyData, diDataSize, 0, ADR(sa), SIZEOF(sa));

ia.S_addr:=UDINT_TO_DWORD(sa.sin_addr);
UdpReceiveData.IPAddress:=IP4_TO_STRING(sa.sin_add r);

Вопрос в том, что если одновременно два ПЛК на один и тот же порт шлют данные третьему, то коректно ли будет эти данные разбирать по IP адресу принятого сообщения?

capzap , что-то у меня вообще ничего не стартует
ПЛК150 использую.
Беру ваши примеры, библиотеку TcpUdplib - толку ноль.
Сокет не хочет открывать...
Все время возвращает вместо номера сокета -1

Где я неправ?

Цитата:

---

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

Попробуйте сбросить плк, может лимит открытых сокетов исчерпан

---

Да... переменные сбрасывает
По UDP посылку шлет. Четыре порта открывает
Надо теперь с TCP разобраться

Цитата:

---

Сообщение от Леонид

Смущает что в ПЛК всего 4 UDP сокета, или вы настраиваете прием с любого адреса, а потом сортируете принятые данные по ip адресу принятого сообщения ?
Кстати пробовал настроить UDP сокет на прием от конкретного ip адреса, а он почему-то принимал данные с разных ip.

---

Здравствуйте!

Подскажите пожалуйста, правильно ли я понимаю, что в ПЛК ОВЕН UDP-порта всего 4 штуки на айпишник?
Если да, нумерация им присваивается произвольно? Есть какой-то диапазон нумерации UDP портов ПЛК ОВЕН?

Спасибо!

Какой диапазон нумерации?
4 UDP сокета, да. А сокет Вы можете настроить как хотите.

Цитата:

---

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

ТСР в отличие от UDP гарантирует целостность передаваемых данных и уведомление отправителя о результатах передачи, во первых гарантия и уведомления меня не интересуют, во вторых та "мышинная возня" которая начинается у протокола при помехах на линии приводит иногда к зависанию соединения ТСР это мне тоже не нужно. С UDP же я всёравно с заданным периодом отправляю и /или получаю данные, каким то образом не дошло сейчас, дойдет в следущей посылке. А по поводу загрузки процессора, вроде при любом соединении температура ПЛК поднималась одинаково, так что думаю не принципиально

---

Да, всё так. Лучше заранее рассчитывать на то, что пакеты будут теряться и переупорядочиваться (==использовать UDP), чем потом внезапно узнать, что TCP 2 часа ждал "потерянного пакета".

Цитата:

---

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

Да, всё так. Лучше заранее рассчитывать на то, что пакеты будут теряться и переупорядочиваться (==использовать UDP), чем потом внезапно узнать, что TCP 2 часа ждал "потерянного пакета".

---

Ждал 2 часа???
А timeout тогда для чего?

А зачем ? Просто внезапно обнаруживается 2х часовое отсутствие связи.
(Штатный tcp-сервер - рестарт через около 6сек.)