Интерфейсные платы ПР200

[ASo]

А зачем ПР это разбирать?

[melky]

rovki так разбирает не ПР, он честно отвечает на запрос, а уже TCP сервер, зная, откуда прилетело отправляет пославшему.

По крайней мере у меня работает. А через аппаратный мы с двух компов счетчик Меркурий опрашивали.

[rovki]

А зачем ПР это разбирать?

А что бы знать какому мастеру отвечать ,что бы у того таймаут не сработал .

[melky]

Это пофигу, у слейва есть таймаут на ответ и любому слейву глубоко плевать, кому он отвечает. Он запрос принял, обработал, дал ответ. слейвы не умеют определять, получен ответ мастером или нет.

[rovki]

Вот и я про то же - какому мастеру какой ответ достанется и вообще достанется ли.Это раньше слейв плевал ,потому как мастер один ,а вы ему 10мастеров хотите подсунуть ....да еще одновременно говорящих по одному каналу.

[ASo]

А что бы знать какому мастеру отвечать ,что бы у того таймаут не сработал .

Так настройте нормальный таймаут.

[capzap]

Вот и я про то же - какому мастеру какой ответ достанется и вообще достанется ли

неуловил, что значит какой ответ, есть конкретный запрос от непойми какого мастера, выдать данные из конкретных ячеек памяти с вполне однозначной адресацией, счего это слейв должен ерепениться давать эти данные или нет?

[Scream]

Я думаю проблема в том, что первый мастер делает запрос, slave обрабатывает запрос и в это время приходит запрос от второго мастера.
По хорошему второму, slave должен сказать "Я занят, подожди", что опять таки увеличит время отклика первому мастеру, но на деле врятли ПР это отдаёт, что хорошо, а просто пропускает "мимо ушей". Таким образом идёт борьба нескольких мастеров за данные, кто выхватил, тот молодец.
И так чуть ли не каждый запрос. Синхронизировать работу 2х мастеров между собой сложно.
USR K3 имеет modbus, что и для чего не знаю, но мне кажется может там эта проблема решается, не тестил еще с несколькими мастерами.

[rovki]

Так настройте нормальный таймаут.

Да хоть пол часа ,но никто не даст гарантии что 2 мастера не полезут одновременно в сеть ,тут уж не до ответа слейва ...пакет будет битым .

[melky]

У меня с программным слейв веселуха. Отписался разработчику SCADA по данному поводу.
Имеем ПР200 (слейв), remserial (TCP сервер для COM порта), SCADA с modbus

ПР200 честно отвечает всем как бы казалось. Меняю из одной копии SCADA переменную, и ей ПР200 возвращает измененные данные, так же отображая эту переменную на экране.
А вот по логам для второй копии SCADA опрос идет, все хорошо, но измененная переменная имеет предыдущее значение.
Так же среди переменных есть температура, которая меняется так же и в запросах второй копии SCADA и каким то чудом CRC блиать правильная в ответах...


Не может же ПР200 отвечать одному с новыми данными, а второму старыми данными да еще и CRC расчитывать ????

з.ы. в понедельник проверю на хардовом преобразователе Ethernet - RS485 аж самому интересно стало...
хотя с трудом представляю себе тупого разруливщика 485 в сеть, который просто сквозь себя данные прогоняет и ни сном ни духом о Modbus, который будет делать расчет CRC для модбаса отдавая данные из своего буфера...

rovki, ну встретились 2 запроса двух мастеров ну и что, один из них не получил данные или с ошибкой, выполнил запрос повторно, да и все.