Фуоз-676 (Продолжение)

[lukinov]

Да так удобней, только информацию нужно переместить поверх маркера. При передвижении прикрывается ручкой курсора. А так нормально и вместо шифт можно держать свою любимую кружку с чаем.

[Реклама]

Реклама: ООО ТД Промэлектроника, ИНН: 6659197470, Тел: 8 (800) 1000-321

[CherepVM]

Всем, приветики!

Вот прога на проверку работоспособности с прошивками где +85.

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

Бо в этой проге, расчёт остался без изменений.

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

Grafik_ver.002.30.09+85.zip

[Реклама]

20% скидка на весь каталог электронных компонентов в ТМ Электроникс!

Акция "Лето ближе - цены ниже", успей сделать выгодные покупки!

Плюс весь апрель действует скидка 10% по промокоду APREL24 + 15% кэшбэк и бесплатная доставка!

Перейти на страницу акции

Реклама: ООО ТМ ЭЛЕКТРОНИКС, ИНН: 7806548420, info@tmelectronics.ru, +7(812)4094849

[yarstep]

Изменено 26 января, 2013 пользователем yarstep

[Реклама]

Выбираем схему BMS для корректной работы литий-железофосфатных (LiFePO4) аккумуляторов

 Обязательным условием долгой и стабильной работы Li-FePO4-аккумуляторов, в том числе и производства EVE Energy, является применение специализированных BMS-микросхем. Литий-железофосфатные АКБ отличаются такими характеристиками, как высокая многократность циклов заряда-разряда, безопасность, возможность быстрой зарядки, устойчивость к буферному режиму работы и приемлемая стоимость. Но для этих АКБ, также как и для других, очень важен контроль процесса заряда и разряда, а специализированных микросхем для этого вида аккумуляторов не так много. Инженеры КОМПЭЛ подготовили список имеющихся микросхем и возможных решений от разных производителей. Подробнее>>

Реклама: АО КОМПЭЛ, ИНН: 7713005406, ОГРН: 1027700032161

[IGO61]

Здравствуйте все!

Хотел даже пик (675) выбростиь, но их два и поочередно использую. Кто еще пользуется прогой, как у вас?

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

Не спешите выбрасывать 675-й МК. Может всё-таки здравый смысл восторжествует? И "мини-ФУОЗ" опять возродится?

Касательно 676-го МК. Пока здесь я пытаюсь подправить замеченные глюки программы-оригинала, добавить новый функционал к уже имеющемуся.

Меня убедили некоторые активные пользователи через ЛС категорично не отказываться от использования "магнитов на шкиву". После "стабилизации" существующей программы можно будет вернуться и к развитию "магнитов". Когда это будет - затрудняюсь сказать. Есть несколько нерешённых вопросов по основному направлению.

[IGO61]

...возможно неверная формула их расчёта...., что-то прояснилось?

Бо в этой проге, расчёт остался без изменений.

Да, Володя, те формулы что были несколько устарели. Столько времени прошло.

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

Из-за разницы в формулах (вернее, моих ошибок в формировании старых формул) непосредственно в хекс пишутся кривули при накладке после редактирования графика на график. Не важно, верхний на нижний или нижний на верхний. Это претензия не к тебе, это мой косяк при формировании старых формул.

Изменено 26 января, 2013 пользователем IGO61

[syma1961]

Относительно применённых в прогах график и как-то выкладываемых здесь формул ,тоже был не в восторге,так как вседа считал что кривая по вакуму связана с основной другой математикой(в частности умножением на 32 с последующим делением на 16 и т.д.),но не высказывался по этому поводу(чтобы не умничать). Донек когда делал свои проги тоже както не прислушивался,хотя проги были тоже неплохие,но получились не совсем верные

[IGO61]

Относительно применённых в прогах график и как-то выкладываемых здесь формул ,тоже был не в восторге...(чтобы не умничать)...

От общих фраз давайте к конкретным замечаниям. Чтоб стало ясно - где ошибка.

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

Изменено 26 января, 2013 пользователем IGO61

[CherepVM]

Вот формулы:

вычисление номера строки из оборотов:

Nstr:=Trunc(187500/xOboroti);

формирование кода для записи в таблицу:

kodUOZmax:=Trunc(4*Nstr* UOZmax/45)-addUOZc; // для первой таблицы из верхнего графика.

kodUOZmin:=Trunc(2*Nstr*(UOZmax-UOZmin)/45); // для второй таблицы из нижнего графика.

