Выкинуть все задачи и поставить минимальное время цикла, 1-5 мс, тогда погрешности отсчёта времени будут минимальными.
200 мс отсчитывать таймером, как уже сказали.
Вид для печати
Выкинуть все задачи и поставить минимальное время цикла, 1-5 мс, тогда погрешности отсчёта времени будут минимальными.
200 мс отсчитывать таймером, как уже сказали.
слишком заумно кто-то сделал
никакого смысла гонять две задачи лично я не вижу, эта задумка со связанными программами чревата проблемами изначально и дальнейшая "тонкая" настройка всё равно может не привести к результату
что мешает сделать в одном цикле?
Программу обмена по модбас вызываете в задаче с типом "Свободная" и с установленным приоритетом 15.Цитата:
Сообщение от Александр
Основную программу вызываете в задаче с типом "Циклическая", с установленным приоритетом менее 15 и минимальным значением "Интервал", которое будет соблюдаться (начните например с "t#50ms").
Отслеживать цикл можете там-же - но уже при подключенном ПЛК
Цитата:
Сообщение от Cs-Cs
Цитата:
Сообщение от kondor3000
Так как я начинающий пользователь Codesys, а программа сделана сильно более опытными чем я людьми, допустил что есть какой-то высший смысл в этом делении на задачи с интервалом в 200 мсек. При этом там в задаче №2 присоединено 10 штук PRG (управление однотипными 10-ью участками), каждая из которых огромная портянка с вложениями. Идея разместить в одну задачу в списке возможных решений есть, но увлекся вариантом с сохранением двух задач ))) Ну и пока не понимаю всех следствий объединения в одну задачу. На первый взгляд ничего не мешает, буду пробовать.Цитата:
Сообщение от In_Da_Cher_A
200 мсек это не требования к программе, а побочный эффект интервала заданного в типе задач. Требуемое поведение: программа рассчитывает необходимое время хода ИМ, потом это контролируется по времени активности шага SFC, отвечающего за присвоение нужных значений переменным для дискретных выходов.
В частности, не понимаю как происходит обмен по Modbus в программе. Процесс выполнения будет дожидаться ответа данных от подчиненных устройств, до перехода к следующим инструкциям, или это как-то асинхронно выполняетсяЦитата:
Сообщение от Александр
Да, по смыслу это логично, но задача, как я её вижу, уйти вообще от интервалов, создающих погрешность при имеющемся алгоритме управления.Цитата:
Сообщение от 1exan
Александр Обмен по Modbus происходит на уровне ядра, если всё конфигурируется через дерево Конфигурации ПЛК.
Автономно, сам по себе. Без разницы, как работает в этот момент программа.
Можете создать одну задачу со свободным вызовом и добавить в неё все вызовы всех своих программ - это будет аналогично тому, если б вы вызывали их друг за другом из PLC_PRG без использования диспетчера задачЦитата:
Сообщение от Александр
Как понимаю, если сконфигурировано через Конфигурацию ПЛК, то то что на чтение идет в начале цикла, то что на запись в конце цикла. В данном же случае, запуск обмена по Modbus вызывается в PRG задачи №1, через ФБ библиотеки EthernetModbusMaster(Wago), в процессе выполнения задачи №1. Представляется что идет ожидание результата Ethernet-запроса. И никакой асинхронности там нет. Но так ли это - непонятно.Цитата:
Сообщение от Cs-Cs
Цикл ПЛК - 1 мс, запрос ответ по Модбас не менее 25-30 мс. За время одного запроса, ПЛК выполнит 25-30 раз программу целиком.Цитата:
Сообщение от Александр
Если это так, и цикл ПЛК не "растягивается" на время необходимое для обмена по Modbus, то возможно этот интервал для задач в 200 мсек как раз установлен для согласования обмена данных и их обработки в программе, и для того чтобы не заваливать ведомые устройства запросами каждые 20-30 мсек (такое суммарное время цикла задачи №1 и №2). Понимаю что не понимаю как оно должно работать. Есть ФБ выполняющий запрос по Ethernet. Если ответ на запрос еще не вернулся, но уже в следующем цикле идет новый вызов этого ФБ, то ответ первого запроса игнорируется? Интересно, эти вещи где-нибудь описаны вообщеЦитата:
Сообщение от kondor3000
ФБ выполняющий запросы работает в цикле: запросил - подождал - ответили - запросил - подождал - ответили и т.д. Когда ответили - обновил значения полученных данных. До момента ответа - висят данные прошлого ответа.Цитата:
Сообщение от Александр
Основная программа в начале своего цикла считала входные данные (в том числе и текущие значения с ФБ обмена) - их обработала
Иногда PLC_PRG становится настолько большой, что время её выполнения не вмещается в цикл и происходит срабатывание WDT.
Эту проблему каждый решает по-своему:
- Кто-то разделяет на несколько PRG и создает глобальную переменную, которая определяет какой именно PRG будет работать в текущем цикле.
- Кто-то выделяет часть кода, которая по мнению создателя может выполняться еще реже и выделяет её в отдельную задачу (Task).
В любом случае OS ПЛК выполняет опрос исключительно по своим правилам и независимо от PRG.
Однако есть механизмы передачи сигналов управления в/из. Они описаны в документации.
Когда PRG обращается к переменным, то их содержимое может как еще не обновиться OS, так и обновиться несколько раз.
Так и при опросе регистра ведомого устройства, его значение может успеть измениться несколько раз, т.е. значение поступит самое последнее.
Поэтому приходится придумывать различные семафоры, четко фиксирующие ожидаемое событие. За счет чего удается синхронизироваться.
Проблемы начинаются у тех, кто бездумно втыкает задачи по 200 мс в программу, думая, что разгружает ПЛК. А по факту делает только хуже.Цитата:
Сообщение от Александр
Надо не задачи втыкать, а оптимизировать обмен по интерфейсам и программу. Тогда и проблем не будет.
Думаю в вашем случае, задержки по 200 мс в 2 задачах, просто не дают работать программе нормально.
Вместо цикла 1-5 мс, у вас 400 мс и скорее всего обмен работает быстрее чем программа, цикл ещё не закончился, а ответами уже завалили по горло.
Любой таймер насчитает вместо нужных 100 мс, 300-500 мс, что у вас и происходит.
Так понимаю это должно быть реализовано в ФБ библиотеки, определение того что нужно делать: выполнить новый запрос, или ждать ответа на предыдущий? В ФБ (отвечающем за обмен по сети) использующемся в программе этого нет, а как посмотреть код библиотеки не знаю.Цитата:
Сообщение от 1exan
Какие механизмы имеются в виду в данном случае?Цитата:
Сообщение от EFrol
Буду признателен если скажете в какой именно документации.
Так и есть, при управлении ИМ через контроль времени активности шага SFC это и происходит.Цитата:
Сообщение от kondor3000
Знать бы как оптимизировать этот обмен ) Из каких составляющих состоит эта оптимизация?Цитата:
Сообщение от kondor3000
Какая используется библиотека?Цитата:
Сообщение от Александр
Здравствуйте коллеги, подскажите пожалуйста, почему выскакивает сообщение?Вложение 82589
Когда вы уже разделы путать перестанете?Цитата:
Сообщение от sssssaaaaabbbbb
На это уже ответил в посте #11361 https://owen.ru/forum/showthread.php...l=1#post459603Цитата:
Сообщение от Александр
1) Удалить все задачи, доп. программы вызывать из основной программы. Дать работать проекту циклом 1-5 мс.
2) Если будет тормозить обмен, сделать групповой опрос.
Ну а накой сразу смотреть её код?Цитата:
Сообщение от Александр
Ищите и выкладывайте её описание.Цитата:
Сообщение от Александр
Или выкладывайте и проект и эту либу.
Расчетную часть можете выкинуть, никого она не интересует если что. Только архитектура и код обмена.
Код обмена должен вызыватся с макс.скоростью (сказали уже)
Не удалось найти описания библиотек, на оф.сайте нет (там все под CDS3.5 заточено), гугл вообще не находит упоминаний о них.Цитата:
Сообщение от Валенок
Сильно обрезанный проект и либы в приложении.
В главной программе убрал вызовы программ бывших частью задачи №2 (и исключил их из компиляции).
Вызов ФБ работающих с Modbus происходит в главной PRG. Эти ФБ генерируются встроенным инструментом Modbus Configurator (Codesys адаптированная под ПЛК) исходя из сформированного списка подчиненных устройств.
Так и сделал, вызовы подпрограмм Otd01...10(PRG) поместил в PLC_PRG, сейчас в проекте одна задача, тип "свободная". Проверять могу только на резервном ПЛК, который не имеет связи с ведомыми устройствами. Время цикла среднее 16 ms (при переводе в режим "Старт" максимальное 5000 ms, после сброса мониторинга времени цикла в процессе работы, максимальное до 30 ms).Цитата:
Сообщение от kondor3000
Исходя из кода ФБ ModbusSLave, судя по всему там то что можно назвать групповым запросом, данные упаковываются в массив перед передачей.
Есть вероятность что проект не откроется в стандартной Codesys, вот скрины "архитектуры":
1рис - PLC_PRG с вызовом ФБ ModbusSlave.
2рис - код ФБ ModbusSlave.
3рис - Otd01...10 (PRG) вызываемых следом за ФБ ModbusSlave.
Так у вас ПЛК не Овен получается?
Биб-к тоже не хватает.
Нет, Wago. Предполагаю что поведение задач и ФБ такого плана идентичное для любых ПЛК. И, думаю, понимание этих вопросов будет полезно пользователям любых ПЛК. Да, там выше скрины прикрепил на этот случай.Цитата:
Сообщение от kondor3000
Вообще, эта ситуация с недоступностью доков, софта сильно напрягает. И уже неоднократно возникала мысль - а что можно использовать вместо Wago 750-880. И конечно самый понятный вариант в плане доступности (в плане приобретения) и поддержки это Owen. Но вспоминаешь как вел себя ПЛК160.1, обрывы связи, невозможность подключиться, и уже непонятно, не создам ли себе еще больше проблем. В общем пока психологическая травма полученная от опыта работы с ПЛК160 не прошла )) Возможно ПЛК2ХХ уже являются оборудованием другого качества и надежности? Очень, очень хотелось бы, чтобы это было так. Интересно было бы узнать мнение тех кто проверил это.
у вас какие-то детские страхиЦитата:
Но вспоминаешь как вел себя ПЛК160.1, обрывы связи, невозможность подключиться,
не думаю что ВАГО
а зачем и для чего? ваши проблемы - в том, что проект делал какой-то "тру программер" тупо запихнувший зачем-то всё в одну железку по принципу "впихнуть невпихуемое", зато программа судя по скринам - просто образчик ФБстроения, но теперь без него ничего не будет работать нормальноЦитата:
а что можно использовать вместо Wago 750-880.
не думаю, что можно что-то безболезненно тут исправить, максимум - как-то поставить костыли, чтобы решить трабл с временем хода клапана и минимизировать его влияние.
расковыривать это месиво в рабочем порядке чтобы самостоятельно мигрировать на что-то другое - сомнительное удовольствие
я бы смотрел в сторону костылей и не впрягаться в эту неблагодарную работу без команды и финансирования сверху
Решил разобраться с диспетчером задач для повышения быстродействия работы моего проекта.
Дело в том, что в моей задаче автооператоры (АО) на высокой скорости проезжает бесконтактные датчики (20-30 шт.). Датчик идентифицируют номер технологической позиции. Т.к. реальной линии пока нет в моем распоряжении, то не могу оценить сколько раз ПЛК110-60 исполняет программных циклов пока АО проезжает очередной датчик. Обычно я опрос датчиков делал так:
COD_G_POZ_1 := 0;
IF D1 THEN
COD_G_POZ_1 := 1;
ELSIF D2 THEN
COD_G_POZ_1 := 2;
ELSIF D3 THEN
COD_G_POZ_1 := 3;
. . .
ELSIF D18 THEN
COD_G_POZ_1 := 18;
ELSIF D19 THEN
COD_G_POZ_1 := 19;
END_IF
В новом проекте чтобы не потерять сигнал от датчика я решил повесить на каждый дискретный вход отдельную программу, которая будет формировать номер активного датчика. В эмуляторе все работает красиво. Как вы думаете, это правильный подход для гарантированного опроса датчиков? До этого с аппаратными прерываниями на ПЛК ОВЕН не работал.
ПЛК110. Сама постанова - ошибочная. Дальше смотреть смысла нет.Цитата:
Сообщение от vsa
В чем ошибочность? Меня интересует опыт бывалых.Цитата:
Сообщение от Валенок
Как вариант от меня - это то, что быстрее всего будет сделать одну циклическую задачу с самым минимальным временем выполнения.Цитата:
Сообщение от vsa
Мин время - 1мс. Мин минц 1мс
О чем речь? 1 < 1 внезапно?
Лучше бы прикинули реальное время датчиков и сопоставили с характеристиками Di.
Их вроде же не 4 штуки где ещё можно было бы быстрый таймер как-то прикрутить
Мож вообще не Овен.
Убедительно. Закрываю эту тему.
Опять хочу вернуться к диспетчеру задач, но уже для другой ситуации. Просто, хочу разобраться с этим механизмом в ПЛК. Подскажите, если в программе (POU), закрепленной за событием на каком-то дискретном входе, изменится значение переменной, то это изменение появится в основной программе тут же или в начале нового цикла контроллера? Ответ на этот вопрос мне необходим для более глубокого понимания этого программного инструмента. Приведите пример, где обычно используется данная методика программирования. Дело в том, что в моих задачах имеются аварийные кнопки и нажимаются они очень редко. Только при аварийных ситуациях. Бывает, что эти кнопки не нажимаются больше месяца, а может и больше. Но эффект от нажатия должен быть экстренным - отключение движения автооператоров и фиксация их тормозами. Сейчас я в каждом цикле ПЛК анализирую эти входы. Интуитивно понимаю, что делаю не рационально. Таких кнопок бывает 2 - 6 штук. Думаю, вот эту подзадачу можно поручить диспетчеру задач. Или я опять ошибаюсь?
Выбросить все задачи и сделать мин цикл 1 мс, все остальные варианты приведут к замедлению срабатывания кнопок и вообще всего.Цитата:
Сообщение от vsa
Какие приоритеты не ставьте, если задача 10 мс, кнопки сработают медленнее.
Для аварийного отключения контроллер конечно можно использовать, но в нормальных схемах применяются реле аварийного отключения, сертифицированные по SIL3 и т.п.Цитата:
Сообщение от vsa
А ПЛК обычно работают так:
1 действие - запись выходов
2 действие - обработка программы
3 действие - чтение входов
Ранее первым было чтение входов, а последним - запись выходов, но потом вроде стали применять такую последовательность, по крайней мере в Siemens'е...
PS 2 и 3 местами поменять надо, косяк...
1 действие - запись выходов
2 действие - чтение входов
3 действие - обработка программы
В начале цикла, практически у всех.
Вариант другой ПЛК, где в отдельной задаче можно проверять обычные входы внутри цикла.
Вариант использования быстрых входов и в задаче проверять счётчик.
Вариант, описанный выше
элементы, обеспечивающие безопасность, тем более - связанные с людьми, должны быть отделены от "основного" процесса и приводить к остановке движения НЕЗАВИСИМО от состояния "технологического" ПЛКЦитата:
Дело в том, что в моих задачах имеются аварийные кнопки и нажимаются они очень редко. Только при аварийных ситуациях. Бывает, что эти кнопки не нажимаются больше месяца, а может и больше. Но эффект от нажатия должен быть экстренным - отключение движения автооператоров и фиксация их тормозами.
для этого применяют либо ПЛК и модули, сертифицированные для безопасности, либо электрическую схему проектирую так, что действие элементов безопасности идёт в "обход" основного ПЛК напрямую на "привода" активных элементов и приводит к безопасному "останову" процесса.
Советую вам серьёзно отнестись к проектированию именно СИСТЕМЫ ЗАЩИТЫ, а не пихать всё это в несчастный ОВЕН, который вообще для этого не предназначен. Если при аварии могут пострадать и люди, прямо или косвенно, то за вашу самодеятельность вам будет уголовное преследование.Цитата:
Или я опять ошибаюсь?