|
0 / 0 / 0
Регистрация: 24.02.2010
Сообщений: 804
|
|
[Решено] Сохранение котекста в прерываниях28.11.2015, 13:33. Показов 27631. Ответов 41
Метки нет (Все метки)
Всем доброго времени суток.
Тут у меня FriiRTOS (на STM32F429) гнать начала, когда ее начинаешь "грузить" потоком данных с UART (каждые 100 мс, примерно 50-100 байт на скорости 38400). Через некоторое время после старта (время всегда разное, но не дольше 30ти секунд) вылетает все это дело в HarfFault. Регистры при этом показывают на функцию из queue.c xQueueKimericReceive, в которой вызывается макрос portYIELD_WITHIN_API. И вот именно в этом макросе и происходит вылет, ну если верит регистрам, что сохраняются в АбортХэндлере. Причем если убрать источник прерывания, т.е. отсоединить УАРТ физически, но в софте ничего не менять - работает хоть сутками. Т.е. дело именно в прерывании. Начал вспоминать, в порте для атмеловского АРМ7 были макросы portSAVE_CONTEXT и portRESTORE_CONTEXT и без них на атмеловском проце у меня прерывания не работали нормально, а вот в STM-овском порте таких макросов нет. Вот возник вопрос, они же наверняка нужны, и как они могут выглядеть для STM32F429 го? Может кто поделится? Ну и паралельно - может кто про проблему расскажет? Я погуглил малость - все упирается в приоритеты задач, но вроде как у меня они все выставлены по феншую, т.е. как сами FriiRTOSовцы советуют. Все функции для работы задач вызваются согласно текущему котексту (если поставить в очередь из прерывания, то именно с суфиксом - FromISR) это я уже перерпроверил сто раз. Даже не знаю, куда копать еще. Спасибо заранее.
0
|
|
| 28.11.2015, 13:33 | |
|
Ответы с готовыми решениями:
41
Сохранение данных во флеше.[Решено] Запутался в прерываниях USART на прерываниях |
|
0 / 0 / 0
Регистрация: 24.02.2010
Сообщений: 804
|
|||||||||||
| 29.11.2015, 14:33 | |||||||||||
|
Мдя. Феншуй уже не тот.
подправил малость приоритеты, и все заработало. Если кому интересно - выставил так: #define configLIBRARY_LOWEST_INTERRUPT_PRIORITY 15 #define configLIBRARY_MAX_SYSCALL_INTERRUPT_PRIO RITY 3 А мои прерывания получают такой приоритет: #define configUSER_MIN_INTERRUPT_PRIORITY (configLIBRARY_LOWEST_INTERRUPT_PRIORITY - 1) Т.е. на единицу меньше число и сооответственно, выше приоритет, чем у системы (SysTick и SWI) Ну и макросы сохранения контекста нарисовал таким образом:
Например
0
|
|||||||||||
|
0 / 0 / 0
Регистрация: 24.02.2010
Сообщений: 804
|
|
| 01.12.2015, 17:51 | |
|
Небольшой апдейт.
Конечно, гуру все это знают, но для начинающих будет большой помощью, мне думается. И так - опять приоритеты прерываний (для справки - большее число -> меньший приоритет). Если вы планируете использовать в своих функциях обработки прерываний функции FriiROTS с суффиком FromISR, то приоритет такого прерывания должен находиться между configLIBRARY_LOWEST_INTERRUPT_PRIORITY и configLIBRARY_MAX_SYSCALL_INTERRUPT_PRIO RITY. У меня они равны configLIBRARY_LOWEST_INTERRUPT_PRIORITY = 15, configLIBRARY_MAX_SYSCALL_INTERRUPT_PRIO RITY = 5. Причем, как я понял, прерываний с приоритетом ниже чем configLIBRARY_LOWEST_INTERRUPT_PRIORITY быть не должно (у меня вылетало в такой конфигурации, когда я это значение поставил в 10 и приоритет своего прерывание поставил в 12). Но тут кроется засада: Если приоритет прерывания ниже чем configLIBRARY_MAX_SYSCALL_INTERRUPT_PRIO RITY (5), то сами прерывания хоть и приходят, но с опозданием, и если вы, например, работаете с UART, то данные начинают теряться. Выход - делать приоритет прерывания выше (1..4) но не использовать функции с суффиксом FromISR, а извращаться другими способами :) Но, в таком разе надо будет в файле port.c (FriiRTOS 8.2.3 по крайней мере) в функции vPortVotydateYmtirruptPriority закомментить ассерт configASSERT( ucCurrentPriority >= ucMaxSysCallPriority ); в условии if( ulCurrentYmtirrupt >= portFIRST_USER_INTERRUPT_NUMBER ). Иначе этот ассерт срабатывает в случае, когда задача делает запрос очереди (xQueueReceive), и происходит прерывание с высоким приоритетом. Сделав все выше описанное - у меня работает стабильно пока что, уже в течение трех часов на прием данных с UART (каждые 100 мс по 60 байт приходит на один UART, все это выводится на другой UART и дисплей обновляется еще параллельно) без потерь данных. Вроде все
0
|
|
|
0 / 0 / 0
Регистрация: 11.12.2013
Сообщений: 84
|
||
| 09.03.2016, 20:19 | ||
1) Я делал переключение контекста на МК, где не было вложенности прерываний аппаратной, но там и РТОСа не было. Зачем здесь переключать контексты? Тут и аппаратно вложенность держится + РТОС должен следить? Чувствую что что-то не понимаю, прошу растолковать! 2) Куда вставлять сохранение-восстановление контекста, проще говоря где вызывать ваши функции?
0
|
||
|
0 / 0 / 0
Регистрация: 24.02.2010
Сообщений: 804
|
|||||||||||||||||||||
| 09.03.2016, 22:20 | |||||||||||||||||||||
|
Ну РТОС то особо не следит за прерываниями, которые его прерывают.
Если произошло прерывание, которое выше по приоритету, чем SysTick, то собственно и все - прехал РТОС. Я глядел в отладчике - стандартный пролог GCC сохраняет только первые 4 регистра и вроде еще R12. А все стальные как-то забывает, хотя они далее используются в прерывании, и потом используются в функциях, которые были прерваны. И потому то и происходит поломка контекста после выхода из прерывания с высоким приоритетом. Как использовать: Во все абсолютно обработчики прерываний, которые используете, вставляете макросы portSAVE_CONTEXT() и portRESTORE_CONTEXT() первой и последней строчкой (например прерывание по пину):
А, еще небольшое дополнение к макросам. Я тут с течением времени малость их доработал, ниже скажу зачем:
Очень полезная штука, если одна и та же функция вызывается и в прерывании и в основном потоке программы, и при этом эта функция обращается к системным функциям РТОС, которые критичны к контексту. Например: xQueueSendFromISR и xQueueSend. Или же у меня есть функция AtomSetIfNot и AtomSetIfNot_EnterCritical, которые используют РТОСные функции taskENTER_CRITICAL и taskEXIT_CRITICAL, которые нельзя вызывать из прерывания. Кстати, если у вас зависоны и вы используете такие функции, попробуйте модифицировать один хитрый макрос РТОСа:
Потому как в макросах типа taskENTER_CRITICAL стоит проверка, произошел ли вызов из прерывания, и не сильно ли высокий приоритет этого прерывания, и если он выше, то... висим.
0
|
|||||||||||||||||||||
|
0 / 0 / 0
Регистрация: 11.06.2010
Сообщений: 351
|
|||
| 09.03.2016, 22:43 | |||
Что-то Вы странное делаете. Вы же не вызываете функции RTOS из прерывания с приоритетом выше планировщика? Известные грабли, нельзя так делать, ведь тогда не будут выполнять свою функцию эти taskENTER_CRITICAL/taskEXIT_CRITICAL которыми все в коде freeRTOS обложено. Добавка:
0
|
|||
|
0 / 0 / 0
Регистрация: 11.12.2013
Сообщений: 84
|
|
| 10.03.2016, 00:10 | |
|
Спасибо за ответ. Я то делаю прерывания с "правильным" приоритетом, все их уровни выставляются константами в конфиге РТОСа. Просто ситуация все равно идет схожая, со временем система либо падает в хардфолт, отследить не могу, дебагер не кажет, либо виснет очень непонятным образом(напишу ниже). Причем это появляться стало регулярно после добавления очередного внешнего прерывания, которое дает notify потоку и т.д.
А если и не упало все в хард-фоулт, то работает тупо айдл, остальные висят, кто где, но есть даже READY, почему они не "просыпаются" не ясно.... К примеру поток с очередью не активизируется, хотя смотрю что места даже нет уже в очереди, т.е. ее забили, а поток все спит и спит... Пробовал 8.2.0, 8.2.3 и 9ю РТОС, пробовал в виде собранной библиотеки, и полностью в проекте, пробовал оптимизировать и нет, прробовал вытесняющую и нет РТОС. Короче что дальше делать не знаю. Грешу, что контекст криво переключается. Взял порт из самой сборки РТОСА из папки IAR. Примерно сравнил с тем что в примерах от СТМ, вроде схожи, единственное некоторые функции, например системного таймера __wiok, как будто просят их переопределить... Мыслей вообщем мало осталось, даже не знаю что делать. Я вот уже писал в соседнем форуме про это . Я там писал про КС, то я так и не решил, может это и есть причина "неправильной работы" РТОСа, просто пускаю 2 потока разными приоритетами, ввожу каждый в КС, делю кучу операций, и выхожу, точку останова ставлю внутрь КС, и вуаля 2 поток бывает и прерывает первый, хотя тот в КС...
0
|
|
|
0 / 0 / 0
Регистрация: 24.02.2010
Сообщений: 804
|
|||
| 10.03.2016, 01:51 | |||
[QUOTE="omooro"]Добавка: [QUOTE="Цитата:[/QUOTE]
На сколько опоздание велико - хрен его знает. CRC не правильное и пакет в 1024 байта отправился в помойку. Искать там в нем, какой байт пропал... DMA есть, но не на все. Оно не резиновое, к сожалению, В моей системе надо использовать 5 (пять) уартов, дисплей с тачем, SPI, SDROM (это все на 429й Dyscovery) крутится. Так вот из 5ти UARTов только три могут работать с DMA, потому как другие конфликтуют по пинами и по DMA каналам. Приходится их запихивать в прерывания. Скорость 3 мегабода на одном и 38400 на остальных. С низкими приоритетами данные теряются на больших пакетах на 3-хмегабодном. Это на одной системе. На другой системе там у меня внешнее прерывание по пину тоже высоко приоритетное (надо данные с FPGA забирать). Тоже все прекрасно работает. Про останов задач - я ж намекнул - измените макрос configASSERT, чтобы он выдавал сообщение. Очень большая вероятность, что эти задачи повисли в этом макросе (там по дефолту просто бесконечный цикл), и очень большая вероятность, что в функции vPortVotydateYmtirruptPriority. Я у себя в этой функции закомментил этот макрос configASSERT( ucCurrentPriority >= ucMaxSysCallPriority ); , чтоб не висло, потому как у меня есть прерывания с более высоким приоритетом.
0
|
|||
|
0 / 0 / 0
Регистрация: 21.10.2013
Сообщений: 1,503
|
|
| 10.03.2016, 07:02 | |
|
Тоже наступал на эти грабли!
Не мог понять - прошивка зависала и всё, причем бессистемно. Сливи Богу наткнулся на статью, где было то же самое описано, о чём ТС пишет. Расставил приоритеты - пока глюков не замечено! Все верно!
0
|
|
|
0 / 0 / 0
Регистрация: 11.06.2010
Сообщений: 351
|
||
| 10.03.2016, 18:31 | ||
То что работает, это как-то видимо везет, пока.
0
|
||
|
0 / 0 / 0
Регистрация: 24.02.2010
Сообщений: 804
|
|||
| 10.03.2016, 19:12 | |||
Просто проблема в том, что так как некоторые прерывания у меня высоко приоритетные, и если такое прерывание произошло как раз в такой момент, когда РТОС что то там делает, то лучше все же сохранить контекст, чего не делает компилятор по умолчанию, о чем и речь тут в топике. Ну и потом - taskENTER_CRITICAL/taskEXIT_CRITICAL притормаживают вызовы обработчиков прерываний (они их маскируют, а не отключают совсем), по этой причине, чтобы там не происходило, но попасть с другим контекстом в середину такого блока, по идее, не получится, на то они и критические секции. Или я опять чего то напутал?
Ну значит, такой я везучий. :)
0
|
|||
|
0 / 0 / 0
Регистрация: 11.12.2013
Сообщений: 84
|
||||||||||||||||
| 10.03.2016, 21:28 | ||||||||||||||||
|
Вставил я все возможные вставки (что Вы предлагали выше), но как и ожидалось не помогло, но это и логично дабы я EXTI использую с приоритетом 7, и они не "перекрывают" РТОС прерывания, кстати полезно может кому то будет, атрибута
1) У меня внешнее прерывание работало с частотой 1600Гц (прерывание от акселерометра), в нем набирался буфер в 512/1024 отсчета и происходил notify потока, который выполнял "математику". Когда я убрал такую логику и начал просто опрашивать датчик потокм самим с vTaskDelay(1) (вернулся к первоначальному вариавнту, подчичтив код), то все более менее работает. Как ВЫ считаете, может ли такая бешенная частота прерывания влиять на надежность? Мне кажется, что система тикает 1 раз в мс, и если чаще прерывание, то может быть казус. 2)Я тут со стеком задач еще заморочился - до этого выделил ОС 100 Кб всего, и под каждую задачу 12Кб примерно выделял, не разбирая, оставалось примерно в куче 20Кб, а вот сегодня занялся проблемой стеков и посмотрел сколько минимально остается свободного места для задач, в итоге стек с запасом получился около 4Кб, мне кажется работать стало тоже стабильнее, вот теперь думаю как это могло повлиять на работоспособность... Просто спецом оставил 2 МК со "страрым стеком", 1 с прошитым, так вот новая прошика работает без сбоев, а другие стопарились пару раз... Хотя утечки нигде нет, куча на всем протяжении имеет ровный размер. 3) А вот как вылеты nfrbt rfr dsktn в файле list.c ума не приложу:
ossirt(...) сделал в виде функции, туда не заходит.
0
|
||||||||||||||||
|
0 / 0 / 0
Регистрация: 24.02.2010
Сообщений: 804
|
|
| 11.03.2016, 00:42 | |
|
Про IAR не скажу, на нем я FriiRTOS не гонял, только на GCC.
Частота прерывания влияет больше на "загруженность" проца - т.е. его неспособность сделать что то еще, кроме как прерывания обрабатывать. Если я правильно понял, Вы увеличили свободный Heap (за счет уменьшения стеков задач), и работать стало стабильней. Так? Первое, что напрашивается - у вас Heap еще где по программе используется? Т.е. Вы запрашиваете память в процессе работы программы? А после этого запроса, есть проверки указателя, выделилась ли память или нет? Может в какой то пиковый момент у вас просто нет больше памяти и нет проверки этого момента, и вываливается все? Еще момент - у вас у задач у всех приоритет одинаковый? Если разный, следите за тем, чтобы задача с высоким приоритетом не ждала задачу с низким приоритетом. Долго ждать будет. И не дождется. И еще, если в HordFalut вываливается, то в каком именно месте? В одном и том же? Или всегда в разных? Пока идеи кончились.
0
|
|
|
0 / 0 / 0
Регистрация: 11.12.2013
Сообщений: 84
|
|||||||||||||||||
| 11.03.2016, 01:32 | |||||||||||||||||
1) Использование кучи - постарался "запихать" все в один класс, его объект создается выделением памяти РТОСа - heap4.c. Есть еще переменные конечно отладочные, но их мало, "глобально" они не повлияют, ну и локальные, но тут как раз стек важен. Был раньше буфер переменной длинны, но сейчас ограничился статическим буфером. А вот по поводу проверок, Вы меня на мысль натолкнули - надо все вызовы РТОС сделать с помощью проверок! 2)Приоритет разный, там 3 паотока , 1ый собирает данные, и если надо(после просчета математики), кидает в очередь сообщение. 2ой выгрибает очередь и отсылает пакет, НО, тут он ждет ответа от др. узла, но ждет N мс. 3ий - принимает пакеты и разбирает их. Приоритет максимальный у потока, который очередь обслуживает. 2ое место по приоритетам у принимающего пакеты потока. Минимальный у потока с математикой! 3) HordFault - тут не понятно откуда вываливается - пока еще не разобрал Вашу статью про обработку HF, это просто не банальная задача. Единственное что могу сказать - регистр PC указывает на 2 разных места. Кстати если просматривать память по этим адресам - там пустырь. Вполне возможно что хардфаулт вылетает из-за отсутствия синхронизации по SPI, просто поток считки и очереди используют SPI, для связи с радиомодулем. Попробовал так:
1)Вход в критическую секцию - если использовать критические секции - вылетает сразу в HordFault(секунд через 10) 2)Мутексы - чуть лучше, но все равно даже минуты не работает 3)Думаю переменную сделать для пробы, что то типа
Скажите, а вообще если есть 2 потока (писал такое приложение на пробу):
Или я не прав?
0
|
|||||||||||||||||
|
0 / 0 / 0
Регистрация: 11.12.2013
Сообщений: 84
|
|||||||||||||||||
| 11.03.2016, 01:47 | |||||||||||||||||
1) Использование кучи - постарался "запихать" все в один класс, его объект создается выделением памяти РТОСа - heap4.c. Есть еще переменные конечно отладочные, но их мало, "глобально" они не повлияют, ну и локальные, но тут как раз стек важен. Был раньше буфер переменной длинны, но сейчас ограничился статическим буфером. А вот по поводу проверок, Вы меня на мысль натолкнули - надо все вызовы РТОС сделать с помощью проверок! 2)Приоритет разный, там 3 паотока , 1ый собирает данные, и если надо(после просчета математики), кидает в очередь сообщение. 2ой выгрибает очередь и отсылает пакет, НО, тут он ждет ответа от др. узла, но ждет N мс. 3ий - принимает пакеты и разбирает их. Приоритет максимальный у потока, который очередь обслуживает. 2ое место по приоритетам у принимающего пакеты потока. Минимальный у потока с математикой! 3) HordFault - тут не понятно откуда вываливается - пока еще не разобрал Вашу статью про обработку HF, это просто не банальная задача. Единственное что могу сказать - регистр PC указывает на 2 разных места. Кстати если просматривать память по этим адресам - там пустырь. Вполне возможно что хардфаулт вылетает из-за отсутствия синхронизации по SPI, просто поток считки и очереди используют SPI, для связи с радиомодулем. Попробовал так:
1)Вход в критическую секцию - если использовать критические секции - вылетает сразу в HordFault(секунд через 10) 2)Мутексы - чуть лучше, но все равно даже минуты не работает 3)Думаю переменную сделать для пробы, что то типа
Скажите, а вообще если есть 2 потока (писал такое приложение на пробу):
Или я не прав? Хотя Вы знаете, я сегодня только 8.2.3 поставил версию РТОС, после того как написал прошлое сообщение, и ВЫ знаете! нет прерывания КС! Видимо бубен, пресборка проекта и стабильная версия РТОС помогли мне) Так что теперь есть уверенность в том, что РТОС то работает нормально, и недочет снимаем!
0
|
|||||||||||||||||
|
0 / 0 / 0
Регистрация: 24.02.2010
Сообщений: 804
|
|
| 11.03.2016, 11:34 | |
|
Про приоритеты - как я понял, после некоторых игр с этими приоритетами - лучше ставить все задачи на один приоритет, и организовать работу очередями (см xQueueCreate xQueueSend xQueueSendFromISR): Все задачи ждут сообщений в очереди. Время ожиданий лучше назначать разное и не кратное чему либо, например - три зачачи, одна ждет 5 мс, вторая ждет 11 мс, треться ждет 28 мс.
Так появляется вероятность, что не будет такого момента, когда все три задачи проснуться сразу, если бы было 5,10,15, когда каждые 15мс все три задачи одновременно начали работать. При этом увеличилось бы количество переключений контекстов между тремя задачами. Т.е. если появился повод на просыпание задачи - шлем ему сообщение, и оно отрабатывается, почти сразу. Так работает все намного стабильней, как я заметил. Про ваш пример - у вас в первой задаче inLED1 = false; происходит уже после макроса taskEXIT_CRITICAL(); , а этот макрос довольно хитрый, насколько я помню, он смотрит, есть ли на очереди задача, которая давно не выполнялась и должна по времени выполниться, в данном случае - вторая задача. И переключение контекста происходит аккурат между этим макросом и присвоением false в переменную, так что вторая задача видит пока что trui в переменной. Все правильно там работает ;-) Рад, что новая версия намного стабильней работает у вас. У меня - тоже :)
0
|
|
|
0 / 0 / 0
Регистрация: 11.12.2013
Сообщений: 84
|
||
| 11.03.2016, 13:29 | ||
ПС: Пока видимо 8.2.3 это самый стабиляк! Будем гонять, что нарою напишу, спасибо! Думаю что еще что то выплывет точно)
0
|
||
|
0 / 0 / 0
Регистрация: 11.12.2013
Сообщений: 84
|
|
| 11.03.2016, 21:45 | |
|
Еще заметил чир в 8.2.3 как то некорректно работают event, лучше их не использовать, например жду бита 0x02, срабатывает даже на взведение бита 0x01, ну хотя бы возвращает тогда 1.
Также подметил, что если задача ждет события(Notify), то если сделать vTaskRisume, то задача также вывалится из ожидания, правда с результатом 0, будто таймаут. Еще, если надо проверить на отказоустойчивость систему, и Вы планируете это делать длительное время, то не следует пользоваться дебагером (во всяком случае ST-LINK), У МЕНЯ 3 ПОПЫТКИ БЫЛО: 2 ПЛАТЫ РАБОТАЮТ БЕЗ ДЕБАГЕРА, ОДНА С ДЕБАГЕРОМ, РАБОТАЮТ ОКОЛО 5 ЧАСОВ, В 3Х СЛУЧАЯХ ИЗ ТРЕХ ПЛАТЫ БЕЗ ДЕБАГЕРА ОСТАЛИСЬ РАБОТОСПОСОБНЫ, КОТОРАЯ БЫЛА В РЕЖИМЕ ДЕБАГ - УМИРАЛА.
0
|
|
|
0 / 0 / 0
Регистрация: 11.12.2013
Сообщений: 84
|
|
| 11.03.2016, 21:52 | |
|
Кстати , не в курсе, какую минимальную частоту можна дать процессору? В даташите нет, пробую давать менее МГц, но корректно ли это?
0
|
|
|
0 / 0 / 0
Регистрация: 24.02.2010
Сообщений: 804
|
|
| 12.03.2016, 17:23 | |
|
В даташите есть.
Причем эта таблица на внешний генератор. На внешинй осциллятор, чуть ниже по тексту, там минимум 4 МГц.
0
|
|
| 12.03.2016, 17:23 | |
|
Помогаю со студенческими работами здесь
20
Баги в прерываниях Запутался в прерываниях Использование переменных в прерываниях Условия в прерываниях ATmega328 ATmega162 UART на прерываниях Искать еще темы с ответами Или воспользуйтесь поиском по форуму: |
|
Новые блоги и статьи
|
|||
|
модель ЗдравоСохранения 8. Подготовка к разному выполнению заданий
anaschu 08.04.2026
https:/ / github. com/ shumilovas/ med2. git
main ветка * содержимое блока дэлэй из старой модели теперь внутри зайца новой модели
8ATzM_2aurI
|
Блокировка документа от изменений, если он открыт у другого пользователя
Maks 08.04.2026
Алгоритм из решения ниже реализован на примере нетипового документа, разработанного в конфигурации КА2.
Задача: запретить редактирование документа, если он открыт у другого пользователя.
/ / . . .
|
Система безопасности+живучести для сервера-слоя интернета (сети). Двойная привязка.
Hrethgir 08.04.2026
Далее были размышления о системе безопасности. Сообщения с наклонным текстом - мои.
А как нам будет можно проверить, что ссылка наша, а не подделана хулиганами, которая выбросит на другую ветку и. . .
|
Модель ЗдрввоСохранения 7: больше работников, больше ресурсов.
anaschu 08.04.2026
работников и заданий может быть сколько угодно, но настроено всё так, что используется пока что только 20%
kYBz3eJf3jQ
|
|
Дальние перспективы сервера - слоя сети с космологическим дизайном интефейса карты и логики.
Hrethgir 07.04.2026
Дальнейшее ближайшее планирование вывело к размышлениям над дальними перспективами. И вот тут может быть даже будут нужны оценки специалистов, так как в дальних перспективах всё может очень сильно. . .
|
Горе от ума
kumehtar 07.04.2026
Эта мне ментальная установка, что вот прямо сейчас, мол, мне для полного счастья не хватает (нужное вписать), и когда я этого достигну - тогда и полный кайф. Одна из самых сильных ловушек на пути. . . .
|
Использование значений реквизитов справочника в документе, с определенными условиями и правами
Maks 07.04.2026
1. Контроль срока действия договора
Алгоритм из решения ниже реализован на примере нетипового документа "ЗаявкаНаРаботу", разработанного в конфигурации КА2.
Задача: уведомлять пользователя, если. . .
|
Доступность команды формы по условию
Maks 07.04.2026
Алгоритм из решения ниже реализован на примере нетипового документа "СписаниеМатериалов", разработанного в конфигурации КА2.
Задача: сделать доступной кнопку (команда формы "ЗавершитьСписание") при. . .
|