Голосуем за доработки ПР/ОЛ

[Павел Братковский]

Ввод в таблице не активен

по моему, надо галочку включить, тогда пункт активен будет

[sa_mut]

Павел Братковский Спасибо, действительно так. Не понятно как связано начальное значение и энергонезависимость, но в эмуляторе введеное начальное значение подтягивается, только если поставлен чекбокс "энергонезависимость"

[Павел Братковский]

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

[melky]

sa_mut та пусть себе что-то выполняется, если иначе у вас никак, это не мешает поставить на выходе AND и разрешать работу выхода если = 0, 1 или 2... или не разрешать по другим условиям.

[petera]

В часах ПР минимальный отсчет 1 секунда. Если бы был регистр еще с миллисекундами - вопроса бы не было. А если нужно мерить интервалы длительностью менее секунды? В стандартном макросе UNIX_TIME миллисекунд нет. Для его приложений они и не нужны.
В предложения по доработке ОЛ предлагается внести в переменные текущего времени еще миллисекунды. Это решит все проблемы с точностью измерения времени и измерения коротких интервалов.

Значит нужно использовать информацию о времени цикла выполнения программы
Например так
Захват-1.png
Считаем сколько раз выполняется программа за одну секунду, а дальше все просто.
На выходе имеем аналог функции TIME() - время работы макроса в мс от момента включения ПР.

ЗЫ.
В эмуляторе на выходе макроса первоначальные значения появляются с некоторой задержкой.

Измеряем длительность сигнала на входе I4


Измеряем длительность работы таймера TP

[Серёга Букашкин]

Значит нужно использовать информацию о времени цикла выполнения программы

Я примерно так и делаю, только за базу беру 2с, точнее выходит. И циклы считаю счетчиком. Косвенными методами можно многого достичь, но зачем усложнять только потому что в ОЛ нет средств счета в миллисекундах. Поэтому и прошу добавить средства чтобы упростить эту процедуру.
Ваш метод тоже интересен, но требует опытности в таких делах. Много расчетов производится ради элементарной по сути функции. И только потому что не решается напрямую.
Кстати это относится и к макросу FSEL. Нужен просто FB для этого. Но это вроде как обещают сделать в новом релизе.

[Эдуард_Н]

Надо в ПР200 и ОЛ изменить управление пользовательским меню.

[Николаев Андрей]

Надо в ПР200 и ОЛ изменить управление пользовательским меню.

Эдуард, а можно более расширенно что о чем речь и на что изменить?

[Эдуард_Н]

Эдуард, а можно более расширенно что о чем речь и на что изменить?

Где-то уже я писал об этом, очень не удобно если две строки и переход через SEL, надо нажать SEL потом кнопку вверх и если не то выбралось то нажать вниз потом опять SEL и вверх. Полная хрень, чё нельзя в ОЛ сделать что бы одна строка всегда была выделенной и при листании эта выделенность переходила от строки к строке и по нажатии на ввод осуществлялся вход в следующее меню.
http://www.owen.ru/forum/showthread....l=1#post228920
http://www.owen.ru/forum/showthread....EA%F0%E0%ED%E0

[Филоненко Владислав]

Это все мелкие доработки.
На самом деле ПР200 (и последующие приборы) имеют возможность создавать 2 и более независимо исполняемых программ ПР в режиме вытесняющей многозадачности.
При этом можно сделать одну программу высокоприоритетной и реализовывать в ней управление быстрыми процессами,
в другой разместить медленные ПИД, в третьей редкоиспользуемую логику настройки.
Т.к. Пр200 позволяет реализовать (на малой программе) цикл гораздо быстрее 1 мс - то можно резко увеличить сферу применения ПР.
И мегамакросы теперь не будут так тормозить цикл.