Страниц: 1 2 [3]
  Печать  
Автор Тема: TCP/IP через послед. порт в QNX 6.x - реально или нет?  (Прочитано 29764 раз)
DigiMind
Гость
« Ответ #30 : Марта 29, 2002, 10:03:00 am »


QSSL взяла код NetBSD и перетащила весь стек протоколов от туда, включая и bpf ...

Точно. Совсем заработался Уже аббревиатуры путаю.
Записан
dmi
QOR.Admin
*****
Offline Offline

Сообщений: 469



Просмотр профиля
« Ответ #31 : Марта 29, 2002, 12:51:00 pm »


Куда и что перетащила? IPFilter разве "by QSSL"?

Xiong Tang  & (?) Chris McKillop
Записан
dmi
QOR.Admin
*****
Offline Offline

Сообщений: 469



Просмотр профиля
« Ответ #32 : Марта 29, 2002, 12:58:00 pm »


В rtl'ках плохо, вернее криво реализован promiscous mode в сетевухах. (Кстати если сетевая 8139A, а не 8139C, то там очень много аппаратных ошибок). Кстати MAC можно менять во время работы через bpf, правда не знаю, на сколько QSSL качественно перетащила код из BSD bpf и оставили ли они там эту возможность.

Да, у меня именно А. Не знал. надо будет сменить
Записан
lestat
QOR.Moderator
*****
Offline Offline

Сообщений: 985


I don't trust anything


Просмотр профиля WWW
« Ответ #33 : Марта 29, 2002, 01:20:00 pm »


dmi пишет:

В rtl'ках плохо, вернее криво реализован promiscous mode в сетевухах. (Кстати если сетевая 8139A, а не 8139C, то там очень много аппаратных ошибок).

Да, у меня именно А. Не знал. надо будет сменить


Прежде чем менять посмотри опции драйвера при запуске, она (8139) может работать в двух режимах: PIO and MMIO, т.е. с портами и напрямую с памятью, так вот как раз работа с памятью и глючит. Про 8139B сказать мало, что могу, я почему-то видел ее только встроенной в промышленных материнках.

З.Ы. Я не знаю, сделали ли поддержку выбора режима работы в QNX, но в линуксе есть. Вспомнил еще один факт, если включен BOOTROM BIOS, а его физически нет, то возможно все что угодно в плане глюков (только касательно RealTek'ов). Да все очень зависит от производителя сетевой платы ...

Что-то уже попахивает оффтопиком
Записан

olej
QOR.Team
****
Offline Offline

Сообщений: 42



Просмотр профиля
« Ответ #34 : Апреля 02, 2002, 11:55:00 am »

И теперь, когда общий гвалт угас (с последнего сообщения - 4 дня, как я понимаю, все кто что хотел, тот сказал), как говорят в Одессе: "послушайте сюда".

Этот вопрос затрагивает ("бочком") аспекты, наиболее важные для использования QNX, а, поэтому, заслуживает дальнейшего тщательного рассмотрения (при некотором сужении предмета). Попробую объяснить это конкретнее.

Много говорено везде (в старом форуме, к примеру), что использование QNX можно рассматривать в 3-х аспектах (да его так каждый и рассматривает - со своей колокольни): а).как desktop, б).как универсальный сервер, в).как OS для embedded систем. "а" и "б" - об них можно говорить долго и по разному, не стану повторяться, мне они вообще "до лампочки" - меня интересует только "c"! Тем более, что, если кто это пропустил, мы обсуждает subj в разделе "Встроенные системы" - в другом разделе тот же вопрос должен обсуждаться по-другому.

1-я контрольная точка: кому эта позиция неинтересна, могут вообще дальше не читать - не теряйте время: нет ничего дороже времени!. Я буду сознательно писать, как истинный графоман , "медленно и скорботно", и только для тех, чьи сферы интересов совпадают (таких контрольных точек будет несколько).

Я думаю, что, применительно ко встроенным(!) системам, пока только 2 темы форума заслуживают столь пристального рассмотрения: эта и "менеджеры ресурсов". И вот почему. Только в этом году ко мне обращались 2 потенциальных заказчика, продолжающиеся обсуждения с которыми выводят на этот предмет. Это - разработческие круги Харьковского завода им.Малышева и Луганского тепловозостроительного. Первые производят танки, вторые, соответственно - тапловозы . Оба - крупнейшие производители в Европе ("сесть" на такого заказчика - этого хватает на всю жизнь). Называю имена: а).чтоб не быть голословным и б).чтоб лучше "въехать" в предметную область. У них один и тот же truble: им нужны "многомашинные" управляющие системы (N prom-PC), и они "на дух" не видят в своих изделиях никаких Ethernet и даже сами называют "кандидатов": RS-422, RS-485, CAN. Во первых, "золотое правило" гласит, что "заказчик всегда прав", по крайней мере, к его мнению следует прислушаться, или предложить что-то в близкой сфере (мне вот dmi подсказывает - Modbus). Или ещё нечто.

