А зачем ПР это разбирать?
rovki так разбирает не ПР, он честно отвечает на запрос, а уже TCP сервер, зная, откуда прилетело отправляет пославшему.
По крайней мере у меня работает. А через аппаратный мы с двух компов счетчик Меркурий опрашивали.
Это пофигу, у слейва есть таймаут на ответ и любому слейву глубоко плевать, кому он отвечает. Он запрос принял, обработал, дал ответ. слейвы не умеют определять, получен ответ мастером или нет.
Вот и я про то же - какому мастеру какой ответ достанется и вообще достанется ли.Это раньше слейв плевал ,потому как мастер один ,а вы ему 10мастеров хотите подсунуть ....да еще одновременно говорящих по одному каналу.
электронщик до мозга костей и не только
Bad programmers worry about the code. Good programmers worry about data structures and their relationships
среди успешных людей я не встречала нытиков
Барбара Коркоран
Я думаю проблема в том, что первый мастер делает запрос, slave обрабатывает запрос и в это время приходит запрос от второго мастера.
По хорошему второму, slave должен сказать "Я занят, подожди", что опять таки увеличит время отклика первому мастеру, но на деле врятли ПР это отдаёт, что хорошо, а просто пропускает "мимо ушей". Таким образом идёт борьба нескольких мастеров за данные, кто выхватил, тот молодец.
И так чуть ли не каждый запрос. Синхронизировать работу 2х мастеров между собой сложно.
USR K3 имеет modbus, что и для чего не знаю, но мне кажется может там эта проблема решается, не тестил еще с несколькими мастерами.
У меня с программным слейв веселуха. Отписался разработчику SCADA по данному поводу.
Имеем ПР200 (слейв), remserial (TCP сервер для COM порта), SCADA с modbus
ПР200 честно отвечает всем как бы казалось. Меняю из одной копии SCADA переменную, и ей ПР200 возвращает измененные данные, так же отображая эту переменную на экране.
А вот по логам для второй копии SCADA опрос идет, все хорошо, но измененная переменная имеет предыдущее значение.
Так же среди переменных есть температура, которая меняется так же и в запросах второй копии SCADA и каким то чудом CRC блиать правильная в ответах...
Не может же ПР200 отвечать одному с новыми данными, а второму старыми данными да еще и CRC расчитывать ????
з.ы. в понедельник проверю на хардовом преобразователе Ethernet - RS485 аж самому интересно стало...
хотя с трудом представляю себе тупого разруливщика 485 в сеть, который просто сквозь себя данные прогоняет и ни сном ни духом о Modbus, который будет делать расчет CRC для модбаса отдавая данные из своего буфера...
rovki, ну встретились 2 запроса двух мастеров ну и что, один из них не получил данные или с ошибкой, выполнил запрос повторно, да и все.
Последний раз редактировалось melky; 09.09.2016 в 14:25.