формирование значения УОЗ из кода в таблице:

UOZmax :=Okruglenie((45*(kodUOZmax+addUOZc))/(4*Nstr)); //из первой таблицы для верхнего графика.

UOZmin :=Okruglenie((45*(kodUOZmax-2*kodUOZmin))/(4*Nstr)); // из второй таблицы для нижнего графика.

Trunc - функция отсекания дробной части..., остается только целая.

Okruglenie - функция округления до второго знака после запятой.

Nstr - номер строки в таблице.

UOZmax - значение УОЗ верхнего графика, число хх,хх.

UOZmin - значение УОЗ нижнего графика, число хх,хх.

kodUOZmax - код из/для первой таблицы, число - один байт.

kodUOZmin - код из/для второй таблицы, число - один байт.

addUOZc - добавочная константа, например 85.

Изменено 26 января, 2013 пользователем CherepVM

[syma1961]

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

Изменено 26 января, 2013 пользователем syma1961

[syma1961]

я например это понимаю так(для формирования ПЕРВОЙ базовой кривой)... Прога считывает значения первой таблицы(не учитывая коды 34),далее считает по неким формулам и переводит номер строки(опять таки как считать,кто то считает с о,ктото с 1)в оьороты,затем тоже по отдельным формулам переводятся табличные значения в улы.... Всё для первого графика-имеем основу того что выводится на экран....только после этого можно обсуждать способ вывода второй кривой из второй таблицы......Где то так... я например часто обманывал прогу график и смотел то что делал под себя в ней.даже с одним графиком-заьивая туда просто 0000

Изменено 26 января, 2013 пользователем syma1961

[IGO61]

Полное описание формул программы "График" Владимир не выкладывал никогда, сделал только сейчас. Раньше это не имело смысла. Формулы, которые я "накопал" из прошивки и из Авторских "Екселей" находятся здесь. Можно с ними ознакомиться.

Есть! Нашёл ошибку в формулах. Мне надо денёк на прАвку, устранение.

Андрей, то что ты пишешь - "График" уже делает. Даже больше - он пересчитывает контрольные суммы прошивок. Чтоб программаторы не "гавкали" ошибкой CRC. Ошибка в поданных мной Владимиру формулах несколько лет назад.

Изменено 26 января, 2013 пользователем IGO61

[Pensioner 2011]

Всем Привет.

В прошлое воскресенье протестировал прошивку 676VV_n1T, извиняюсь, что сразу не отписал срочно услали в командировку. Результаты следующие:

Запуск отличный, разгоны в городе тоже отлично, выехал специально на объездную проверить на скорости до 120 разгон нормальный выше не удалось дорога загружена.

Но заметил что во время движения загорается индикатор ХХ со старыми прошивками такого не наблюдал. При начальном угле +5 и если ОК= 0 прослушивается легкая детонация, а если ОК= -5 тогда все в норме, а раньше с F676VV_ я держал ОК на +5.

В общем ощущения положительные а пуск в особенности + + + + +.

IGO61 по возможности обратите внимание на диапазон захвата поддержки ХХ, он очень узкий менее 0,5Гц а нужно хотя бы 2Гц то есть + /- 30 об/мин. Я говорю о реальном захвате, потому что индикаторный светодиод как раз и горит в диапазоне 2Гц, но захват с ним не совпадает. Я так понимаю это все перешло из прототипа, там захват работал также.

В четверг вечером вернулся с командировки увидел версию diap_DAD залил собирался тестировать но не судьба. Вчера с утра повалил снег, сыпал сутки, замело все что можно.

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

CherepVM огромное спасибо за разработку проги Grafik.

[korad]

Всем привет! Хочу поблагодарить ВСЕХ АВТОРОВ прошивок за Ваш труд и знания. А так же за программы и выложенные прошивки для ознакомления и использования. Рад, что уже почти образовался некий коллектив МЕГАМОЗГОВ для общего дела, создания программ для авто. Плюс к этому, мне кажется, объединение поможет во-первых поделиться знаниями между авторами и выработать максимально лучший вариант. Во вторых - устранить общими усилиями ошибки, которые не получается разобрать самому, в одиночку. Ну и удачи ВСЕМ!!! А мы, простые пользователи, будем только рады новым прогам и возвожности их использовать на своем авто.

[lukinov]

Попробовал редактировать, всё нормально, по моему можно так и оставить. А груповуха понравилась, если нужно поднять весь график чуть-чуть само то.

[IGO61]

