а так:Сообщение от Сема
Как изменить тип входа и выхода в макросе.jpg
а так:
Как изменить тип входа и выхода в макросе.jpg
пора выбрасывать прах, от обиды на мир, пока тела наши не стали невидимыми...
Глупости. Входы-выходы макроса прекрасно настраиваются под любой имеющийся тип.
Не при создании макроса, а в свойствах входа/выхода.
Научитесь пользоваться макросами, и не придётся рисовать "метр на метр" схемы, в которых чёрт ногу сломит,и оттестировать которые голова квадратной станет.
Ещё умейте пользоваться переменными, как "именованными цепями". И схемы станут простыми и легко читаемыми и отлаживаемыми.
Это называется "структурное программирование". В рисовании схем для ПР это тоже актуально.
А вы не пробовали в свойствах входов и выходов макроса изменить их, сделать целочисленными или флоат?
Там ещё и процессор слабее чем в ПР200
Поскольку вопрос с написанием макросов на языке высокого уровня подвис, а так же с заявлениями разработчиков ОЛ - "присылайте нам заявки, мы сделаем блок в библиотеку", я предлагаю разработчикам разработать и включить в библиотеку ФБ, по выполняемым функциям соответствующие логическим микросхемам стандартной серии 74 (у нас 155), например. В отличие от языков высокого уровня, я не предвижу возражений от любителей рисовать "квадратики", ибо это и будут квадратики. Кроме этого значительная часть имеющихся схем будет достаточно просто переводиться на новую элементную базу в виде ПР. Возможное неудобство будет никак не больше, чем например отсутствие отрицательных целых чисел в ОЛ (что является несомненным достижением, т.к. в микроконтроллере ядра ПР200 они есть). Вообще системы управления возможно проектировать исходя из аппаратного подхода или программного. При этом сторонники ПР придерживаются первого, а ПЛК - второго. Однако в настоящее время ОЛ не реализует толком ни один - для первого слишком малая библиотека, а для второго - слишком узкие возможности программирования. Своим предложением я предлагаю устранить первое ограничение, если уж второе признано идеологически неверным.
Справочник "Популярные цифровые микросхемы" автор В. Шило - читаем, если забыли и рисуем что душе угодно
Так мы и так уже читаем и рисуем. Есть только ощущение, что это какой-то бред - сперва квадратики, потом это странслируется в промежуточный язык, а потом интерпретатор будет выполнять эти команды на контроллере... Я предположил что если создатели ОЛ оформят это в виде библиотеки - оно покомпактнее выйдет и побыстрее, возможно.
Не выйдет побыстрее. Всёравно через "промежуточный код" и "интерпретатор".
Другой вопрос - а нафига оно полный набор нужен, если любой элемент за несколько минут собирается из того, что уже есть. А какие именно понадобятся, а какие никогда - заранее неизвестно.
Вставлю свои 5 копеек.
На самом деле проблема не столько в том, что нет нужных наборов макросов, сколько в том что собственные макросы попадают в финальный код именно как макросы, а не как вызовы процедур.
Поэтому при реализации достаточно сложных, однотипных механизмов на разных вводах/выходах сам лично столкнулся с банальной нехваткой памяти под микропрограмму уже на 3-м порту из 8-ми. Пришлось всё заново переписывать придумывать очередь для обработки запросов и обрабатывать каждый вход на одном макросе в режиме карусели.
В общем код получился пипец какой сложный, без бутылки спустя месяц не разобраться. как итог иногда происходят теперь какие-то "странные глюки" (по большому счету не критичные в техпроцессе), которые не понятно к чему отнести, то-ли к звону контактов, то-ли к ошибкам в вечно бета ОЛ, то-ли моей ошибке в схеме из-за многопоточности где-то в этой гигантской каруселе линий и квадратиков.
Но разбираться желания особого нет, работает 99,9% времени и хорошо, нажать лишний раз кнопку оператору - не проблема.
Последний раз редактировалось sdy; 16.09.2017 в 20:46.
Господин президент, что Вам снится ночами...? (с) ДДТ
Будь человеком, а то съедят!
Какой памяти не хватало?
ОЗУ? Переменные? Стек?
Ваши права
