Отправлено: 18.12.16 13:20. Заголовок: Перестают работать модули Simpl+

Сложилась непонятная ситуация: на объекте после заливки контроллера PRO3 всё работает. Через какое-то время все Simpl+ модули вдруг перестают работать. В логах ничего. Намекните, где копать, пожалуйста!

 Отправлено: 18.12.16 13:46. Заголовок: У меня было подобное..

У меня было подобное, из-за какой-то ошибки один из S+ модулей при запуске останавливал AV3 процессор напрочь.
Хорошо, что при пусконаладке...
Ловил исключая модули по одному. Причину так и не нашел, какая то моя ошибка, совместной работы с SIMPL или использования памяти.
Нашел S+ из-за которого все зависало и переписал заново.

 Отправлено: 18.12.16 18:16. Заголовок: На моей практике в 9..

На моей практике в 99% случаев ошибка была в ошибочной организации бесконечного цикла не притормаживаемого delay и т.п.
Смотрите while циклы.
Код программы
while(k=0)
{
}
готов положить любой процессор на лопатки. Утрирую конечно тупость кода, но суть ясна. Доходило, что спасать ситуацию приходилось только остановкой программы, подключившись по USB/COM.
Было пару случаев при объявлении достаточно большого массива nonvolatile переменных. При этом компилятор не ругается, т.е. физической памяти хватает, но программа встает раком и на изменение переменных в дебагере не реагировала. Но это проявляется сразу, так что смотрите 1 вариант про бесконечные циклы.

 Отправлено: 18.12.16 18:21. Заголовок: Да, бывало и у меня ..

Да, бывало и у меня раньше на 2-й серии несколько лет назад при тренировках с циклами в S+.
Процессор вставал так, что только насильственный физический останов, восстановление через Monitor позволяли вернуться на исходные позиции.

 Отправлено: 18.12.16 20:20. Заголовок: речь идет о том что ..

Вячеслав, Игорь, речь идет о том что процессор нормально работает, не работают только + модули, а вы описываете тупление всего контроллера. У меня ситуация идентичная описываемой была на 2 серии - закончилось заменой контроллера в сервисе после диагноза - ошибки памяти. Но у 3-ей серии совсем другая архитектура, причины могут быть другие.

 Отправлено: 18.12.16 20:25. Заголовок: Alexandr, я не выдаю..

Alexandr, я не выдаю рецепт решения, возможно автору вопроса все эти наши страшные рассказки помогут найти решение проблемы.
И откуда вам точно знать что там в точности происходит?

 Отправлено: 18.12.16 20:40. Заголовок: Да понятно что вы не..

Да понятно что вы не выдаете рецептов :), мы уже к вам привыкли. Контроллер положить есть множество способов, а отрубить обработку Simpl+ через некоторое время работы - это уже экзотика, тут или аппаратная проблема (как у меня на 2 серии была) или нужно копать глубже, разбираясь как организована на 3-ей серии обработка таких модулей, и там уже можно будет смотреть что и как падает. На 2 серии Simpl+модули имели достаточно низкий приоритет, и если контроллер был сильно занят чем в обычной программе, они могли и тупить, но не совсем отваливаться. Хотя может и банальная корявость в одном из модулей тупо вешает их обработчик(что вроде не должно происходить, но кто знает).

 Отправлено: 18.12.16 21:19. Заголовок: Если у автора не раб..

Если у автора не работают исключительно + модули при работоспособности остального кода, вероятно ошибка программирования.
1. И самая из них распространенная опять таки войти в цикл из которого уже не выйти. В данном случае не обязательно с подвешиванием процессора.
С другой стороны не во всех же сразу ошибки. Тогда может и с прошивкой быть баг и аппаратный.
2.Редко достижимая но все же выявленная мной ошибка уязвимость 3 серии = это ограничение на количество одновременных циклов (угадайте каких) - ага, циклов while
Так вот у 3 серии процессоров нельзя организовать одновременное выполнение более 8 циклов while (по крайней мере внутри одного + модуля). т.е. тело 9 по счету цикла выполнятся не будет.
Дальше я копать эту проблему не стал, скажу только что 2 серия вполне справлялась с 10 циклами и может быть справилась бы и с большими, но для выполнения поставленной задачи более 10 мне запускать не нужно было и ограничение 2 серии в этом вопросе остается до конца не исследованным.

 Отправлено: 19.12.16 02:55. Заголовок: У S+ в 3-й серии нет..

У S+ в 3-й серии нет определённого "процесса", который общий на все модули. Наоборот - для каждоого S+ модуля есть своя DLL.

Обработчик события S+ может словить необработанное исключение и упасть сам - т.е. недовыполнинться. И если вы сипользовали какие-нибудь семафоры, то busy не прекратится, и конструкция с threadsafe тоже больше не будет выполняться. Обычно это даёт крэш в логе.

Обработчик события S+ c вызовом S# может бОльшее: он может вызвать "системную" функцию .Net, которая словит необработанное исключение. Тогда в перезагрузку уходит контроллер, а если ловятся три такие перезагрузки за 5 минут то вочдог разрегистрирует эту программу - я напоролся на это с недозалитым шлюзом CI-KNX. Это тоже было в логе.

