Вы предлагаете, проверять в критических моментах. Но имеет ли смысл, если пока мы не перешли к следующему циклы, значения портов не изменятся.Сообщение от Yegor
Вы предлагаете, проверять в критических моментах. Но имеет ли смысл, если пока мы не перешли к следующему циклы, значения портов не изменятся.
Если в контроллере выходы меняются после цикла проги, кто мешает в самом конце проги, при отсутствии сигнала на входе контроллера выполнить по триггеру действия при обнаружении перехода 1-0, а далее тупо обнулять выходы пока ноль на входе?
Вроде элементарно, вроде такой подход защищает от ошибок в будущем, при изменении проги, когда уже почти забыл где что.
Нужна максимальная скорость? поставьте в начале проги переход в конец по условию входа. (кстати заморозите все переменные, может пригодится при возврате к автомату.)
Нафига городить строки
выход_на_моторчик := NOT стоп AND (крутить_моторчик OR другие_условия_кручения_моторчика)Вопрос у ТС был довольно интересный, про архитектуру,Причём желательно, чтобы это было единственное место записи в выход_на_моторчик;
В подходе из цитат, архитектурой даже не пахнет.
-------------------
Архитектура, это когда прога разбита на кучу подпрограм и функций, а в нужный момент работают только те куски, которые нужны именно в этот момент. Так вообще то писать намного проще.
Последний раз редактировалось BETEP; 29.09.2016 в 19:52.
К сожалению. Такая тема мимо ушла...
но он то совсем про другое, ему казалось что бесконечный цикл решит все проблемы и неподозревал что плк это делает и так. Под прерываниями он тоже имел ввиду не то что считается в контроллерах
Bad programmers worry about the code. Good programmers worry about data structures and their relationships
среди успешных людей я не встречала нытиков
Барбара Коркоран
Да ушел от темы, как и задал вопрос слишком преждевременно, погорячился. Надо было больше почитать и проверить свои идеи.
В обычном микроконтроллере, это выглядело бы как обычный конечный автомат.
Было бы объявлено какой-то enum, ну к примеру:
Переменная, как stateTPA которая хранит переменную.enum TPAAutomaticStepCycleEnum
{
/// <summary>
/// Не выбран
/// </summary>
TPAASC_None = 0,
/// <summary>
/// Смыкание формы
/// </summary>
TPAASC_CloseForm = 1,
/// <summary>
/// Выс. давл. дожатия
/// </summary>
TPAASC_CloseFormHighPressureSqueezing = 2
};
Дальше проверка if, которая проверяет вход, и если на нем 0, идем в функцию которая отключает оборудование в зависимости от последнего пункта, каким образом мы не идем дальше, если 1 идем дальше.
После это проверка выбранного режима, как правило они жестко забиты, поэтому это был бы if, а в нем функции TPAWAutomatic(), TPAWSemiAutomatic(), TPAWManual() и т.д.. Каждая функция TPAWAutomatic и TPAWSemiAutomatic представляет собой отдельный конечный автомат на case, к примеру так.
switch (stateTPA)
{
case TPAASC_CloseForm:
func1(&stateTPA);
break;
case TPAASC_CloseFormHighPressureSqueezing:
func2(&stateTPA);
break;
}
При появлении нового шага, нам нужно добавить дополнительную строку в enum, поменять нумерацию и добавить дополнительную обработку в case. Сами обработчики это функции и т.д.
Это, что касается расширения программы.
Что касается обработчика защиты, то мы просто читаем в критическим моментах порт. Или создаем прерывание и пробуем перейти в 0 адрес программы.
Не являюсь профессионалом, поэтому возможно вариант не идеальный. И да
Последний раз редактировалось Alex19; 29.09.2016 в 21:47. Причина: Исправление
Возможно я не правильно выразился.
Меня интересовала возможность расширения и уход от повторяемости кода.
Очень интересно, есть какой-то триггер, который может обнаружить переход состояния входа 1-0. Идея действительно правильная, но мне мешало ее увидеть привычка, что изменение выхода происходит мгновенно. По сути триггер с проверкой в конце цикла, это то, что мне нужно, надо разобраться, что за зверь и как это работает. Спасибо за идею.
Вы говорите о метках или goto, разумно.
Такое написание кода, желательно всегда.
Alex19
на пластавтомате нет быстрых процессов.
там ни переходы, ни менеджер задач не нужны.
А программа пишется примерно так:
Честно говоря у меня еще нет полного представления о работе ТПА.
Сейчас собираю документацию на машину.
Как понял у Вас используется последовательный вызов функций/методов.
А если режимов работы несколько?
В одном случае, автомат, переход из функции в функцию, в другом случае вызов по нажатию. В этом случае Вам нужно будет делать проверку на входе каждой, можно так же поставить их по режимам работы. К примеру if и потом череду функций с доп. проверками, но тогда у нас получаются лишние вызовы, case позволяет избежать их.
Нужно отдыхать, завтра в командировку.
На следующей неделе попробую проверить все идеи.
Большое спасибо, всем кто уделил мне время.
Ваши права
Ответить с цитированием