[image]

Ракетный софт

Тема посвящена программам для расчетов ракет, двигателей, топлив.
 
1 14 15 16 17 18 19 20

RocKI

опытный

GOGI> В новых VisualStudio очень развитая система Intellisense

Кстати, давно хотел пощупать VB.Net. Только всегда останавливала запутанная ситуация с софтом. GOGI, может подскажешь, что надо? Вот рекомендуют скачать

.NET Framework Software Development Kit Version 1.1

The Microsoft® .NET Framework Software Development Kit (SDK) version 1.1 includes everything developers need to write, build, test, and deploy .NET Framework applications—documentation, samples, and command-line tools and compilers. // www.microsoft.com
 

.NET Framework Version 1.1 Redistributable Package

The .NET Framework version 1.1 redistributable package includes everything you need to run applications developed using the .NET Framework. // www.microsoft.com
 

Но это вроде только среда, а редактора там нет. Надо что, скачивать всю VisualStudio 7.0 ?
   33.0.1750.14633.0.1750.146
Не, это ничего качать не надо,
Качаешь только http://www.microsoft.com/ru-ru/download/details.aspx?id=40787 и все.
   27.027.0
KZ Xan #12.03.2014 09:33  @Бывший генералиссимус#11.03.2014 20:17
+
-
edit
 

Xan

координатор

Б.г.> Понимаешь, у меня в данных, что идут с макета СУ, вообще встречаются вещи, которые я интерпретирую просто по месту положения - там 28 байт

Я для 16 двоичных байтов добавлял один байт (0x00) для синхронизации, в потом к очередным принятым 17 байтам прикладывал шаблон - там, кроме синхробайта, некоторые другие байты не полную двоичную свободу имели, так что можно было понять, правильно ли байты легли в шаблон.
А если неправильно, то всех сдвигал на одного и добавлял следующий принятый байт. И опять шаблоном проверял.
При сбоях в связи прога легко снова синхронизировалась.
   

Xan

координатор

SashaMaks> Лучше в шестнадцатеричном виде (00...FF)

Не всякие программы легко читают шестнадцатеричные.
У меня бейсик не понимает, например.
(А эксель понимает?)
Поэтому удобнее писать в десятичных.
А потом "255 и 255 = 65535" легко сделать обычной арифметикой.
   
Xan> У меня бейсик не понимает, например.
И опять-таки .Net позволяет не думать, а просто сделать
code text
  1.             Dim TempString As String
  2.             Dim ByteValue As Byte
  3.             TempString = SerialPort1.ReadLine 'читаем строку из порта
  4.             ByteValue = Convert.ToByte(TempString, 16)'преобразовываем строку в значение типа байт, считая что строка это текстовое представление числа в 16-ричной системе
   27.027.0
RU Бывший генералиссимус #12.03.2014 13:01  @GOGI#12.03.2014 10:54
+
-
edit
 
Xan>> У меня бейсик не понимает, например.
GOGI> И опять-таки .Net позволяет не думать, а просто сделать

Ха, а, если там 26 байт, из которых 24 - это 6 16-битных двоичных чисел, а ещё 2 - это просто двоичные числа, но попадающие в диапазон ASCII?
   11.011.0
RU GOGI #12.03.2014 13:33  @Бывший генералиссимус#12.03.2014 13:01
+
-
edit
 
Б.г.> Ха, а, если там 26 байт, из которых 24 - это 6 16-битных двоичных чисел, а ещё 2 - это просто двоичные числа, но попадающие в диапазон ASCII?
code text
  1.             Dim TempString As String
  2.             Dim ByteValue As Byte
  3.             Dim ByteBuffer(25) As Byte
  4.             While SerialPort1.BytesToRead < 26
  5.             End While
  6.             SerialPort1.Read(ByteBuffer, 0, ByteBuffer.Length) 'читаем из порта в массив Byte
  7.             TempString = System.Text.Encoding.ASCII.GetString(ByteBuffer, 0, 24) Конвертируем часть массива байт в строку
  8.             For TempCounter As Integer = 0 To 21 Step 2
  9.                 Debug.Print(Convert.ToUInt16(TempString.Substring(TempCounter, 4), 16)) 'преобразовываем текстовые представления шестнадцатеричных чисел в значения Uint16
  10.             Next
  11.             Debug.Print(BitConverter.ToUInt16(ByteBuffer, 24)) 'два последних байта преобразовываем в Uint16
   27.027.0

SashaMaks
SashaPro

аксакал

Xan> Не всякие программы легко читают шестнадцатеричные.

