Вид для печати
Всем привет!
На мой взгляд в среде OWEN Logic не хватает тригонометрических функций, таких как SIN и COS.
Мне, в моём первом опыте программирования ПР114, пришлось создавать макрос с приблизительным расчётом косинуса угла, подгоняя его под табличные значения.
Добрый день. А если не секрет - зачем такие функции в программируемом реле, предназначенном для создания не очень сложных систем управления. Язык на мой взгляд сделан по аналогии старых стандартных логических микросхем. А они в общем то никогда особо и не были предназначены для выполнения сложных арифметических операций. Для математики - это уже более сложный контроллер, у которого и быстродействие побольше.
Может я конечно что то и не понимаю, но для решения производственных задач мне такие функции пока ни разу не требовались.
С уважением.
Уже несколько раз выкладывались, ищите, скорей всего в "макросах"!Цитата:
Сообщение от POMAXA
Здравствуйте.Цитата:
Сообщение от maximov2009
В моём случае, не совсем стандартное применение этого реле. Мы производим высотную технику (автоподъёмники и автолестницы), и в зависимости от сложности, мы проектируем три типа систем управления. В данном случае, на ПР114, выбор пал из-за низкой цены. COS необходим для расчёта вылета стрелы в зависимости от угла наклона и длины стрелы.
Вообще, было бы интересно в Owen Logic сделать online базу макросов.Цитата:
Сообщение от POMAXA
Сейчас макросы на форумах проскакивают туда-сюда.
А если бы в самой среде была возможность "найти в online базе"/"добавить в базу"/"написать комментарий" -- было бы полезно.
Онлайн база макросов есть ,только заполняют ее в Овен ,а им похоже некогда ..И две темы про макросы есть на форуме ..
вот вам синус или тут где то рядом http://www.owen.ru/forum/showthread....l=1#post107897Цитата:
Сообщение от POMAXA
Здравствуйте.Цитата:
Сообщение от rovki
Спасибо. Этот макрос я уже исследовал, он абсолютно не работает, отклонение от настоящего синуса (я проверял в диапазоне углов 0 - 90) составляет примерно 0,25, а это в моём случае, при длине стрелы 30 метров, порядка 7-8 метров.
который из 2 макросов проверили.У первого угол задается в градусах (целочисленных) ,естественно точность будет +-1гр по входу...
А у 2 макроса задание в радианах ,выбирайте что нужно ...
Вот моя версия косинуса 0 до 90 градусов. Точность, в моём случае, порядка 15 см
Проверил с градусами.Цитата:
Сообщение от rovki
Что ж так много раз проверили ?
Вот я наклонировал сообщений, пытался удалить, все удаляются.
Не привык ещё.
Ну так добавьте еще один член ряда ,получите большую точность ...если нужно.Цитата:
Сообщение от POMAXA
Пока не нужно, всё устраивает.Цитата:
Сообщение от rovki
Цитата:
Сообщение от POMAXA
Раскладывать в ряды это неправильный подход.Цитата:
Сообщение от rovki
У разложений в ряды цель -- приблизить функцию в окрестности. А при "приближенном вычислении sin/cos" важнее "минимизировать общую ошибку на интервале".
Нужно так делать: http://lab.polygonal.de/?p=205 (если есть плавающая точка). Или так: http://www.coranac.com/2009/07/sines/ (если в целых числах)
Категоричные выводы не приветствую ....Только калькуляторы об этом не знают ;) .Нам бы реализацию к теории ...(в рамках элементов ПР) Может Капзап сделает ?:rolleyes:
А с интегралами знакомы?Цитата:
Сообщение от rovki
По второй ссылке есть доказательство оптимальности указанного многочлена (в части минимизации среднеквадратичного отклонения): http://www.coranac.com/2009/07/sines/#ssec-test-opt (см 24 и 25)
Ну вот никак не поверю, что вам неясно как реализовать формулу sin = 1.27323954 * x - 0.405284735 * x * x;Цитата:
Сообщение от rovki
А как после этого сделать ещё_более_точный_sin = .225 * (sin * sin - sin) + sin; тоже объяснять нужно?
Если углы в области 0...PI, то 5 умножений, 3 сложения, 0 возведений в степень, 0 условий. И при всём при этом, ошибка не превышает 2%
Вот вам график f(x)-sin(x)
А вот график (f(x)-sin(x))/sin(x)
И, да, конечно, вопрос в том, в каком диапазоне нужно вычислять.
Убедили.....:rolleyes:
Ну, пока убеждал, сам убедился, что реально всё зависит от того, в каком диапазоне нужно вычисление.Цитата:
Сообщение от rovki
Чтобы расширить диапазон иногда проще использовать sin(x)=sin(pi-x).
Т.е. не плодить лишние члены ряда, а предварительно уменьшать угол.
Вот, например, график ошибки для ((x-x3/6+x5/120)*(x<pi/2)+((pi-x)-(pi-x)3/6+(pi-x)5/120)*(x>=pi/2)
Получается ошибка не более 0.5% на интервале 0..PI, при том, что реализовано будет как "стандартное x-x3/6+x5/120", перед которым SEL(x>PI/2, PI-x, x)
Если хотите - можете попробовать мои наработки. Мне они вполне подошли. Вроде бы и народ тестировал, отзывы были не ругательные. Входные значения - в радианах, без ограничения.
Давайте я пожалуюсь.Цитата:
Сообщение от Hemann
1) Вычислять "знак числа" через POW(-1, TO_FLOAT(NOT(GT(x, 0)))) это круто.
С extract'ом же правильно поняли.
Т.е. XOR(NOT(GT(x, 0)), TO_INT(fDIV(x, pi))) и потом extract нулевого бита.
2) Подаю на вход sin_x значение 3,14158 (~179.99927 градусов), получаю на выходе -4,3E-04 == -0.00043
Реальное значение sin(3.14158) == 1.26536e-5 == 0.0000126536
Ошибка просто огроменная: целых 3600% == (0.0000126536 + 0.00043)/0.0000126536 == 36
При углах 179.97..180 градусов ошибка превышает 100%
Конечно, считать sin(x) при x порядка pi это неблагодарное занятие, но если перед "записью в Y" ещё сделать преобразование "если Y>pi/2, то записать pi-Y", то точность около pi повысится просто невероятно. Можно и y^11 выкидывать смело будет.
Вот график относительной ошибки для вашего алгоритма около pi
Владимир, как говорится у Шекспира, нет в мире совершенства. На значениях Х, близких к 0 или Pi, здорово сказывается ограничение точности как самой ПР-ки, так и метода. Однако, увеличивать количество членов ряда не имеет смысла именно из-за свойств платформы. В любом случае-писал для себя, мне подошло, может кому будет тоже полезно
Теория хорошо ,а практика лучше ..;). Часто вспоминаю AI ,умница ,хороший теоретик ,но и знания свои подтверждал примерами (проектами)..Вроде на форуме он ,но что то молчит....
Вы меня не поняли.Цитата:
Сообщение от Hemann
Количество членов ряда нужно даже уменьшать.
x9 и x11 совершенно не нужны -- они никак не добавляют точности (если добавить if (x>pi/2) { y=pi-x; } else { y=x; } предобработку)
x7 -- нужно, иначе будет некрасиво около 1.57
Вот я поправил ваш макрос sin: Вложение 22215
Выглядит так: Вложение 22217
Вот вычисление проблемного 3.14158. Видно, что правильный ответ получается с первых же членов ряда: Вложение 22219
К сожалению, отображение float в OwenLogic крайне неудачно сделано (показывает слишком мало цифр и никак не узнать все). Например, если вычислять sin(1.57), то с первых же членов ряда получается 1e0, а реально там чуть больше должно получаться на первых двух членах -- 1.004 (это при том, что синус больше 1 быть не должен %)
Разумеется, около pi всё равно будет колбасить (т.к. pi float'ом не представимо), но после поправки pi-x зона расколбаса гораздо уже. Сравните синий и красный графики. Синий ряд до x5, но с предобработкой. Красный -- до x11, но без.
Вот это уже лучше ,с примерами :rolleyes:
У меня нет ПР и пока не предвидится. Поэтому могу только руками размахивать и теоретизировать в симуляторах.Цитата:
Сообщение от rovki
Кстати, интересно:
1) Можно ли задать порядок выполнения fADD. Теоретически, нужно ряд складывать наоборот: x5/120-x3/6+x. Когда складываешь "совпадающие по величине числа" погрешность float'а меньше копится.
2) Насколько симулятор верно считает (нет ли там глюка, что внутренние вычисления идут в double)
1.порядок вычисления можно попробовать изменить если использовать явные обратные связи ...
2.это к разработчикам...
Ваши бы знания в макросы втиснуть ,цены бы не было:rolleyes: ..
Практическое пожелание - всегда помните о железе ,да же занимаясь математикой .Точность АЦП по входу ограничена 12 разрядами (двоичными) ,без учета реальных помех а это 3,5 порядка десятичных .Поэтому когда вы оперируете величинами в теоретических изысканиях 0.0000126536 не забывайте о железе.;) и соизмеряйте желания и возможности ...А в остальном ,СПАСИБО...
А вдруг кто-то опрометчиво переведёт паскали в атмосферы? И будет полный пиец.Цитата:
Поэтому когда вы оперируете величинами в теоретических изысканиях 0.0000126536 не забывайте о железе.
Владимир, замечательно! Действительно толковое дополнение!
Взываю к разработчикам ОЛ! Появление ПР200 с относительно развитой функцией индикации и редакции энергонезависимых переменных (доступных настроек проекта) настоятельно требует расширения вариантов записи проекта в прибор. Энергонезависимые переменные призваны быть сохраненными не только при выключении питания, но и при перезаливке программы в прибор. Сейчас они при заливке переписываются в значения "по умолчанию", что в реальной эксплуатации ухудшает потребительские свойства прибора, вынуждает вести протоколы настроек и восстанавливать настройки вручную. Просьба рассмотреть возможность появления в ОЛ:
1. Разделение записи проекта отдельно на функцию записи программы и функцию записи в энергонезависимые переменные значений "по умолчанию"+ системные переменные, назначаемые в настройках проекта (границы AI, типы сигналов, параметры RS-485).
2. Дать функцию прочитать из прибора все эти переменные и автоматически внести их значения в проект, или хотя бы прочитать в файл пользователя, который потом можно было бы записать обратно или в другой прибор.
3. Расширить список доступа к системным переменным настроек проекта (только для чтения) чтобы программа их могла видеть и реагировать на неправильно проредактированные.
Поддерживаю, проблема действительно актуальная. Не очень хочется при перезаливке заносить обратно вручную счётчики моточасов и настройки.Цитата:
Сообщение от Серёга Букашкин
Спасибо!
Зафиксировали.
, а если другой проект залили с другими сетевыми адресами и часть с теме же,а там сохранилась каша от предыдущено проекта ..Как отличить перезаливку от заливки ...Цитата:
Сообщение от flicker581
Добрый день. Вопрос о выходе описания лоджика. Скоро в продаже модули расширения будут. Добавлена возможность ОРС сервера . А описания до сих пор нет. Если бы не работа Гайнутдинов Кирилл было бы трудно. Сделайте что не будь в этом направлении.