Обработчик S+ может исчерпать разделяемые ресурсы контроллера - забить всеь пул таймеров, открыть файл на запись и упасть, заказать кучу памяти под динамическую структуру, забить стэк вызывая из процедуры её саму, забить стек событий с помощью неимоверно тормозящего обработчика и кучи событий для него. В этом случае ни ему ни другим S+ обработчикам ничего хорошего больше не дадут и в отладчике вы тоже будете выидеть как бы нереагирующие на измения входов S+ модули. Тут возможны варианты, может и нечем станет в лог писать)

Бесконечные циклы в main() во 2-й серии были наименьшим злом - этот код исполняется 1 квант времени ОС, останавливается и ждёт в стеке недовыполненных обработчиков, это делается механизмом многозадачности той OS. Если делать delay() то поверх этого механизма ещё добавляется таймер. А если какой-нибудь processLogic() - то вовсе шухер на переключение в интерпретатор SIMPL.
Сейчас появились wait() и всю ту логику, которую делали в этих циклах стало изящней делать с помощью этих таймеров, а в 3-й серии тупые бесконечные циклы грузят контроллер, Windows Mobile не так спокойно к ним относится, приоритет выше и вообще неясно чем процессор занялся. Вроде бы у вас не тот случай.

Я не думаю, что это может быть из-за ошибок в трансляторе в духе 10-го вложенного while() - вы бы увидели невыполнение сразу.

 Отправлено: 19.12.16 04:44. Заголовок: позапускайте из конс..

позапускайте из консоли с разной переодичностью

SPLUSTASKS:n
THREADPOOLINFO:n

n - номер програмы.

посмотрите какие ThreadId для каких модулей S+ запущены.

SPLUSTASKS:2
Module Name | ThreadId | Priority | RunTime(ms) | CodeLine Information
S-5.3 0x084882F2 255 19 238 (Main)
S-5.3 0x080084F2 255 6 195 e_SIGNAL_TYPE_ANALOG -- Input: 2

может найдёте подозрительные которые не должны в отличии от while(1) висеть постоянно;)

 Отправлено: 19.12.16 05:41. Заголовок: Вячеслав пишет: Так..

Вячеслав пишет:

цитата:

Так вот у 3 серии процессоров нельзя организовать одновременное выполнение более 8 циклов while (по крайней мере внутри одного + модуля). т.е. тело 9 по счету цикла выполнятся не будет.

попробовал... одновременно выполняются и 21. скорее тут вопрос не в количестве тел ...

 Отправлено: 19.12.16 12:28. Заголовок: Я не стопорил програ..

Я не стопорил программу delay-ями.
Я в каждом цикле инкрементировал счетчик глобальной переменной. (Идея была в косвенной оценке производительности процессора.)

 Отправлено: 19.12.16 19:41. Заголовок: Производительность в..

Производительность высокая даже на MC3, если не использовать Simpl+ модули. Все больше упирается в интерфейсы нежели в процессор. Например если к PRO3 подключить 240 TCP/IP устройств в 1 программе, то он работает, но как только подключаешься через дебаггер или монитор он падает как мертвый... и это он еще не управлял этими устройствами.

 Отправлено: 20.12.16 00:26. Заголовок: Да, в SIMPL есть 253..

Да, в SIMPL есть 253 IP слота, можно сколько хочешь наделать соектов в S+ и если очень прёт - то ещё наоткрывать соединений из S# можно. Но как сетевой стек в базовой OS Windows Mobile 6.5 все эти соединения будет держать?)

Откуда эта склонность к PRO3? Если нужно управлять по IP, возьмите уже на эти деньги 5 штук RMC3 и открывайте 240 сокетов в своё удовольствие.
PRO3 ирогирывает ВЕЗДЕ:
- хотите поставить самый дорогой контроллер? Ставьте уже DMPS3-300-C-AEC, чего стесняться-то)
- хотите жуткое количество портов? Ставьте этих глючных уродцев CEN-CI3-3, может их отладят как будете запускаться.
- хотите чтобы не тормозило? Ставьте CP3 сколько хватит воображения.

Если в проекте от 7-ми комнат неотвратительный монтаж, неидиотская схема коммутации и подбор оборудования не из складских остатков, то после жуткой криворукости программера самая частая причина недовольства клиента - страшные тормоза - оказывается в упорном желании программиста запустить всё это строго на одном контроллере, да ещё и на каком-нибудь AESI до кучи.

 Отправлено: 20.12.16 16:13. Заголовок: Не понимаю, чем поле..

Не понимаю, чем полезным можно так загрузить процессор, что он перестанет отвечать на запросы?

 Отправлено: 20.12.16 23:31. Заголовок: У нас хорошенько при..

У нас хорошенько притормаживало процессор подключение по COM видеомикшера DATAVIDEO. Он постоянно спамит запросами статусов всего чего попало и эти запросы транслировали в порт управления камерами. Когда в дебагере по 250 событий в секунду, процессор начинает туговато реагировать.
Вот к CEN-CI3-3 нареканий не было. Это ведь просто модуль расширения портов по IP. Что там глючит?
C DMPS напротив были какие то проблемы. Только может это еще не 3 серия была.
Про PRO3 и правда, часто не загружен даже картами или карты не используются- т.е. чистой воды продать.
Вот к PRO2 какие то теплые чувства все таки. Как же все быстро компилируется и заливается, не то что на 3 серии.