Программы? Тут их создают...

Xan> У меня бейсик не понимает, например.

Попробуй добавить # или $ перед строковой записью FF. А вообще, печально.

Xan> (А эксель понимает?)

Эксель работает с типом Variant, ему ты отправишь переменную числового типа (не строкового), которую он будет сам распознавать.

Xan> Поэтому удобнее писать в десятичных.
Xan> А потом "255 и 255 = 65535" легко сделать обычной арифметикой.

Не понял, почему "по этому".
Строка в любом случае изначально будет преобразована к числовому типу, а потом будет передана в Эксель в тип вариант, где Эксель сам будет думать, что ему подсунули.
А скорость преобразования строк 255 и $FF в число одинаковая.
   27.027.0
RU SashaMaks #12.03.2014 20:02  @SashaMaks#12.03.2014 19:31
+
-
edit
 

SashaMaks
SashaPro

аксакал

SashaMaks> А скорость преобразования строк 255 и $FF в число одинаковая.

Хотя с добавлением дополнительного символа указателя вроде # или $ время преобразования увеличивается в 1,5 раза, но это только на машине приёмнике, которая всё равно успеет всё сделать на лету, так как от МК данные идут всяко медленней, чем нужно чтобы завис хотя бы ноутбук с процем на 1ГГЦ...

А вот, МК от такого способа передачи данных здорово выигрывает, так как, чтобы составить строку FF вместо 255 потребуется в два раза меньше времени МК и передать можно в 1,5 раза больше данных по COM не меняя скорости пересыла.

Поэтому передача байтов чисел в строке по порту COM оптимальна в шестнадцатеричном формате FF для системы МК->COM->ПК.
   27.027.0
RU SashaMaks #12.03.2014 20:08  @SashaMaks#12.03.2014 20:02
+
-
edit
 

SashaMaks
SashaPro

аксакал

SashaMaks> Хотя с добавлением дополнительного символа указателя вроде # или $ время преобразования увеличивается в 1,5 раза...

:-Р
А если ещё накатать свою функцию преобразования из строки в число, в которой не будет различаться десятичное число от шестнадцатеричного с помощью вспомогательного символа, а сразу вся строка будет переводится по умолчанию из шестнадцатеричного формата, то скорость преобразования будет всё-таки одинаковая.

SashaMaks> Поэтому передача байтов чисел в строке по порту COM оптимальна в шестнадцатеричном формате FF для системы МК->COM->ПК.
   27.027.0
RU SashaMaks #12.03.2014 22:58  @SashaMaks#12.03.2014 20:02
+
-
edit
 

SashaMaks
SashaPro

аксакал

SashaMaks> А вот, МК от такого способа передачи данных здорово выигрывает ... можно в 1,5 раза больше данных по COM не меняя скорости пересыла.

Для МК:
Замерил алгоритмы на скорость и получилось, что в 16-18 раз быстрее кодировать байт в шестнадцатеричную строку FF, чем в десятичную 255.

Для ПК:
Декодирование также выигрывает, если собственную рукописную функцию применить, но не сильно процентов на 10-20%.
   27.027.0
RU Бывший генералиссимус #12.03.2014 23:41  @SashaMaks#12.03.2014 22:58
+
-
edit
 
SashaMaks>> А вот, МК от такого способа передачи данных здорово выигрывает ... можно в 1,5 раза больше данных по COM не меняя скорости пересыла.

Ещё быстрее - в base64, но это на МК программировать утомительно :)

SashaMaks> Для МК:
SashaMaks> Замерил алгоритмы на скорость и получилось, что в 16-18 раз быстрее кодировать байт в шестнадцатеричную строку FF, чем в десятичную 255.

Подтверждаю. Не только быстрее, но и меньше кода.

SashaMaks> Для ПК:
SashaMaks> Декодирование также выигрывает, если собственную рукописную функцию применить, но не сильно процентов на 10-20%.

Совершенно несущественно. Даже самописная программа на фрибэйсике преобразует мегабайтные таблицы за младшие десятки секунд - у меня данные идут на 115200 без пауз, "выведение на орбиту" занимает 300 секунд, это 3,5 мегабайта.
Из HEX.TXT в capture.csv конвертируется за 12-13 секунд. Хотя программа абсолютно однотредовая, и 7/8 моего core i7 использовать не может.
   11.011.0
RU SashaMaks #13.03.2014 00:01  @Бывший генералиссимус#12.03.2014 23:41
+
-
edit
 

SashaMaks
SashaPro