Я предполагаю, что с подобными проблемами (с заказчиком) столкнётся всяк, кто подойдёт к встроенным системам, по крайней мере, транспортного базирования. Тех, кто интересуется подобным кругом задач (и заказчиков), я пригласил бы совместно поработать (именно поработать) над выработкой позиций в отношении таких задач.

2-я контрольная точка: тех, кого не интересует очерченный круг проблем, я очень просил бы (именно просил!) - не мешать. Если у вас нет мнения по этому вопросу, вам это просто неинтересно, если вы противник крупных индустриальных заказчиков (есть такая группа, твёрдо усвоившая предисловия из либеральной прессы об "исторической предопределённости" "малого" бизнеса) - просьба не вмешиваться: в форуме масса других интересных и приятных тем. Это замечание не относится ни к какому конкретному лицу, но, всего лишь, просьба дать заинтересованному меншинству спокойно поработать.

Небольшое лирическое отступление: есть такой общеупотребимый термин "мозговой штурм", но, к моему удивлению, многие его употребляющие не имеют представления, о чём конкретно идёт речь. А это всего лишь лруг организационных мероприятий, которые требуют:
- создать комфортные условия (в натуре - кофе там принести...);
- позволить высказывать и обсуждать любые, самые бредовые предположения;
- разрешить позитивные высказывания по проблеме и запретить ссылаться на предыдущие мнения (и тем более критически ссылаться);
- всё это делается под стенограмму (запись), а любые решения принимаются существенно позже, только на основе этой стенограммы.
Примерно на таких основах хотелось бы обсудить предлагаемую тематику.

Небольшое рациональное замечание: нет технических проблем сделать такое обсуждение закрытым - через рассылку, закрытый IRC-канал,... Как-то dmi предлагал наделить меня полномочиями модератора, но как-то всё ненужно это было. Но, видит Бог, если не удасться спокойно поработать над этим крайне важным для использования QNX вопросом - то обсуждение придётся сделать закрытым. Пусть всякий, кого всё это не интересует, прежде чем создать препятствия нормальной работе, подумает: на сайте ежедневно >200 юзеров (я смотрю статистику почти ежедневно), кому-то что-то из этого обсуждения может понадобиться завтра, послезавтра ... но, увы, обсуждения в форуме к тому времени окажется закрытым.

Возвращаемся к постановеке проблемы.

Прежде всего, повторюсь, общая черта - много компьютеров промисполнения (2-5-15 не важно), разнесённых территориально, каждый обслуживает группу агрегатов или подсистему и приближён к этой группе, степень автономизации достаточно высокая, интенсивность обмена - умеренная или даже низкая.

Почему индустриальные заказчики мобильных систем даже рассматривать не хотят привычные сетевые технологии (напр.Ethrnet):

- тянуть 100Мb многоуровневые (!) сигналы мимо силовых агрегатов в несколько сот квт. их не прельщает (можно согласиться);
- не устраивает звездообразная топология: если бы это был некоторый надёжный конструктив BNC (без разборных соединений?), вопрос ещё можно было бы обсуждать;
- всё упирается в провода и разводку (на некоторых технических устройствах их и так до 30000км. - ~5 раз вокруг земли). Тянуть отдельную линию на каждый агрегатный компьютер - не представляется возможным;
- лишняя конструктивная единица - хаб - куда его девать?
- оптоволоконика? дорого, но и это (для них) не главное. Как поведёт себя оптоволокно в условиях долговременных (3-5-10 лет) постоянных вибраций (старение, разрушение). На это и производители не могут дать ответ.
- но самое главное - это сферы и люди традиционно "приборные", они предрасположены к промышленным и приборным интерфейсам, им это проще, понятнее и они больше доверяют сертифицирующим (стандартизующим) инстанциям (международным) этой области!

Пожалуй, самый предпочтительный для этих сфер применения - RS-485.  

Sergey пишет:
А 232, 485 да хоть токовая петля, это всего-лиш железо.


