Более того в контроллере для таких случев нужен буффер памяти и видимо генератор стробирующего сигнала с другими временными параметрами, подходящими под обычный комп.

L>>>Отвечу поподробней. В общем контроллер устройств управляет фазовращателями(не особо важно в этом контексте). В нем имеется 2 генератора состояний: 1, 0, -1, 0 и 0, 1, 0, -1, которые изменяются циклически.
S>> В такой постановке задача нереальная, а уж тем более под гражданской ОС, типа Windows. Контроллеры должны ставить отметки времени в своих пакетах, тем или иным образом, тогда можно будет попытаться их как-то синхронизировать.
L>При принятии сообщения возникла проблема, пакеты идут неупорядоченно, так есть какая-нибудь возможность получать пакет по порядку, не дожидаясь других пакетов, т.е. сразу. Как отправил контроллер устройств сообщение, так у себя в программе получить сразу же этот пакет?
Интересно, те кто изначально проектировал вашу систему чем вообще руководствовались? Явно не спецификациями тех средств, которые они использовать решили.
ЗЫ UDP не гарантирует ни порядок, ни сам факт доставки пакетов
ЗЗЫ по хорошему вам нужна своя реализация UDP и всего что под ним. + про реалтайм уже много чего написано.

Здравствуйте, Figaro, Вы писали:

F>Более того в контроллере для таких случев нужен буффер памяти и видимо генератор стробирующего сигнала с другими временными параметрами, подходящими под обычный комп.

А какая задача будет стоять у контроллера? Как можно будет обеспечить правильный порядок следования сообщений?

Здравствуйте, ononim, Вы писали:

L>>>>Отвечу поподробней. В общем контроллер устройств управляет фазовращателями(не особо важно в этом контексте). В нем имеется 2 генератора состояний: 1, 0, -1, 0 и 0, 1, 0, -1, которые изменяются циклически.
S>>> В такой постановке задача нереальная, а уж тем более под гражданской ОС, типа Windows. Контроллеры должны ставить отметки времени в своих пакетах, тем или иным образом, тогда можно будет попытаться их как-то синхронизировать.
L>>При принятии сообщения возникла проблема, пакеты идут неупорядоченно, так есть какая-нибудь возможность получать пакет по порядку, не дожидаясь других пакетов, т.е. сразу. Как отправил контроллер устройств сообщение, так у себя в программе получить сразу же этот пакет?
O>Интересно, те кто изначально проектировал вашу систему чем вообще руководствовались? Явно не спецификациями тех средств, которые они использовать решили.
O>ЗЫ UDP не гарантирует ни порядок, ни сам факт доставки пакетов
O>ЗЗЫ по хорошему вам нужна своя реализация UDP и всего что под ним. + про реалтайм уже много чего написано.

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

L>>>>>Отвечу поподробней. В общем контроллер устройств управляет фазовращателями(не особо важно в этом контексте). В нем имеется 2 генератора состояний: 1, 0, -1, 0 и 0, 1, 0, -1, которые изменяются циклически.
S>>>> В такой постановке задача нереальная, а уж тем более под гражданской ОС, типа Windows. Контроллеры должны ставить отметки времени в своих пакетах, тем или иным образом, тогда можно будет попытаться их как-то синхронизировать.
L>>>При принятии сообщения возникла проблема, пакеты идут неупорядоченно, так есть какая-нибудь возможность получать пакет по порядку, не дожидаясь других пакетов, т.е. сразу. Как отправил контроллер устройств сообщение, так у себя в программе получить сразу же этот пакет?
O>>Интересно, те кто изначально проектировал вашу систему чем вообще руководствовались? Явно не спецификациями тех средств, которые они использовать решили.
O>>ЗЫ UDP не гарантирует ни порядок, ни сам факт доставки пакетов
O>>ЗЗЫ по хорошему вам нужна своя реализация UDP и всего что под ним. + про реалтайм уже много чего написано.
L>Проектировал не я, мне просто дали задание это сделать. Своя реализация это грубо говоря каждое сообщение помечать при отправке и при приеме проверять, чтобы в общем потом совпадал порядок следования сообщений?
Ну это не своя реализация, а как правильно юзать UDP. + контроль того что все дошло, если надо что все дошло
А под своей реализацией я подразумевал свой стек tcp(udp)/ip дабы гарантировать что все что пришло физически по кабелю пришло в лучшем виде к вам в апликуху. Потому как разработчики _стандартных_ стеков вольны делать с UDP пакетами все что угодно. И делают. Скажем не успела апликуха вовремя чтото вычитать — ну и фиг с ним. Или сделать некий кольцевой буфер и складывать в него пакеты, а вычитывать разумеется тоже в любом порядке могут. Причем так могут делать еще и производители драйверов сетевых карт с эзернет фреймами. То есть если в вашей задаче требуется передавать UDP пакеты с фиксированными задержками, гарантированной передачей и порядком — вам по сути не UDP нужно, а совсем другой протокол, который лишь использует формат пакетов UDP
Ну или научите свой софт мириться с ограничениями стандартного UDP — путем введения порядковых номеров пакетов.

