Область видимости и время жизни переменных.

[kakmyc]

Вопросы такие:

1. Соответствуют ли область видимости и время жизни переменных спецификации языка С/С++ ?
Т.е. глобально объявленные переменные и функции имеют видимость из всех частей программы и срок жизни переменных неограничен.

2. Разрешается ли внутри макросов создание и использование переменных со спецификатором static ?

3. Какие из директив препроцессора можно использовать ?

4. Как организована память программ макросов ? А конкретно, если объявлена глобальная переменная, и используется она эпизодически, а процесс ее расчета непрерывен и ее состояние напрямую связано с ее предыдущим состоянием то надо ее в обязательном порядке при каждом вызове функции считывать из регистров панели а по завершении вычисления записывать в регистры панели или она будет жить и без этого ?

5. Какой размер ОЗУ доступен для использования в макросах ?

[kakmyc]

Просто есть желание переложить часть вычислений (а может и вообще все) на панель для разгрузки ПЛК.
А для этого нужно понимать, что она позволяет делать, а что нет.
Руководство не дает полной картины.
Стек С/С++ для меня родной, проблем с реализацией быть не должно.

[petera]

спецификатор static поддерживается https://owen.ru/forum/showthread.php...l=1#post247040
Объявленные переменены, в том числе и глобальные живут в своей области памяти никак не связанной с регистрами панели.
Вот пример использования макросов, в том числе и глобальных ТЕТРИС https://owen.ru/forum/showthread.php...l=1#post340895

Еще пример https://owen.ru/forum/showthread.php...l=1#post251022

[kakmyc]

Значит панель в связке с блоками ввода/вывода можно использовать как полноценный ПЛК используя возможности С/С++.
Спасибо.

[In_Da_Cher_A]

для разгрузки ПЛК

а он разве нагружен чем-то серьёзным?

переложить часть вычислений

что за специфические задачи, которые надо "перекладывать"? биток майнить?

[kakmyc]

Ну допустим управление десятком систем PID, некоторые из которых многокаскадные, а некоторые оприходовано связаны с соседними.

[kondor3000]

Ну допустим управление десятком систем PID, некоторые из которых многокаскадные, а некоторые оприходовано связаны с соседними.

В таком случае надо использовать ПЛК, панель скорее всего не потянет большой нагрузки.

[In_Da_Cher_A]

Ну допустим управление десятком систем PID, некоторые из которых многокаскадные, а некоторые оприходовано связаны с соседними.

и что это за технологический процесс, где на ОДНОМ "управляющем процессоре" будет сидеть "десяток" ПИД регуляторов, да ещё и каскадных? и что же это за регуляторы?
и при этом - всё это предполагается крутиться на единственной дешманской китайской панели да ещё с сигналами по модбасу?

[Валенок]

Ну допустим управление десятком систем PID, некоторые из которых многокаскадные, а некоторые оприходовано связаны с соседними.

Десяток? Cотни ПИД'ов ни о чём для панели. Не парьтесь про "размер ОЗУ"

а он разве нагружен чем-то серьёзным? ...

+100500. И этот "десяток" еще больше ни о чём для ПЛК. Здесь несложно обосновать и про тысячи ПИД'ов.
kakmyс - вы хотите облегчить жизнь товарному вагону переложив часть груза в тамбур плацкарта.


Поэтому народ и недоумевает про

переложить часть вычислений (а может и вообще все) на панель для разгрузки ПЛК..

Но! Во всех случаях узким местом является не "размер ОЗУ" а канал получения данных и вот это

.... используется она эпизодически, а процесс ее расчета непрерывен и ее состояние напрямую связано с ее предыдущим состоянием ....

является очередным эльфийским подходом. Как минимум применительно к ПИД. Если мы говорим про реальный а не про "мелком на доске" ПИД