Синхронный TCP/IP

[Daemvil]

Доброго времени суток всем!
Передо мной возникла такая нетривиальная задача:
Есть некий поворотный стол (купленный, с интерфейсом обмена Ethernet по протоколу TCP/IP)
Есть команды управления им, есть ответы на них. Собственно управление состоит из диалога "вопрос/ответ".
Нужно точно отмерить поворот 360 градусов, регистрируя показания с девайса, установленного на этом столе, которые идут в COM-порт.
Девайс все время выдает показания, без диалога.
Делал сначала так: отправляю с компа по TCP запрос положения стола и считываю показания с девайса, затем жду ответа от поворотного стола о текущем угловом положении. Но проблема в том, что, по всей видимости, пакет TCP отправляется не сразу, будто с переменными интервалами, и ответа приходится ждать часто непозволительно долго.
Затем сделал так: запросы и ожидание ответов выполняются в главном потоке, считывание показаний с девайса в другом потоке. Все бы хорошо, но в такой связке сильно теряю точность, т.к. отправка по TCP не гарантирует того, что пакет отправится именно в тот момент, когда выполняется команда отправки, и за это время стол может уже повернуться на определенный угол, и присланный ответ будет содержать в себе информацию о неправильном угловом положении.
Вопрос в следующем: есть ли какие-то способы отправить пакет по TCP непосредственно во время выполнения команды отправки, как это делается при отправке в COM-порт?

[Stilet]

Нескромный вопрос: А зачем тебе знать сверхточное время? Пусть этим контроллер занимается. Твоя винда или Линукс, или что там у тебя у станочника стоит все равно не ОС реального времени. Получение данных с конечников и реакция - это логика самого контроллера, а уже клиентский ноут просто будет успевать получать инфу с самого контроллера как сможет.
Или я чего-то не понимаю?

[Daemvil]

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

Нескромный вопрос: А зачем тебе знать сверхточное время? Пусть этим контроллер занимается. Твоя винда или Линукс, или что там у тебя у станочника стоит все равно не ОС реального времени. Получение данных с конечников и реакция - это логика самого контроллера, а уже клиентский ноут просто будет успевать получать инфу с самого контроллера как сможет.
Или я чего-то не понимаю?

Время знать не обязательно. Дело в том, что не согласуются данные.
Пришел например пакет с девайса с показаниями, соответствующими положению 170 градусов (в этом положении во время движения девайс померил сигнал и выдал в интерфейс). В этот момент я отправил запрос о текущем угловом положении стола, а он отправился через(к примеру)30мсек, а за это время стол успел повернуться еще на пару градусов, и уже вернет ответ не "170", а "172". Причем задержка каждый раз разная, и пройдет может быть не 30мсек, а 50 или вообще 100. Был бы COM - было бы проще. Вот такая беда...
Или ты предлагаешь сваять контроллер, который будет сам отсылать пакеты TCP, принимать данные с девайса, принимать ответы от стола, а потом их компоновать и отправлять? это уже новая надстройка будет над всей системой

[Stilet]

Не, я прост не оч. понимаю зачем станочнику такие точные данные. Всю логику реакций на конечники нужно упаковывать в контроллер. Даже на СОМ ты никак не сможешь получить с точностью такой, как требуешь, потому что ОС не успеет.
Смысл станочнику знать сверхточно угол поворота стола? Он же задает программу некую, которая управляет сервоприводами, и события создают именно конечники, на которые реагирует контроллер. Вот пусть контроллер и разбирается когда что переключать и останавливать.

[Daemvil]

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

Не, я прост не оч. понимаю зачем станочнику такие точные данные. Всю логику реакций на конечники нужно упаковывать в контроллер. Даже на СОМ ты никак не сможешь получить с точностью такой, как требуешь, потому что ОС не успеет.
Смысл станочнику знать сверхточно угол поворота стола? Он же задает программу некую, которая управляет сервоприводами, и события создают именно конечники, на которые реагирует контроллер. Вот пусть контроллер и разбирается когда что переключать и останавливать.

Мне нужно считать показания девайса и вычислить его параметры. Угол поворота нужно знать точно, чтобы посчитать эти параметры правильно. Считает программа на компе. На COM информация приходит со стабильной задержкой, в отличие от TCP(разброс большой по времени, даже до 200мс доходит). Когда был стол, управляемый по COM - все было стабильно и точно. Концевики там были магнитные и срабатывали каждые 15 градусов, сигнал от них приходил на пин COM порта, который отлавливался программно уже на компе. Если бы у TCP была стабильная задержка, можно было бы как-то еще выкрутиться, но она бегает в очень больших пределах.
У нового стола нет концевиков, есть какой-то сверхточный датчик углового положения, показания с которого можно принять только по запросу по TCP.
К слову сказать, в старом варианте стола погрешность программно замеренного времени одного оборота при скорости 2 градуса/сек варьировалась в пределах 15мс. Это достаточная точность.

[Stilet]

Ну если честно, я не могу понять почему так... Я работал с контроллерами, в которых упаковывалась вся логика работы, а тачпад на руках станочника ничего не вычислял. Поэтому мне сложно как-то так сообразить что тебе посоветовать.
По хорошему ваши ведущие из вашего БЭП должны были предусмотреть такие случаи, видимо провтыкали.

Тогда другой вопрос: Есть ли возможность прикрутить OPC Server, чтоб инфу со станка собирал уже он сам? Например бесплатный NAP OPC вроде умеет по ТСР работать, я правда не в курсах насколько стабильно, юзал его на RS-232 только, но в любом случае там хотя бы предусмотрены подобные случаи. Опять таки что за протокол? может вообще нужно отказываться от ТСР и выходить на уровень ниже транспортного, хотя бы на канальный (OSI 2), чтоб обеспечить стабильность. Как-то выглядит это как серьезный просчет при проектировке...