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

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

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

Но это вроде только среда, а редактора там нет. Надо что, скачивать всю VisualStudio 7.0 ?

Не, это ничего качать не надо,
Качаешь только http://www.microsoft.com/ru-ru/download/details.aspx?id=40787 и все.

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

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

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

Не всякие программы легко читают шестнадцатеричные.
У меня бейсик не понимает, например.
(А эксель понимает?)
Поэтому удобнее писать в десятичных.
А потом "255 и 255 = 65535" легко сделать обычной арифметикой.

Xan> У меня бейсик не понимает, например.
И опять-таки .Net позволяет не думать, а просто сделать

1.             Dim TempString As String
2.             Dim ByteValue As Byte
3.             TempString = SerialPort1.ReadLine 'читаем строку из порта
4.             ByteValue = Convert.ToByte(TempString, 16)'преобразовываем строку в значение типа байт, считая что строка это текстовое представление числа в 16-ричной системе

Xan>> У меня бейсик не понимает, например.
GOGI> И опять-таки .Net позволяет не думать, а просто сделать

Ха, а, если там 26 байт, из которых 24 - это 6 16-битных двоичных чисел, а ещё 2 - это просто двоичные числа, но попадающие в диапазон ASCII?

Б.г.> Ха, а, если там 26 байт, из которых 24 - это 6 16-битных двоичных чисел, а ещё 2 - это просто двоичные числа, но попадающие в диапазон ASCII?

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

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

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

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

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

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

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

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

Не понял, почему "по этому".
Строка в любом случае изначально будет преобразована к числовому типу, а потом будет передана в Эксель в тип вариант, где Эксель сам будет думать, что ему подсунули.
А скорость преобразования строк 255 и $FF в число одинаковая.

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

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

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

Поэтому передача байтов чисел в строке по порту COM оптимальна в шестнадцатеричном формате FF для системы МК->COM->ПК.

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


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

SashaMaks> Поэтому передача байтов чисел в строке по порту COM оптимальна в шестнадцатеричном формате FF для системы МК->COM->ПК.

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

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

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

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 использовать не может.

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

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

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

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

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

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

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

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

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());
// что эти строчки значат уже не помню!!!
...
}
И ошибок "моя прога не успела забрать байты из буфера драйвера" не бывает.
А на драйвер MOXA я подействовать не могу, вот он и гадит.

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

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

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

Я тоже её использую, другого и не пробовал, опыта ещё нет широкого. Она через USB работает, что удобно и даже питание всё на МК всё идет от USB, что тоже очень удобно.

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

Желание хорошее и очень полезное! Но и очень не простое. Могу только про видео сказать, что его определенно считали с очень мелкой сеткой и на очень мощных ЭВМ, скорее всего на супер компьютере.
У меня тоже были похожие идеи, но тогда про практику пришлось бы забыть. Так всё пока в мыслях и осталось.

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) Самое главное - есть ли действительно потребность в подобной программе. Я имею ввиду что одно дело просто разок заглянуть внутрь двигателя ради любопытства и совсем другое дело если подобное приложение действительно поможет ответить на определенные вопросы и даст практическую пользу при разработке двигателей.

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

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

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

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

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

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

С уважением,
Pinko

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

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

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

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

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

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

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

Предлагаю объединить усилия.