Codesys2.3 как можно написать программу на языке CFC чтобы на выходе был ШИМ сигнал у меня контроллер ПЛК63 выходы релейные кто что знает подскажите
Вид для печати
Codesys2.3 как можно написать программу на языке CFC чтобы на выходе был ШИМ сигнал у меня контроллер ПЛК63 выходы релейные кто что знает подскажите
ШИМ на реле — варварство.
http://images.devs-on.net/Image/oDyH...ysUntitled.png
Пример не будет работать, так как все выходы на ПЛК63 - тип REAL.
В свойствах выхода задайте период ШИМ, а значение VALUE (как в примере) необходимо подавать непосредственно на выход.
ЗЫ: Зачем темы плодить? В документации вроде всё написано.
Как в свойствах задавать период ШИМ какие параметры нужны
Не совсем понятен вопрос.... Вообще в конфигурации, в свойствах соответствующего выхода. Параметр так и называется - Период ШИМ. Задается в миллисекундах.
ЗЫ: Терзает любопытство - зачем всё это? То есть зачем ШИМ через электромеханическое реле?
потому что у меня все выходы релейные вообще возможно ШИМ сигнал через релейный выход
Ну пристали к человеку.
200..400т.раз при периоде в секунд 20..30, и с учетом того что сам объект может эксплуатироватся не круглые сутки, и с учетом что выход ШИМа может быть и 0.0 и 1.0 - может означать и год и двадцать.
Я сделал на основе блока "BLINK". Работает, проверено на практике. Если бы знал, как прикрепить проект - прикрепил бы. Заодно МЭТРЫ меня бы покритиковали. На словах - там есть два момента, которые следует участь: поскольку входной аналоговый сигнал у меня в формате REAL, то и период задается в нем же. Следовательно, требуется преобразование в TIME. Стандартный оператор преобразования в системе есть, но при отрицательных и при превышающих диапазон значениях ведет себя, на мой взгляд, плохо. (Здесь это обсуждалось, Мне объяснили, почему это так, но я говорю не о том, почему, а о том, что это неправильно). Значит,надо ограничивать сигнал. Стандартный блок ограничения, на мой взгляд, странный. Его описания в документации нет, экспериментально удалось установить, что нижнее значение у него почему-то вверху, а верхнее, наоборот. Доверия не внушает. Лучше использовать комбинацию MIN и MAX. Кроме того, если хотите вывести коэффициент заполнения или скважность, то лучше выводить коэффициент заполнения - нет деления на ноль.
Теперь к вопросу о выходах с ШИМ. На ПЛК 63, если использовать программный блок с ШИМ, то надо просто преобразовать выходную BOOL в REAL стандартным оператором. На ПЛК 150 при его дискретных входах есть их настройка в конфигурации как ШИМ выходов, но единицы измерения там довольно странные, надо привыкнуть. Смотреть надо в документе PLC_configuration п. 2.2.2, стр 27 (Для 150).
Если вы от LIMIT - то в хелпе ясно: min, x, max (ST)
min,
x,
max (СFC) Тоже самое - очевидно ж :)
А ШИМ смастерить можно из чего угодно.
Если Вы это знаете, то конечно, очевидно. Но человек обычно строит шкалу снизу вверх. Пример - традиционные координатные оси, градусник (термометр). Я навскидку не берусь назвать общепринятые примеры построения положительной оси сверху вниз, а отрицательной снизу вверх.
Ну это Вы с высоты своей квалификации. Кроме того, как я уже писал, не все гладко с преобразованием типов, если на вход REAL_TO_TIME попадает отрицательное значение, то на выходе получается предельно возможное для TIME число. Но, скорее всего, Вы это где-то учитываете, только я не понял, где, как Вы уже, наверное, догадались, я не очень хорошо в этом разбираюсь. Я написал, как сам делал. За это могу ручаться, практически проверил работоспособность в разных ситуациях
Так значит можно сделать на выходе с реле ШИМ сигнал
Можно, конечно. Причем стандартный библиотечный блок "BLINK" почти он и есть. Осталось пережде вычислить необходимую скважность сигнала и длительности импульса и паузы - это из соотношения имеющегося аналогового сигнала и его диапазона. Потом подать значения на входы указанного блока. По пути возникнут трудности с преобразованием типов данных, мы их как раз обсуждали. Суть можно уловить из переписки и необходимость в это вникнуть - тоже.
Как раз затем, чтобы обойти эту неверность. Понимаете, у меня создается впечатление, что нас постоянно вынуждают выкручиваться из всяких ситуаций, которые являются порождением чьей-то недобросовестности, отсутствием контроля. Когда я вижу такие вещи, я об этом пишу. В ответ мне сразу начинают пояснять, почему так получилось. Вроде бы так и должно быть. А я говорю о том, что такого быть не должно, что это ошибка, не счетная, а идеологическая и хорошо бы было, чтобы ее исправили. Но никто ничего не исправляет. Вы, видимо, уже к этому привыкли, а я еще нет. Вот и кричу: "Льву не додают мяса ... и тд" - думаю, Вы помните - у Хазанова такая интермедия была. Вот и в данном случае, боюсь, мы немного не понимаем друг друга: я говорю о факте наличия этих разрывов по краям диапазонов значений, о том, что в документации об этом ни слова, о том, что именно из-за этого приходится немного усложнять и если вы этого не знаете, то влипаете не по своей вине. А Вы говорите, что ввести ограничение диапазона просто. Так я и не говорю, что сложно, я говорю о том, что наличие разрывов при преобразовании типов данных - это неправильно. Вот что было содержанием моего высказывания.
Для этого и я LIMIT внедряю, если знаю что он нужен. Только это не неверность. Это нормальное преобразование отрицательного значения в время. Даже иногда использую конструкции типа int_to_time(-1). Время же - кольцеобразно а не линейно.Цитата:
Как раз затем, чтобы обойти эту неверность
И что должно быть в документации ? Правила целочисленного исчисления ? :confused:
Что же в этом нормального? Смотрите сами - область определения этой функции непрерывна (отвлечемся от дискретности задания, говорим об аналитическом виде). А область значений - разрывна. Ужель Вы считаете это нормальным?
Нормально, на мой взгляд, было бы, если бы разрывов не было. А их сделали. Зачем? Ведь используя ограничение вы как раз и ликвидируете это явление.
А в документации, на мой взгляд, должно было бы быть указание на то, что у этого преобразования есть такое свойство. Уж коль его таким сделали.
Время - в смысле TIME и TIME()
А другое - говорят вообще спираль :)
PS
Самолет через 4 часа. А сейчас 23:30 :confused: А будет ли самолет :eek:
Я бы не стал смешивать филосовские категории с типами данных, их областями определений и форматами. Да и вообще, начинали совсем с другого, но надо же, куда пришли! Кроме того, строго говоря, речь-то шла не о времени, а об интервале времени. У них даже тип шкалы измерений разный.
От оно ! Жалкое ограниченное подобие Времени - это DATE. А TIME это действительно измеритель интервала на прямой Времени.Поэтому и циклично.
А тут я вообще не рискнул бы чего-либо утверждать :) Или, максимум - на данный момент считается что это такЦитата:
..а время течет линейно от прошлого через настоящее в будущее
Откатываясь назад. А что нужно-то от REAL_TO_TIME ?
Проблема то в чём? Вроде всё разжевали.... Даже от темы начали отклонятся....
Можно сделать используя аппаратные возможности ПЛК63 либо программным методом (считаю аппаратный лучше)
Реле только долго не проживёт и всё - ресурс то не резиновый
Если уж сейчас не понятно - то ШИМ на ПЛК63 сделать действительно нельзя
Не вижу логической связи. Сам по себе измеритель - с какой стати? Люди могут закольцевать, это уже вопрос его конструкции, концепции построения.
Логичности работы, а именно отсутствия разрывов на концах диапазона значений. Или информирование о такого рода явлении в документации. Но, понятно, что не от самого преобразования, а от людей, которые его делали. Все-таки это - не явление природы, а рукотоворно.
То, что слово надо заменить - это, думаю, верно. А вот при каких периодах - это уже от человека зависит. Для одного - целсообразно одно, для другого - другое. Кого-то, может и секунда устроит. Может, ему жизненно важно, чтобы неделю проработало, а дальше можно выбросить, жизненная задача решена. Все зависит от того, за какое время человек планирует выработать ресурс и от скоростных особенностей реле. Но если говорить о нормальных ситуациях, то, наверное, надо согласиться.
Не понимаю, почему Вы такие значения взяли. И для того и для другого будет максимальное значение области значений тип TIME.
Разрывы происходят в нуле и в максимальном значении. Предположим, на входе этого преобразования есть последовательность положительных значений, снижающихся к нулю. Например, 100, 50, 10, 3, 2, 1, 0. На выходе, Вы соответственно получаете тоже 100, 50, 10, 3, 2, 1, 0. При дробных значениях будет округление. То есть, функция преобразования - прямая, снижается к нулю. Чего логично ждать, если на вход после нуля попадет, предположим, минус 1? Думаю, что логичным будет ноль, поскольку область значений с этой стороны ограничена нулем. Ну и уперлись в него и все. А что имеем на деле? Имеем дикий скачок в максимальное значение. А зачем? Аналогичная вещь происходит при превышении максимального значения. Попробуйте задать какое-нибудь превышающее значение. Только не берите значения в миллисекундах из документации. Похоже, что там очередная ошибка. И что имеем на деле? Почему-то имеем ноль. Только не надо мне объяснять, КАК он получается. Вы попробуйте с позиций обычного человека объяснить, ПОЧЕМУ сделана такая разрывная функция. А если уж сделана, то почему в документации об этом ни слова. И опять мы вернулись к ней, родимой.
Никто эти разрывы специально не вводил. Кроме того, в алгоритмах управления чаще нужна дельта времени, нежели его абсолютное значение. Без переполнения считать дельту в «разрывах» гораздо сложнее, чем с ним.Цитата:
Нормально, на мой взгляд, было бы, если бы разрывов не было. А их сделали. Зачем? Ведь используя ограничение вы как раз и ликвидируете это явление.
Документация на кодесис вызывается нажатием F1. Про диапазоны временных типов там сказано.Цитата:
А в документации, на мой взгляд, должно было бы быть указание на то, что у этого преобразования есть такое свойство. Уж коль его таким сделали.