...При начальном угле +5 и если ОК= 0 прослушивается легкая детонация, а если ОК= -5 тогда все в норме, а раньше с F676VV_ я держал ОК на +5...

...диапазон захвата поддержки ХХ, он очень узкий менее 0,5Гц а нужно хотя бы 2Гц...

После моего "шаманства", вероятно, подрос реальный УОЗ, вносимый программой. Это хорошо или не очень?

Уже занимаюсь вопросом стабилизации ХХ. Захват сверху будет от 1100об/мин. Снизу - пока не определился. И задействую конечник карбюратора. По принципу "Солекса": замкнут - отслеживаем холостые, разомкнут - работаем в обход попдпрограммы стабилизации ХХ.

Почему 1100? Включил три нагрузки: печка (2-я скор), ближний свет, обогрев заднего стекла. Карбом выставил 820об/мин. Снял все нагрузки - обороты выросли до 1000...1100. Это без поддержки ХХ.

Изменено 26 января, 2013 пользователем IGO61

[donec]

Может Я чего не дочитал, и не туда лезу, но мои применяемые формулы вообще не сходятся с выше приведенными, короче сами разберетесь.

for k:=227 downto 26 do //F676VV=221; F675ok=227; F676VV_=227;

begin

ob:=30000000/k/16/10; - это понятно обороты от строки K.

grad:=180*(Data[1,k]+85)/k/16; - это перевод данных в градусы //F676VV=0; F675ok=+85; F676VV_=+50;

Chart1.SeriesList[0].AddXY(ob,grad,'',clRed);

grad:=180*(Data[1,k]+85-Data[2,k]*2)/k/16; - то-же для другой кривой //F676VV=0; F675ok=+85; F676VV_=+50;

Chart1.SeriesList[1].AddXY(ob,grad,'',clBlue);

end; // for k

Изменено 26 января, 2013 пользователем donec

[CherepVM]

UOZmax :=Okruglenie((45*(kodUOZmax+addUOZc))/(4*Nstr));

и

grad:=180*(Data[1,k]+85)/k/16;

Индентичны!!!

Например, подставляем в формулы значения: kodUOZmax=100; Nstr=100.

UOZmax = (45*(100+85)/4*100 = 20,8125

grad = 180*(100+85)/100/16 = 20,8125

Результат одинаков.

А вот здесь, и я подозревал про это:

UOZmin :=Okruglenie((45*(kodUOZmax+0-2*kodUOZmin))/(4*Nstr));

и

grad:=180*(Data[1,k]+85-Data[2,k]*2)/k/16;

Тож идентичны, только разница в том, что у меня вычетается без увеличенного на 85 значения. Игорь сказал, что нужно увеличить на 85 только обработку кодов первой таблицы, про вторую... сказал, что всё без изменений. Ездил по делам и думал, а может для нижнего графика нужно вычетать код второй таблицы из кода первой, который уже имеет +85?.... Вижу что donec так и делает.

Может из-за этого получается сыр-бор в прошивках которые обрабатывала моя прога?

Изменено 26 января, 2013 пользователем CherepVM

[CherepVM]

Щас сделаю расчёт нижнего графика и кодов второй таблицы, учитывая увеличенное значение kodUOZmax(это значение из первой таблицы) на 85, а вы проверьте как оно получилось.

Изменено 26 января, 2013 пользователем CherepVM

[syma1961]

сначало надо как мне кажется надо делать разбор прог без этих 50 и 85,возможно потом станет понятнее(ведь для чего они вводились--автор увеличивал углы верхней кривой-1я таьлица,а поскольку нельзя было увеличить значения 1ой таблицы-в некоторых местах они уже были на грани отведённой для однобайтовой организации--они и появились)

[CherepVM]

Выяснил..., оказывается, что преобразование таблица-->график у меня выполнено так как у donec, а вот при обратном преобразовании, вичетание 85 делается только для верхнего графика, вот тут и кроется наверное глючёк.

syma1961, не вопрос..., щас скину прогу у которой нет добавочной константы....

Вот...

Grafik_ver.002.30.09+00.zip

Изменено 26 января, 2013 пользователем CherepVM

[CherepVM]

Проверил как работает обратное преобразование(график-->таблица)...., всё выполняется коректно. Проверял подставляя в формулы исходные значения, получал УОЗ и потом из УОЗ в формулы и получал код..., какой код был изначально, такой получился и на выходе.

Лады..., ждём Игоря...

Есть! Нашёл ошибку в формулах. Мне надо денёк на прАвку, устранение.

[IGO61]

У-у-уф, наконец-то добрался до компа. Моя благоверная решила потренироваться в написании документов.

Да, Володя ты правильно нашёл мою ошибку в обновлённых формулах (с прибавкой 85).

В общем так, для прошивок без прибавления констант 85 или других, формулы остаются старыми - они не изменились. Перепроверил.

Для прошивок с "прибавкой 85" формулы должны иметь вид:

1). Вычисление номера строки из оборотов: Nstr:=Trunc(187500/xOboroti) - остаётся неизменной.