аксакал

Б.г.> Из HEX.TXT в capture.csv конвертируется за 12-13 секунд. Хотя программа абсолютно однотредовая, и 7/8 моего core i7 использовать не может.

А у меня на лету всё происходит. Данные сразу же обрабатываются в буфере оперативке и тут же выводятся на экран. Всё в двух потоках реализовано так, чтобы один поток на одном ядре работал только по приёму и сохранению данных в памяти, а второй поток использует второе ядро проца для визуального отображения поступающей информации в реальном времени.
Поскольку проц 2-х ядерный, то по статистике загрузки видно, что один поток вообще почти не загружен, а второй на 50% занят рисованием графика.

Нетбук Б/У и довольно медленный даже 3D ускорение не помогает существенно, зато это дисциплинирует не разбрасываться ресурсами)))

П.С. Ексель, тоже сильно тормознутая штука, особенно, когда точек для графика будет больше 10000. Я его теперь только для конечных отчётов использовать буду, даже специально для него собственный кодек сжатия данных разработал на подобие mp3...
   27.027.0
RU SashaMaks #13.03.2014 03:06  @SashaMaks#13.03.2014 00:01
+
-
edit
 

SashaMaks
SashaPro

аксакал

SashaMaks> А у меня на лету всё происходит.

Небольшой анонс.
Вот так работает этот модуль на обычном ПК с 6-и ядерным процем. Загрузки вообще никакой не заметно.
Решил переписать преобразование строки FF в число, так как при использовании новой своей функции время сокращалось на тестах с 1,4с до 0,7с, что меньше, чем и у исходной функции с 0,85с преобразования. Сделал тест на МК, чтобы точно убедится, что всё работает без сбоев и не только в симуляционном режиме.

А так получилось что-то вроде виртуального осциллографа, данные можно масштабировать по ширине и высоте, можно менять частоту развёртки, фиксировать ноль или оставить автоподстройку. И всё это работает на лету, будь там для отображения хоть сотни тысяч точек, алгоритм оптимизирован так, что отображаются только те, что попадают в масштаб экрана согласно разрешению экрана, поэтому ничего не тормозит + вся графика сделана с аппаратным 3D ускорением на технологии OpenGL с поддержкой версий от 1.0 до 4.4.

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

Xan

координатор

SashaMaks> Всё в двух потоках реализовано так, чтобы один поток на одном ядре работал только по приёму и сохранению данных в памяти

Это не поможет, если дрова приёмного железа кривые.
Раньше использовал вставляемую в комп плату MOXA с RS485.
Это как бэ шибко профессиональная железка для промэлектроники.
Мало того, что она временами вообще забывала работать.
Так когда работает, не моги ещё что-то в винде делать - ни прогу какую запустить, ни, даже, окно передвинуть. Сразу появляются ошибки "драйвер не успел забрать пришедшие байты из железа". Полный Пэ.

В своих прогах общения с компортом я всегда делаю тред чтения и ставлю ему высокий приоритет:
void MyThread(void)
{
SPriority = SetPriorityClass(GetCurrentProcess(), REALTIME_PRIORITY_CLASS);
SClass = SetThreadPriority(GetCurrentThread(), THREAD_PRIORITY_TIME_CRITICAL);
SPriority = GetPriorityClass(GetCurrentProcess());
SClass = GetThreadPriority(GetCurrentThread());
// что эти строчки значат уже не помню!!! :D
...
}
И ошибок "моя прога не успела забрать байты из буфера драйвера" не бывает.
А на драйвер MOXA я подействовать не могу, вот он и гадит.

Сейчас перешёл на FT232, у них с дровами всё в порядке.

Потребление на чтение процессора ничтожно маленькое, что таскманагер даже одного процента не показывает.
   

SashaMaks
SashaPro

аксакал

Xan> Сейчас перешёл на FT232, у них с дровами всё в порядке.

Я тоже её использую, другого и не пробовал, опыта ещё нет широкого. Она через USB работает, что удобно и даже питание всё на МК всё идет от USB, что тоже очень удобно.
   27.027.0
RU biostar_37 #22.03.2014 01:08
+
-
edit
 
RU biostar_37 #23.03.2014 20:31
+
-
edit
 

biostar_37

втянувшийся

