При этом справа загорается только галочка Watchdog, что по идее означает, что неправильно распределено процессорное время между разными тасками.
Проверка параметров тасков (Monitor в свойствах таска) показала, что каких либо проблем с выполнением задач нет (нет повторных вызовов незавершённых тасков и т.п.). Поэтому не совсем понятно в чём дело.
Удалось выяснить, что ошибка может возникнуть только при попадании логики в определённую ветвь одного из тасков. Эта задача является периодической с периодом 30миллисекунд. При непопадании в длинную ветвь этой задачи время выполнения составляет около 1миллисекунды, при попадании в проблемную ветвь – около 15 миллисекунд (что составляет половину периода, поэтому особого криминала в этом я не вижу).
Ещё видимо стоит отметить, что ошибка возникает при попадании логики в определённую ветвь таска не всегда, то есть пока ясно только что при непопадании логики в эту ветвь ошибка точно не возникает.
Так что ситуация на данный момент следующая – однозначно определить уловия возникновения ошибки не удалось. Были подозрения что выполнение таска за 15 миллисекунд иногда мешает выполнению системных тасков, но после понижения приоритета программного таска ошибка всё равно иногда возникает. Так что пока не понятно действительно ли ошибка связана с неправильным распределением времени между тасками.
Ещё стоит отметить, что каких-либо ошибок в логике не выявлено, то есть все таски работают правильно и выполняют в точности то, что нужно. В принципе, возникновение подобных minor faults ничему не мешает, но хотелось бы разобраться, да и не совсем хорошо копить со временем лог minor faults контроллера.
Обращение к документации ничем не помогло, так как в списке кодов ошибок нет такой ошибки контроллера.
Может кто-нибудь подскажает, что делать с подобной проблемой?
Вообще, Type 06 говорит о том, что какой-то из задач не был предоставлен запрошенный ресурс за отведенное время.
В CompactLogix обновлением ввода-вывода занимается специальная задача с приоритетом 6. Это периодически выполянемая задача, период её выполнения соответствует RPI, который назначен для CompactBus.
То, что Вы наблюдаете, означает, что RPI очень маленький, задача обновления ввода-вывода выполняется слишком часто, отбирая значительные ресурсы у других системных задач и/или в контроллере есть другие более высокоприоритетные задачи, из-за которых данной задаче не хватает процессорного ресурса. Судя по тому, что чем больше время испольнения задачи, тем больше вероятность получения ошибки, эта задача отбирает ресурс у других, что, видимо, и есть причина.
Что можно сделать:
- Увеличить RPI насколько возможно
- Установить приоритеты других задач так, чтобы они были меньше, чем 7, чем меньше, тем лучше (т.е., численно больше 7 и до 15).
Вообще, при программировании мультизадачных систем реального времени есть простой принцип, которое называется так: "Don't fog the CPU!".
Приветствуется т.н. "оборонительный" стиль планирования вычислительных ресурсов, который означает, что каждая задача должна иметь наименьший возможный приоритет и запрашивать как можно меньше ресурсов CPU, при которых обеспечивается необходимая функциональность.
Спасибо за совет - попробую изменить RPI. Насчёт приоритетов других задач - сейчас он численно от 10 и меньше у всех задач, так что это по идее не могло стать проблемой. Возможно проблема в том, что есть считывание большого объёма через RS-232(а именно это и происходит в проблемной ветке программы - там считывание из буфера накопленного ответа от прибора размером около 800 символов). Может RPI и обмен по RS-232 не всегда могут поделить процессорное время. Просто немного смутило наличие unknown fault, т.к. ранее при некорректно выставленых приоритетах некоторых задач в логах писалась какая именно задача повторно запустилась.
Ну и параллельно возник вопрос об устройстве логов ошибок - как он устроен и к чему может привести постоянный рост кол-ва minor faults? А то что-то кроме кодов ошибок и того, что лог при каждом запуске ведётся с нуля, больше никакой информации не нашёл... может плохо искал...
Скорее всего, более подробной информации и нет. minor и есть minor
В принципе, в КВ можно найти почти всё, а то, чего там найти нельзя, можно попробовать узнать, напримекр, у нас
Владение портом RS-232 - вообще, штука монополизируемая, и возможно, чтобы не потерять данные, задача захватывает его и держит, пока не будет прочитана вся цепочка данных.
Обычно рекомендуют строить такие "длинные" и претендующие на ресурс задачи из двух частей:
1) Короткая высокоприоритетная "ловушка" символов из порта, которая кладёт символы в буфер и сразу отдаёт процессор
и
2) медленная спокойная неприоритетная задача, которая не торопясь берёт символы мз буфера и обрабатывает их.
Вы не можете начинать темы Вы не можете отвечать на сообщения Вы не можете редактировать свои сообщения Вы не можете удалять свои сообщения Вы не можете голосовать в опросах
Smart Solutions VDT GmbH | Friedrich-List-Allee 38, D-41844 Wegberg-Wildenrath, Germany Tel.: +49 2432 933 57 83 | e-Mail: office@vdt-solutions.de Все товарные знаки и торговые марки являются собственностью их владельцев.
При использовании материалов сайта ссылка на данный сайт обязательна. Открытие страницы: 1.534 секунды
FAQ
Поиск
Группы
Профиль
Войти и проверить личные сообщения
Вход