Так оно, да и не так. На этом железе (и RS-422) висит 32 (и то это определяется электрически, на новых моделях и 128 и 256) процессорных плат, симметрично, и обменивающихся на скоростях 10Мбит/сек (на некоторых - 35Мбит/сек). Протоколы выше физических требований к среде (кабель, нагрузки...) не стандартизованы. Со стороны prom-PC - полный /ser: одна из реализаций - автономные переходники на com-разъёмы (RS-232 <-> RS-485).

Вопросов к такой среде у меня много, но, чтоб не мельчить, они все означают: можем мы в такой среде, увязав /ser каждого хоста с IP, организовать в такой подсетке организовать обмен TCP/IP (и именно TCP, ну, на худой конец, UDP, а не только IP или неформатированный ICMP).

Понятно, что RS-485 - это вариант, может быть могут предложены к рассмотрению другие стандарты, протоколы и интерфейсы.

Поскольку эта тема переполнена, в ней уже "шевелиться" невозможно, то это - только постановка вопроса. Если кто-то что-то может сказать по этому вопросу, или видит интерес свой в том, чтоб "поковыряться", то я сделаю просто новую тему, скажем "Промышленные интерфейсы", тем более, что тема действительно новая, а предварительно "копать" её в связи с RS-232 - это, конечно, была провокация, но без злого умысла.
Записан
Evgeniy
Jr. Member
**
Offline Offline

Сообщений: 73


Просмотр профиля
« Ответ #35 : Апреля 02, 2002, 05:11:00 pm »

Olej!
Пока вы не зарядили новую тему - пишу здесь

Судя по всему, проблема промышленных устройств коммуникации вас крепко достала. С учетом ваших потенциальных заказчиков, для вас предпочтительно железо "местного разлива".
В такой ситуации могу посоветовать посмотреть на то что предлагает Северодонецк.
У них есть как магистральные адаптеры, так и оборудование типа точка-точка. Сегодня это оборудование применяется на ГРЭС и АЭС.

Если вас интересуют подробности по этому оборудованию - могу дать коордтнаты прямо в Харькове. Можно в форуме или лично - как вам удобнее.
К сожалению, там не работают с QNX, но драйвера под DOS, OS/2 и Linux для этого железа там делали - так что, по крайней мере, "железо" они знают и смогут помочь.
Какие-то наработки под QNX 4* были в самом Севдоне, но чем там все закончилось - не знаю.
Записан
DigiMind
Гость
« Ответ #36 : Апреля 03, 2002, 04:47:00 am »


У них один и тот же truble: им нужны "многомашинные" управляющие системы (N prom-PC), и они "на дух" не видят в своих изделиях никаких Ethernet и даже сами называют "кандидатов": RS-422, RS-485, CAN. Во первых, "золотое правило" гласит, что "заказчик всегда прав", по крайней мере, к его мнению следует прислушаться, или предложить что-то в близкой сфере (мне вот dmi подсказывает - Modbus). Или ещё нечто.

Шайтан . Я как раз третий день этот ModBus (и его TCP-модификацию ковыряю). Начал тесты писать.
Вот так совпадения .
Записан
BAT
Гость
« Ответ #37 : Апреля 03, 2002, 05:20:00 am »

 Здравствуйте уважаемые!
Вопрос, поднимаемый в этой теме, действительно очень важный. Собираемся применить систему для работы на подводных аппаратах. Там сеть довольно специфическая. Пульты завязаны между собой обычными сетевыми картами, а нижняя  машина связывается с верхом по RS-232 (естественно не напрямую, а полудуплекс через специальный модем  ). Абонентов может быть больше. Итого, было бы неплохо обеспечить прозрачность для всей сети.
Прочитав, что dmi посоветовал в самом начале темы,  сразу начал пробовать. Кстати, devn-fd.so на 6.1 у меня на машине уже был. В результате появились новые устройсва в системе, пинг с тогоже  компьютера проходит, а вот с подключенного по  RS что-то не идет никак (физически связь надежная, проверил до начала эксперимента).
Отсюда просьба, если кто-то добился полного результата, то может где-то степ бай степ опишет действия? А еще неплохо было бы разобраться, как обеспечить прозрачность дальше через ethernet,  и не тольлко для TCP, но и для QNET.


[ Это Сообщение было отредактировано: BAT в 2002-04-03 02:30 ]

[ Это Сообщение было отредактировано: BAT в 2002-04-03 02:35 ]
Записан
lestat
QOR.Moderator
*****
Offline Offline

Сообщений: 985