Редактор двигателей для ОпенРокет. Для работы желательно обновить Джаву на компе.
Извиняюсь, наврал, TCtracer открывает файл рисунка кривой тяги двигателя и позволяет рисовать прямо по этому рисунку. После нанесения кривой тяги, вы вводите данные на двигатель, и он сохранит данные двигателя в формат файла RASP. Далее см. Кто чем рисует?(SpaceCAD и другие) [Mester#29.03.14 00:15]
Прикреплённые файлы:
 
   33.0.1750.15433.0.1750.154
Это сообщение редактировалось 29.03.2014 в 00:38
RU SGRMrocket #18.08.2015 16:53
+
+1
-
edit
 

SGRMrocket

новичок

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

Все ракеты - YouTube

Тут собран весь мой путь ракетостроения - от первых экспериментов до полетов //  www.youtube.com
 

Собственно причина это сообщения - это желание и возможность написать честный собственный газодинамический смулятор двигателей. У меня уже написано пара программ обсчитывающих течение газа и моделирование работы твердотопливного двигателя, но они сделаны для 2d случая и исключительно для визуальной демонстрации а не получения практических данных. Иными словами я предлагаю сделать собственный открытый ANSYS, специализированный на расчете твердотопливных двигателей (хотя с помошью такой программы можно моделировать и камеру сгарания с соплом лаваля). Кроме открытости мы получаем более простой ввод данных, лучшую оптимизацию под нашу конкретную задачу. С помошью такого симулятора мы сможем заглянуть непосредственно внурть двигателя во время работы - экспериментировать с его внутренним устройством и получать любые данные о плотности давлении и скорости газа в любой точке двигателя во время работы. Также на равне с остальными калькуляторами двигателей мы сможем получать обощенные данные двигателя во время работы - силу тяги, ускорение, сопротивление воздуха. Вот ссылка на развлекательный 2d вариант такой программы

Естественно чтобы сформулировать самому себе задачу мне будет полезен опыт и пожелания участников форума. Если моя затея не нужна сообществу, не интересна, бесполезна и бессмысленна (всеже она требует больших затрат времени и сил) то подскажите мне это, чтобы я не тратил силы и сразу погасил в себе энтузиазм.
   40.040.0
RU SashaMaks #18.08.2015 20:26  @SGRMrocket#18.08.2015 16:53
+
-
edit
 

SashaMaks
SashaPro

аксакал

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

Желание хорошее и очень полезное! Но и очень не простое. Могу только про видео сказать, что его определенно считали с очень мелкой сеткой и на очень мощных ЭВМ, скорее всего на супер компьютере.
У меня тоже были похожие идеи, но тогда про практику пришлось бы забыть. Так всё пока в мыслях и осталось.
   44.0.2403.15544.0.2403.155
RU umbriel #18.08.2015 21:13  @SGRMrocket#18.08.2015 16:53
+
-
edit
 

umbriel

опытный

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

Отличная идея. Помогу чем смогу. Как у тебя с математикой?
   44.0.2403.15544.0.2403.155
RU SGRMrocket #19.08.2015 16:57  @SashaMaks#18.08.2015 20:26
+
+2
-
edit
 

SGRMrocket

новичок

SashaMaks
То что на видео я считал на сетке 1920х1080 методом годунова 2-го порядка. Обсчитывается это на обычном компьютере с многопоточностью со скоростью 1-2 кадра в минуту. Если интересно - могу скинуть эту программу (если нужен могу дать исходный код) она написана на с++ под виндовс.
umbriel
В университете у меня была специальность "прикладная математика" и, так получилось, что вся моя кафедра как раз занималась численными методами сплошных сред. Поэтому я и пишу для себя, для удовольствия всякие симуляторы, как на предстваленном выше видео. Сейчас их у меня написано 2 штуки - один для визуализации ракет на с++ с многопоточностью и второй - универсальный симулятор позволяющий можелировать подкрашенный газ, написанный на cuda с расчетом на нескольких видеокартах. Могу предоставить исходные коды (проекты) обоих, если интересно. Собственно началось все с любви к ракетам (а она у меня с детства) - после окончания вуза начал пытаться их делать, и поскольку мое образование позволяло, появилось желание не только делать ракеты, но и с помошью компьютера смоделировать то что я делаю. Точные результаты мне было делать лень и они не представлялись такими интересными, поэтому я все сделал с параметрами "на глаз" - лишь бы было правильно с точки зрения законов сплошных сред и красиво на глаз. Но осталось ощущение что я не раскрыл потенциал тех технологий которыми владею, поэтому и думаю сейчас над применением их для действительно полезных целей.

Для реализации такого симулятора сразу появляются следующие вопросы и проблемы
1) Так как я собираюсь рассматривать его как opensource проект - необходимо выбрать техническую среду для расчетов. Это может быть или процессор (что просто в разработке, доступно много памяти, но медленно) или видеокарта (все плохо кроме скорости расчета). Для расчета на видеокартах опять встает выбор технологий - CUDA (более быстрый и у меня уже есть опыт написания такой программы на нем, но не универсальный) или openCL (я его не знаю, менее быстрый но универсальный). Поскольку мы будем моделировать в 3d, предположив что для одной ячейки пространства нам требуется 8 значений (плотность, давление, 3 скорости + еще какие-то параметры газа) для симуляции сетки размером 512х512х512 нам потребуется 4 гигобайта памяти. Учитывая что и считать все это весьма трудемкое занятие - думаю нужно изначально нацеливаться именно на видеокарты.
2) У меня нет опыта депараметризации такой задачи и собственно настройки параметров под реальные данные (умею только применять разностные схемы). Также мне не известны законы горения топлив, важность теплопроводности, передачи энергии внутри топлива путем светимости газа.
3) Касательно вводных данных - в предыдущих своих 2D программах я делал вводные данные данные через .bmp картинки и описания значений цветов. Как сделать простой и универсальный способ задать 3-х мерное значение объемов пространства без использования всяких autocad форматов?
4) Касательно вывода - по хорошему мы должны сначала просчитать всю симуляцию, сохранить историю состояний процесса, а потом уже делать все замеры. Но при весе одного кадра симуляции в 4 гб - нам потребуется целый жесткий диск для сохранения прямых результатов. Альтернативный вариант - сохранять не все данные а только заранее выбранные (какой-то разрез двигателя, или значения в специально выбранных заранее точках)
5) Самое главное - есть ли действительно потребность в подобной программе. Я имею ввиду что одно дело просто разок заглянуть внутрь двигателя ради любопытства и совсем другое дело если подобное приложение действительно поможет ответить на определенные вопросы и даст практическую пользу при разработке двигателей.