SD>. В общем, я на этом не только собаку съел, и, уверяю, это вполне реально.
В собаку охотно верю.

Здравствуйте, ononim, Вы писали:

Pzz>>Я очень подозреваю, что товарищу и не нужен никакой RT. Если ему надо просто аккуратно собирать информацию и показывать ее на экране, времянка вообще особого значения не имеет. Если же он там крутит тяжелыми механическими устройствами, вряд ли ошибка в несколько миллисекунд при воздействии на такое устройство хоть как-то будет заметна. Лишь бы не накапливалась систематическая погрешность (когда ошибка всегда в одну сторону, грубо говоря).
O>А вдруг это система автоматического слежения за целью в РЛС? Чуть зазевался — и потерял цель

Вы очень проницательны, =).

Здравствуйте, Pzz, Вы писали:

Pzz>Здравствуйте, ononim, Вы писали:

O>>А вдруг это система автоматического слежения за целью в РЛС? Чуть зазевался — и потерял цель

Pzz>Вряд ли. Там еще спектроанализатор есть. Разве что с целью измерить спектр уже после попадания ракеты в цель

При помощи спектроанализатора, я получаю мощность сигнала.

Здравствуйте, leonneon, Вы писали:

L>Здравствуйте, sz36, Вы писали:

S>>Здравствуйте, leonneon, Вы писали:

L>>>Отвечу поподробней. В общем контроллер устройств управляет фазовращателями(не особо важно в этом контексте). В нем имеется 2 генератора состояний: 1, 0, -1, 0 и 0, 1, 0, -1, которые изменяются циклически.

S>> В такой постановке задача нереальная, а уж тем более под гражданской ОС, типа Windows. Контроллеры должны ставить отметки времени в своих пакетах, тем или иным образом, тогда можно будет попытаться их как-то синхронизировать.

L>При принятии сообщения возникла проблема, пакеты идут неупорядоченно, так есть какая-нибудь возможность получать пакет по порядку, не дожидаясь других пакетов, т.е. сразу. Как отправил контроллер устройств сообщение, так у себя в программе получить сразу же этот пакет?

Прочитал тему. Кажется что вы вообще нето что нужно делаете.
1. Под виндой вы никак не добьетесь стабильной работы.
2. Вам нужно маркировать пакеты, что бы знать их порядок. И тчо вы будете делать если один из пакетов пропадет?

Здравствуйте, BlackEric, Вы писали:

BE>Здравствуйте, leonneon, Вы писали:

L>>Здравствуйте, sz36, Вы писали:

S>>>Здравствуйте, leonneon, Вы писали:

L>>>>Отвечу поподробней. В общем контроллер устройств управляет фазовращателями(не особо важно в этом контексте). В нем имеется 2 генератора состояний: 1, 0, -1, 0 и 0, 1, 0, -1, которые изменяются циклически.

