|
|
Регистрация Восстановить пароль |
Повторная активизация e-mail |
Регистрация | Задать вопрос |
Заплачу за решение |
Новые сообщения |
Сообщения за день |
Расширенный поиск |
Правила |
Всё прочитано |
|
Опции темы | Поиск в этой теме |
16.07.2015, 10:11 | #1 |
Пользователь
Регистрация: 23.12.2009
Сообщений: 56
|
Синхронный TCP/IP
Доброго времени суток всем!
Передо мной возникла такая нетривиальная задача: Есть некий поворотный стол (купленный, с интерфейсом обмена Ethernet по протоколу TCP/IP) Есть команды управления им, есть ответы на них. Собственно управление состоит из диалога "вопрос/ответ". Нужно точно отмерить поворот 360 градусов, регистрируя показания с девайса, установленного на этом столе, которые идут в COM-порт. Девайс все время выдает показания, без диалога. Делал сначала так: отправляю с компа по TCP запрос положения стола и считываю показания с девайса, затем жду ответа от поворотного стола о текущем угловом положении. Но проблема в том, что, по всей видимости, пакет TCP отправляется не сразу, будто с переменными интервалами, и ответа приходится ждать часто непозволительно долго. Затем сделал так: запросы и ожидание ответов выполняются в главном потоке, считывание показаний с девайса в другом потоке. Все бы хорошо, но в такой связке сильно теряю точность, т.к. отправка по TCP не гарантирует того, что пакет отправится именно в тот момент, когда выполняется команда отправки, и за это время стол может уже повернуться на определенный угол, и присланный ответ будет содержать в себе информацию о неправильном угловом положении. Вопрос в следующем: есть ли какие-то способы отправить пакет по TCP непосредственно во время выполнения команды отправки, как это делается при отправке в COM-порт?
Nostra Sunt
|
16.07.2015, 10:26 | #2 |
Белик Виталий :)
Старожил
Регистрация: 23.07.2007
Сообщений: 57,097
|
Нескромный вопрос: А зачем тебе знать сверхточное время? Пусть этим контроллер занимается. Твоя винда или Линукс, или что там у тебя у станочника стоит все равно не ОС реального времени. Получение данных с конечников и реакция - это логика самого контроллера, а уже клиентский ноут просто будет успевать получать инфу с самого контроллера как сможет.
Или я чего-то не понимаю?
I'm learning to live...
|
16.07.2015, 10:43 | #3 | |
Пользователь
Регистрация: 23.12.2009
Сообщений: 56
|
Цитата:
Пришел например пакет с девайса с показаниями, соответствующими положению 170 градусов (в этом положении во время движения девайс померил сигнал и выдал в интерфейс). В этот момент я отправил запрос о текущем угловом положении стола, а он отправился через(к примеру)30мсек, а за это время стол успел повернуться еще на пару градусов, и уже вернет ответ не "170", а "172". Причем задержка каждый раз разная, и пройдет может быть не 30мсек, а 50 или вообще 100. Был бы COM - было бы проще. Вот такая беда... Или ты предлагаешь сваять контроллер, который будет сам отсылать пакеты TCP, принимать данные с девайса, принимать ответы от стола, а потом их компоновать и отправлять? это уже новая надстройка будет над всей системой
Nostra Sunt
Последний раз редактировалось Daemvil; 16.07.2015 в 10:49. |
|
16.07.2015, 10:56 | #4 |
Белик Виталий :)
Старожил
Регистрация: 23.07.2007
Сообщений: 57,097
|
Не, я прост не оч. понимаю зачем станочнику такие точные данные. Всю логику реакций на конечники нужно упаковывать в контроллер. Даже на СОМ ты никак не сможешь получить с точностью такой, как требуешь, потому что ОС не успеет.
Смысл станочнику знать сверхточно угол поворота стола? Он же задает программу некую, которая управляет сервоприводами, и события создают именно конечники, на которые реагирует контроллер. Вот пусть контроллер и разбирается когда что переключать и останавливать.
I'm learning to live...
|
16.07.2015, 11:06 | #5 | |
Пользователь
Регистрация: 23.12.2009
Сообщений: 56
|
Цитата:
У нового стола нет концевиков, есть какой-то сверхточный датчик углового положения, показания с которого можно принять только по запросу по TCP. К слову сказать, в старом варианте стола погрешность программно замеренного времени одного оборота при скорости 2 градуса/сек варьировалась в пределах 15мс. Это достаточная точность.
Nostra Sunt
Последний раз редактировалось Daemvil; 16.07.2015 в 11:14. |
|
16.07.2015, 11:57 | #6 |
Белик Виталий :)
Старожил
Регистрация: 23.07.2007
Сообщений: 57,097
|
Ну если честно, я не могу понять почему так... Я работал с контроллерами, в которых упаковывалась вся логика работы, а тачпад на руках станочника ничего не вычислял. Поэтому мне сложно как-то так сообразить что тебе посоветовать.
По хорошему ваши ведущие из вашего БЭП должны были предусмотреть такие случаи, видимо провтыкали. Тогда другой вопрос: Есть ли возможность прикрутить OPC Server, чтоб инфу со станка собирал уже он сам? Например бесплатный NAP OPC вроде умеет по ТСР работать, я правда не в курсах насколько стабильно, юзал его на RS-232 только, но в любом случае там хотя бы предусмотрены подобные случаи. Опять таки что за протокол? может вообще нужно отказываться от ТСР и выходить на уровень ниже транспортного, хотя бы на канальный (OSI 2), чтоб обеспечить стабильность. Как-то выглядит это как серьезный просчет при проектировке...
I'm learning to live...
|
Похожие темы | ||||
Тема | Автор | Раздел | Ответов | Последнее сообщение |
Синхронный сокет тормозит программу. | Человек_Борща | Работа с сетью в Delphi | 14 | 08.08.2014 14:16 |
Синхронный вывод в textBox | BrookBond | C# (си шарп) | 6 | 21.11.2013 14:48 |
TCPListener синхронный (прием и отправка данных) | Johnlion | C# (си шарп) | 1 | 20.01.2013 17:43 |
как создать TCP клиент, TCP сервер ? | DreamMaster911 | C/C++ Сетевое программирование | 1 | 26.10.2010 15:05 |
Синхронный просмотр | SeaMan | БД в Delphi | 3 | 09.10.2008 03:16 |