Собственно главный вопрос для меня - последний, так как одну программу для "просто взглянуть" я уже имею. А хочется принести практическую пользу сообществу.
   40.040.0
19.08.2015 17:20, Skyangel: +1
RU Skyangel #19.08.2015 17:18  @SGRMrocket#19.08.2015 16:57
+
-
edit
 

Skyangel

опытный

SGRMrocket> Собственно главный вопрос для меня - последний, так как одну программу для "просто взглянуть" я уже имею. А хочется принести практическую пользу сообществу.
Делай, если считаешь нужным. И никого не спрашивай. Мнения могут быть необъективными. Время покажет.
   40.040.0
+
-
edit
 

pinko

опытный

SGRMrocket> 2) У меня нет опыта депараметризации такой задачи и собственно настройки параметров под реальные данные (умею только применять разностные схемы). Также мне не известны законы горения топлив, важность теплопроводности, передачи энергии внутри топлива путем светимости газа.

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

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

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

С уважением,
Pinko
   40.040.0
RU SashaMaks #19.08.2015 20:42  @SGRMrocket#19.08.2015 16:57
+
-
edit
 

SashaMaks
SashaPro

аксакал

SGRMrocket> Если интересно - могу скинуть эту программу (если нужен могу дать исходный код) она написана на с++ под виндовс.

О, это очень интересно и код тоже давай!

1. OpenGL выбор однозначный. Я уже начал разработку своей программы на этой основе. Ориентируюсь на небезызвестный опыт создания SolidWorks. Это даёт возможность создать примитивный 3D редактор и задавать всю необходимую для нас геометрию.

2. Память расходуется сильно, но не критично. Смежные значения можно интерполировать в интересующих сечения по узловым значениям. Именно так сделано в Flow.

3. Про физическую дотошность пока не стоит думать, главное изначально всё увязать вместе качественно, а количественно потом уже можно будет что угодно задать в том числе и с физической точностью.

4. Сохранять весь процесс в каждой точке времени и пространства нет нужды, в итоге будет важна лишь обобщенная расчётная информация, которая занимает совсем немного места. Всё остальное можно сохранить в виде видеоформатов по наиболее интересным сечениям.

SGRMrocket> Собственно главный вопрос для меня - последний, так как одну программу для "просто взглянуть" я уже имею. А хочется принести практическую пользу сообществу.

Предлагаю объединить усилия.
   44.0.2403.15544.0.2403.155
1 14 15 16 17 18 19 20

в начало страницы | новое
 
Поиск
Настройки
Твиттер сайта
Статистика
Рейтинг@Mail.ru