M_Andrey

Прорисовка у меня проходит не в callback-ах, а по другим событиям. Надо как-то WM-у указать не портить рамку, клиентскую область он-же не портит.

Имеем окно (FRAMEWIN "Состояние каналов" - рис.01), в котором (четыре раза в секунду) прорисовываем как виджеты (TEXT_SetText), так и 2D-графику (GUI_FillCircle/GUI_FillRect/GUI_DispDec). При открытии нового окна (FRAMEWIN "Тест каналов" - рис.02) рамка FRAMEWIN портится нижним окном, но только 2D-графикой, виджеты отрисовываются корректно. Клиентская область не портится. Как добиться корректной отрисовки окон. WM_Validate/WM_Invalidate не помогают.

https://softelectro.ru/program.html нужна бесплатная регистрация :)

А вам точно нужно только 20 входных константных переменных или все-таки 20 кнопок, к которым потом потребуется цеплять бесконечное число переменных с бесконечным количеством вариантов сочетания :) ?

А речь идет о переменном или постоянном токе? Если о переменном, то трансформатор тока ТС вообще не нужен. Берете ТALEMA AC-1100 (AC-1200), пропускаете через него один провод нагрузки и измеряете переменный ток 1/1000. Если о постоянном то ой.

Кстати у SHT21 есть встроенный подогрев чипа, у вас он не включен случайно?

А при чем тут калибровка. Может у вас датчик что-то греет. Может сама схема, а может горячий воздух из ноута, например :).

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

А снятие изоляции и пропайку то-же pressmaster делает?

А как их искать - перебором? Мне нужен машинный алгоритм.

Оказалось что второй способ в моем первом посте и есть реализация "подходящей дроби". Вот только беда в том что постоянное деление (1/х) в каждой итеррации приводит к погрешности при вычислении даже конечной дроби.

Не пойму как непрерывную дробь применить в моем случае. PS. А вот "подходящая дробь" мой случай :) Спасибо.

Если-бы мне надо было сделать это один раз, то я бы на калькуляторе посчитал и ввел один раз. Но эти коэффициенты наладчики будут вводить на объектах из верхнего софта (HMI SCADA), программа ПЛК получает число (double), пересчитывает в числитель и знаменатель, и передает их частотнику.

Нужно вводить коэффициент редуктора двигателя в частотник из верхнего софта.

Встала задача преобразовать число single/double в простую дробь. Классическое правило: 1.2345 = 12345 / 10000 Находим наибольший общий делитель НОД(12345,10000)=5 и сокращаем дробь: 12345 / 10000 = 2469 / 2000 Еще нашел способ: d = 0.12345; // Исходная дробь, может быть любой a0 = 0; a1 = 1; b0 = 1; b1 = 0; while(не_достигнута_нужная точность) { N = Floor(d); a = N * a1 + a0; b = N * b1 + b0; printf("%d / %d = %f\n", a, b, a/b); a0 = a1; a1 = a; b0 = b1; b1 = b; d = 1/(d - N); } Первый способ дает неоптимальные числа (слишком большие) при той-же точности, у второго в алгоритме есть дыры типа деления на ноль. Может кто-то уже проходил этот путь? Что посоветуете?

Была такая-же проблема. http://electronix.ru/forum/index.php?showt...st&p=963527

Имея over 1800 сообщений на форуме не знать возможностей языка С как-то странно.

Вопрос в том что вы хотите получить. Вам действительно нужна точность 24 бита?

Здесь acp_MSB - байт, он беззнаковый и компилятор об этом предупредит. Надо примерно так: </p><p>union long2uch { struct { struct { unsigned char l,ml,mh,h; } byte; signed long sl; } } acp; acp.byte.l = 0; acp.byte.ml = acp_LSB; acp.byte.mh = acp_Mid_Byte; acp.byte.h = acp_MSB; double znachenie_acp = acp.sl*(5.0/(2147483648*64));</p><p>

А если так: int i = (int)(A*10.0); sprintf(s_temp, "%4d.%.1d %5d", i/10, i%10, B );

ну так выложите уже

А вы начните думать с другого конца - с программирования ПЛК конечным пользователем. Codesys + PLCcore самый оптимальный по финансам вариант если нет команды с большим опытом. Это хоть какая-то гарантия что на стороне пользователя хоть что-то будет работать. Если сразу что-то не пойдет или будут проблемы, то первых клиентов вы потеряете навсегда! Если заработает, то мезанин с PLCcore попытаетесь заменить на свой с возможностью отката обратно. Codesys - золотая середина программирования ПЛК. ПЛК "Delta" с их LD (дешево и сердито) - это мрак. Step7 от Siemens (очень дорого, но очень удобно) - как ориентир на будущее. Есть еще ниша HMI+PLC в одном корпусе. Мало кто делает, немцы делают, но как всегда все дорого. Есть Mitsubishi alpha, но слабоват, ОВЕН (ПЛК63 и т.п.) - дисплей маловат. И неплохо-бы для температур до -20 (ЖКИ не тянут). И еще заливка программы. Самый оптимальный вариант - USB. У Siemens - Ethernet, Delta - COM(RS232), ОВЕН - COM(RS232), но свой кабель в RJ45, Mitsubishi alpha - программатор через COM(RS232) и т.д. Интегратор все это найдет, но когда ПЛК уйдет на объект, то там ничего этого не будет, в лучшем случае только USB (Ethernet то-же, но потребуются бОльшие знания по запуску программатора), а потребность возникнет наверняка.

У меня то-же маячит похожая задача, но попроще. Жидкость - глицерин. Так что присоединяюсь к вопросу в качестве слушателя :)

SPWF01SA.11 и SPWF01SС.11