Формирование кода для записи в таблицу и чтения из неё:

2). Для "верхнего" графика

kodUOZmax:=Trunc(4*Nstr* UOZmax/45)-addUOZc; // для первой таблицы из верхнего графика - тоже остаётся неизменной,

но должно выполняться условие 0< kodUOZmax<255.

3). Для "нижнего" графика

kodUOZmin:=Trunc(2*Nstr*(UOZmax-UOZmin)/45); // для второй таблицы из нижнего графика - тоже остаётся неизменной и

тоже должно выполняться условие 0 < kodUOZmin<255.

Для правильной загрузки в прошивку и правильного исполнения правок при работе прошивки должно выполняться ещё условие:

для прошивок с "+85" kodUOZmax+85 > 2*kodUOZmin. ( > - больше или равно, < - меньше или равно)

Для формирования видимого УОЗ из кода в прошивке формула "верхнего" УОЗ:

UOZmax :=Okruglenie((45*(kodUOZmax+addUOZc))/(4*Nstr)); //из первой таблицы для верхнего графика - остаётся неизменной.

Само собой разумеется, что условие из п.2 касательно kodUOZmax уже выполнено.

Для формирования УОЗ "нижнего" графика из кода прошивки (вторая таблица) формула должна иметь вид:

UOZmin :=Okruglenie((45*(85+kodUOZmax-2*kodUOZmin))/(4*Nstr)); // из второй таблицы для нижнего графика.

Так же само собой разумеется, что из прошивки уже выдернуты коды, удовлетворяющие условию из п.3 касательно

взаимосвязи kodUOZmax и kodUOZmin.

Вот в отсутствии "85+" и заключалась моя ошибка при подаче формул Владимиру для адаптации "Графика" под прошивки "+85".

[CherepVM]

Всем, приветики!

Игорь, как бы то нибыло, а я сам того не подозревая, реализовал формулу получения УОЗ нижнего графика правильно(UOZmin :=Okruglenie((45*(85+kodUOZmax-2*kodUOZmin))/(4*Nstr));), это получилось само по себе и работает с первых версий с индексом [+85].

Вот этот моментв программе:

inTh:=inTabl[maxUOZc, Nstr ]+addUOZc; //получаем код первой таблицы и +85.

inTl:=inTabl[minUOZc, Nstr ]; //получаем код второй таблицы.

xOboroty:=Okruglenie(187500/ Nstr );

UOZmax :=Okruglenie((45* inTh)/(4* Nstr )); //вычисляем УОЗ для верхнего графика.

UOZmin :=Okruglenie((45*(inTh-2*inTl))/(4* Nstr )); //вычисляем УОЗ для нижнего графика.

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

maxUOZc - указатель на выборку из масива значений первой таблицы.

minUOZc - указатель на выборку из масива значений второй таблицы.

inTh - код для вычисления УОЗ верхнего графика.

inTl - код для вычисления УОЗ нижнего графика.

Обрати внимание, что значение inTh вначале получает прибавление к коду первой таблицы +85, а потом уже учавствует в формулах.

Это получилось самособой...., хотелось оставить наглядность формул, вот и вывел вычисление кодов таблиц отдельно.

Так что всё "пучком"!

[IGO61]

Здравствуйте все!

Ну и слава Богу!

Да, забыл сделать акцент. При вычитании (85+kodUOZmax-2*kodUOZmin) или (inTh-2*inTl) не должно получаться отрицательного числа, в лучшем случае нужно поставить "ограничитель" на нуле. Если в результате получится число отрицательное (в десятичном исчислении), то в прошку сформируется неверный код.

[CherepVM]

Тогда, раз формулы преобразования верны, тогда почему и где проявляется "корявость"?

Получается, только одно место...., не до конца верный анализ условий ограничений на формируемый код для прошивки и, соответственно, пределы корекции графиков. Бум проверять.... .