I don't trust anything


Просмотр профиля WWW
« Ответ #38 : Апреля 03, 2002, 05:43:00 am »


Это - разработческие круги Харьковского завода им.Малышева и Луганского тепловозостроительного. Первые производят танки, вторые, соответственно - тапловозы . Оба - крупнейшие производители в Европе ("сесть" на такого заказчика - этого хватает на всю жизнь). Называю имена: а).чтоб не быть голословным и б).чтоб лучше "въехать" в предметную область.


Из всего прочитанного не совсем понятна топология сетевого проекта и конкретная постановка задачи (чтоб лучше "въехать" )


У них один и тот же truble: им нужны "многомашинные" управляющие системы (N prom-PC), и они "на дух" не видят в своих изделиях никаких Ethernet и даже сами называют "кандидатов": RS-422, RS-485, CAN. Во первых, "золотое правило" гласит, что "заказчик всегда прав", по крайней мере, к его мнению следует прислушаться, или предложить что-то в близкой сфере (мне вот dmi подсказывает - Modbus). Или ещё нечто.


Как показывает практика, заказчик вообще не должен выставлять требования к железу и его типу. Роль заказчика такова, что он хочет НЕЧТО, которое он подробно описывает прилагая все сопутствующие материалы в виде документации и требования к НИОКР. Если заказчик навязывает частично готовые аппаратные решения и настаивает на них, то обычно это к добру не приводит.

Olej не любит голых слов, поэтому приведу хороший пример из жизни, большая просьба - не выносить все сказанное ниже за пределы форума, прошу просто по-человечески.

Весна 2001 года, принимается решение о том, что необходим пропускной контроль на Киевском пригородном вокзале, недолго думая (или долго) заказчик (УкрЗализныця) закупает турникеты производства МалоЯрославского некоторого завода (по слухам, такие же стоят в Москве на пригородном вокзале), ставят перед фактом: железо у нас есть - с вас готовая система. Мозг турникета - микроконтроллер на базе 8051. Софт для мозга турникета поставляет производитель турникетов. Внешне и по параметрам турникет очень красив, реверсивный, три состояния индикации, отображающие его текущее состояние, на этом пожалуй все. Время разработки - три месяца (с проектированием, может кто читал книгу "Путь камикадзе" тот поймет, что значат три месяца для разработчика). Причем это время - для разработки всей системы, в которой турникеты - 5%.

Вернемся к нашим баранам (С) Кавказкая пленница

Надо сказать, что высокоуровневый софт для турникета писал я - лазерные считыватели штрих-кодов, безконтактные карточки, логика пропуска пассажиров. Т.к. турникет реверсивный, то решено было сделать проход с обоих сторон сразу, причем в разных комбинациях, свободный выход с перрона, вход по билетом на перон, и т.п. Проблема первая, турникет не хотел работать в вышеуказанном режиме - виноват софт мозга турникета, заявка, волокита, присылают обновление вместе со своими людьми, вроде проблема решена. Проблема вторая - индикация состояния турникета, в некоторых комбинациях была совсем неверная, нами было решено взять управление индикацией на себя, благо GPIO портов на мамке было 16. Все турникеты должны поддерживать режим паники, т.е. опускать все что у них стоит или открывать все что закрыто, для свободного прохождения людей, эти турникеты не смогли пропускать больше 1 человека за раз, если второй подходил сзади, то его било створками (мозг турникета), пришлось сделать полуавтоматическое отключение питания. Проблемы всплывали одна за другой: обогрев на морозе, т.к. мороза не было, проверить его мы не смогли, производитель не смог сообщить как искусственно проверить обогрев, как оказалось зимой - обогрев грел не то, что надо, пришлось ставить свой. И еще очень много проблемю.

Я ни в коем случае не хочу облить грязью производителей этих турникетов - эти турникеты делались для другой высокоуровневой аппаратуры, вместо нее мы ставили свою, а он под нее не был расчитан - это главная мысль моего повествования. Тем не менее мы все сделали, уже скоро год, как все безупречно работает, но сколько крови нам это стоило, особенно отказаться от RS-485 в пользу Ethernet. Благодаря Ethernet была сделана распределенный баланс нагрузки на сервера, в случае аварийного режима турникеты объединяются в один большой кластер, распределенная база данных и т.п. вкусности.

Сразу хочу ответить Olej, что стоимость свитчей, далеко не соизмерима со сложностью разработки проекта на RS-485.

И все-таки если ты обрисуешь топологию объекта, тогда можно что-то конкретно советовать ...