S>>> В такой постановке задача нереальная, а уж тем более под гражданской ОС, типа Windows. Контроллеры должны ставить отметки времени в своих пакетах, тем или иным образом, тогда можно будет попытаться их как-то синхронизировать.

L>>При принятии сообщения возникла проблема, пакеты идут неупорядоченно, так есть какая-нибудь возможность получать пакет по порядку, не дожидаясь других пакетов, т.е. сразу. Как отправил контроллер устройств сообщение, так у себя в программе получить сразу же этот пакет?

BE>Прочитал тему. Кажется что вы вообще нето что нужно делаете.
BE>1. Под виндой вы никак не добьетесь стабильной работы.
BE>2. Вам нужно маркировать пакеты, что бы знать их порядок. И тчо вы будете делать если один из пакетов пропадет?

По идее для этого нужно сделать дублирующий контроллер устройств, который имитирует работу настоящего, и каждые 1 и 1,25мс изменяет значение генераторов. Он так же будет работать на частоте 125 микросек. В итоге надо будет их синхронизировать чтобы одновременно выдавали положения генераторов. А для этого не надо будет каждое сообщение проверять. Если использовать tcp, то насколько будет он медленный?

Здравствуйте, leonneon, Вы писали:

L>По идее для этого нужно сделать дублирующий контроллер устройств, который имитирует работу настоящего, и каждые 1 и 1,25мс изменяет значение генераторов. Он так же будет работать на частоте 125 микросек. В итоге надо будет их синхронизировать чтобы одновременно выдавали положения генераторов. А для этого не надо будет каждое сообщение проверять. Если использовать tcp, то насколько будет он медленный?
Не даст вам винда точность в микросекунды. Даже не думайте.
Я не думаю что при гигабитной сети разница будет заметна.

Здравствуйте, BlackEric, Вы писали:

BE>Здравствуйте, leonneon, Вы писали:

L>>По идее для этого нужно сделать дублирующий контроллер устройств, который имитирует работу настоящего, и каждые 1 и 1,25мс изменяет значение генераторов. Он так же будет работать на частоте 125 микросек. В итоге надо будет их синхронизировать чтобы одновременно выдавали положения генераторов. А для этого не надо будет каждое сообщение проверять. Если использовать tcp, то насколько будет он медленный?
BE>Не даст вам винда точность в микросекунды. Даже не думайте.
BE>Я не думаю что при гигабитной сети разница будет заметна.

Точно микросекунду возможно и не даст, но близко к микросекунде 1-2 микросекунда, если машина сильная и не загруженная дает, boost chrono нужно использовать.

Здравствуйте, leonneon, Вы писали:

L>Точно микросекунду возможно и не даст, но близко к микросекунде 1-2 микросекунда, если машина сильная и не загруженная дает, boost chrono нужно использовать.

Вы можете огрести проблем когда комплекс в серию пойдет на разном железе.

Здравствуйте, BlackEric, Вы писали:

BE>Здравствуйте, leonneon, Вы писали:

L>>Точно микросекунду возможно и не даст, но близко к микросекунде 1-2 микросекунда, если машина сильная и не загруженная дает, boost chrono нужно использовать.

BE>Вы можете огрести проблем когда комплекс в серию пойдет на разном железе.

Согласен, что лучше использовать реал тайм системы.

Здравствуйте, leonneon, Вы писали:

l> F>Более того в контроллере для таких случев нужен буффер памяти и видимо генератор стробирующего сигнала с другими временными параметрами, подходящими под обычный комп.

l> А какая задача будет стоять у контроллера? Как можно будет обеспечить правильный порядок следования сообщений?

Внутренний кэш... Сброс по прерыванию, вместо поллинга (по стробу)...

Здравствуйте, ononim, Вы писали:

L>>>>>>Отвечу поподробней. В общем контроллер устройств управляет фазовращателями(не особо важно в этом контексте). В нем имеется 2 генератора состояний: 1, 0, -1, 0 и 0, 1, 0, -1, которые изменяются циклически.
S>>>>> В такой постановке задача нереальная, а уж тем более под гражданской ОС, типа Windows. Контроллеры должны ставить отметки времени в своих пакетах, тем или иным образом, тогда можно будет попытаться их как-то синхронизировать.
L>>>>При принятии сообщения возникла проблема, пакеты идут неупорядоченно, так есть какая-нибудь возможность получать пакет по порядку, не дожидаясь других пакетов, т.е. сразу. Как отправил контроллер устройств сообщение, так у себя в программе получить сразу же этот пакет?
O>>>Интересно, те кто изначально проектировал вашу систему чем вообще руководствовались? Явно не спецификациями тех средств, которые они использовать решили.
O>>>ЗЫ UDP не гарантирует ни порядок, ни сам факт доставки пакетов
O>>>ЗЗЫ по хорошему вам нужна своя реализация UDP и всего что под ним. + про реалтайм уже много чего написано.
L>>Проектировал не я, мне просто дали задание это сделать. Своя реализация это грубо говоря каждое сообщение помечать при отправке и при приеме проверять, чтобы в общем потом совпадал порядок следования сообщений?
O>Ну это не своя реализация, а как правильно юзать UDP. + контроль того что все дошло, если надо что все дошло
O>А под своей реализацией я подразумевал свой стек tcp(udp)/ip дабы гарантировать что все что пришло физически по кабелю пришло в лучшем виде к вам в апликуху. Потому как разработчики _стандартных_ стеков вольны делать с UDP пакетами все что угодно. И делают. Скажем не успела апликуха вовремя чтото вычитать — ну и фиг с ним. Или сделать некий кольцевой буфер и складывать в него пакеты, а вычитывать разумеется тоже в любом порядке могут. Причем так могут делать еще и производители драйверов сетевых карт с эзернет фреймами. То есть если в вашей задаче требуется передавать UDP пакеты с фиксированными задержками, гарантированной передачей и порядком — вам по сути не UDP нужно, а совсем другой протокол, который лишь использует формат пакетов UDP
O>Ну или научите свой софт мириться с ограничениями стандартного UDP — путем введения порядковых номеров пакетов.

А если использовать другой вид передачи, например rs422. У него скорость передачи и чтения может обеспечить 1 мс? Или can? Просто с udp пока, что пришел в тупик.

Здравствуйте, leonneon, Вы писали:

L>А если использовать другой вид передачи, например rs422. У него скорость передачи и чтения может обеспечить 1 мс? Или can? Просто с udp пока, что пришел в тупик.

Я бы на вашем месте все это тестировал. Дела простейший прототип и гонял часами, что бы убедиться что нет сбоев.

Здравствуйте, leonneon, Вы писали:

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

Здравствуйте, leonneon, Вы писали:

L>Здравствуйте, ononim, Вы писали:

L>>>Отвечу поподробней. В общем контроллер устройств управляет фазовращателями(не особо важно в этом контексте). В нем имеется 2 генератора состояний: 1, 0, -1, 0 и 0, 1, 0, -1, которые изменяются циклически.
O>>Ох, я надеюсь это не софт для АЭС или спутника какого? Ибо использование стоковой железяки с виндой для таких задач — большая ошибка.

L>Если поточнее, то для слежения и наведения антенны в реальном времени.
Надеюсь, не антенн для нашего ПРО?

S>Смотрю я на эту тему, и что-то очкую. Раз РЛС, то это что-то либо военное, либо авиационное. И если второе, то через несколько лет мы все имеем шанс с "этим" столкнуться. ТС то ладно, ему задание дали, он и корячится. Но ведь должен же быть и какой-то архитектор у этой системы. Который придумал два интерфейса по UDP и плюс еще USB синхронизировать с погрешностью менее миллисекунды, да еще и под под Windows . А после этого вы удивляетесь, что ракеты падают.
Насколько мне знается, в гражданской авиации РЛС с автоматическим слежением не делают, ибо целей там много, они все вокруг и сбежать от радара не стремятся Так что остается или ПРО, или какая нить экзотика типа подлодки.