Прежде всего, повторюсь, общая черта - много компьютеров промисполнения (2-5-15 не важно), разнесённых территориально, каждый обслуживает группу агрегатов или подсистему и приближён к этой группе, степень автономизации достаточно высокая, интенсивность обмена - умеренная или даже низкая.


А как насчет требований к realtime ? ОНО там есть или его нет ?


- оптоволоконика? дорого, но и это (для них) не главное. Как поведёт себя оптоволокно в условиях долговременных (3-5-10 лет) постоянных вибраций (старение, разрушение). На это и производители не могут дать ответ.


Уже лет пять лежит под железнодорожным полотном, еще и 50 пролежит


- но самое главное - это сферы и люди традиционно "приборные", они предрасположены к промышленным и приборным интерфейсам, им это проще, понятнее и они больше доверяют сертифицирующим (стандартизующим) инстанциям (международным) этой области!


Ну тогда схема "стандартная" железки по сбору информации - стандартные, отсылают свои данные некоторому АРМ, который показывает состояние объектов.


Вопросов к такой среде у меня много, но, чтоб не мельчить, они все означают: можем мы в такой среде, увязав /ser каждого хоста с IP, организовать в такой подсетке организовать обмен TCP/IP (и именно TCP, ну, на худой конец, UDP, а не только IP или неформатированный ICMP).


Кстати использовать TCP в промышленных объектах (особенно реального времени - это грубая ошибка). Если хочешь, я тебе приведу свои доводы, только наверное давай в новой теме, потому что тут уже тесно. А использовать надо UDP.


просто новую тему, скажем "Промышленные интерфейсы", тем более, что тема действительно новая, а предварительно "копать" её в связи с RS-232 - это, конечно, была провокация, но без злого умысла.


Ну и еще TCP vs UDP А еще надо серьезно подумать, а нужна ли там QNX ? Во многих объектах использование Linux не только облегчает жизнь, а еще и цену объекта.

Да и железок под Linux больше будет, и драйверки регулярнее, а стоимость разработки драйверов под QNX может перекрыть всю выгоду от его использования ...
Записан

DigiMind
Гость
« Ответ #39 : Апреля 03, 2002, 05:50:00 am »


Кстати использовать TCP в промышленных объектах (особенно реального времени - это грубая ошибка). Если хочешь, я тебе приведу свои доводы, только наверное давай в новой теме, потому что тут уже тесно. А использовать надо UDP.

Интересно, интересно .

Ну и еще TCP vs UDP А еще надо серьезно подумать, а нужна ли там QNX ? Во многих объектах использование Linux не только облегчает жизнь, а еще и цену объекта.
Да и железок под Linux больше будет, и драйверки регулярнее, а стоимость разработки драйверов под QNX может перекрыть всю выгоду от его использования ...

Давайте - в новый тред. Этот уже растолстел "неимоверно"
Записан
dmi
QOR.Admin
*****
Offline Offline

Сообщений: 469



Просмотр профиля
« Ответ #40 : Апреля 16, 2002, 06:44:00 pm »


DigiMind пишет:
Шайтан . Я как раз третий день этот ModBus (и его TCP-модификацию ковыряю). Начал тесты писать.
Вот так совпадения .

Ха, успехов
Если что - пиши,  я в этой штуке неплохо разобрался. Только у меня RTU. Но и TCP не проблема.
dmi@ml.qnx.org.ru кстати уже работает.
Записан
DigiMind
Гость
« Ответ #41 : Апреля 17, 2002, 09:28:00 am »


Ха, успехов
Если что - пиши,  я в этой штуке неплохо разобрался.

Спасибо
RTU-master уже сделал. Теперь осталось превратить его в ModBus/TCP шлюз, и сервер переписать под это дело.
Записан
T_i_m_u_r_l_a_n
Участник
*
Offline Offline

Сообщений: 30


Просмотр профиля
« Ответ #42 : Апреля 22, 2015, 12:54:50 pm »

Реально. Но опасно. Лучше делать на ВЫДАЧУ из QNX, а не на прием в QNX. И еще, мало кто помнит - разработчики под QNX должны уметь восстановть любую систему или свой софт ОЧЕНЬ быстро. Люди в аэропорту больше 2-х суток точно самолета (как и поезда) ждать не будут. Удачи в принятии безопасных и безотказных решений.
Я уже молчу про медицинское оборудование и инсулиновые помпы.
Записан
Страниц: 1 2 [3]
  Печать  
 
Перейти в: