Длина и размер строки

В CODESYS при объявлении строки задается ограничение числа ее символов. Если число символов не указано, то по умолчанию используется значение 80. Ограничение максимального числа символов строки в явном виде отсутствует. Фактически длина строки ограничена только объемом памяти, выделенной под проект.

VAR
// Максимальная длина – 40 символов
// Выделенная память – 41 байт
sMessage: STRING(40) := ‘test’;
// Максимальная длина – 80 символов (по умолчанию)
// Выделенная память – 162 байта
wsTitle: WSTRING := “test”;
END_VAR

Базовые функции работы со строками

Значение строковой переменной можно присвоить не только при ее объявлении, но и в коде программы. Однако одного присваивания недостаточно. Для реализации алгоритмов требуются дополнительные операции, например, объединение нескольких строк в одну, поиск в строке нужного символа и т.д. Для этих операций используются базовые функции из библиотеки Standard. Список этих функций с кратким описанием

CONCAT (STR1, STR2)Объединяет две строки в одну

DELETE (STR, LEN, POS)Удаляет из строки заданное число символов с нужной позиции

FIND (STR1, STR2)Производит поиск подстроки в строке

INSERT (STR1, STR2, POS)Добавляет подстроку в строку с заданной позиции

LEFT (STR, SIZE)Выделяет из строки подстроку заданной длины (начиная с первого символа)

LEN (STR)Вычисляет длину строки

MID (STR, LEN, POS)Выделяет из строки подстроку заданной длины (начиная с нужной позиции)

REPLACE (STR1, STR2, LEN, POS)Заменяет в строке один фрагмент на другой (начиная с нужной позиции)

RIGHT (STR, SIZE)Выделяет из строки подстроку заданной длины (начиная с последнего символа)

Примеры использования этих функций:

sVar1 := ‘Hello, ’;
sVar2 := ‘world’;
// sVar3 теперь имеет значение ‘Hello, world’
sVar3 := CONCAT(sVar1, sVar2);
// iLen будет иметь значение 12
iLen := LEN(sVar3);

Функции из библиотеки Standard могут работать только с переменными типа STRING.
Для работы с WSTRING используется библиотека Standard64 с идентичным набором функций, имеющих префикс «W» (WCONCAT, WDELETE и т. д.).

Расширенные функции работы со строками

Важно отметить, что функции из библиотек Standard/Standard64 могут работать только со строками, длина которых не превышает 255 символов. Для работы с более длинными строками используется библиотека StringUtils. В ней содержатся функции, которые в качестве аргументов принимают не строки, а указатели на них. Кроме того, библиотека содержит дополнительные функции для перевода строк в верхний/нижний регистр, удаления пробелов и т. д.

Типы строк STRING и WSTRING предназначены для работы с разными кодировками. Иногда требуется выполнить конвертацию этих типов, например, ввести в визуализацию строку-сообщение типа WSTRING и отправить ее по SMS в виде STRING-значения. Стандартные операторы конверсии STRING_TO_WSTRING/WSTRING_TO_STRING в этом случае не подходят, так как не производят конвертации кодировок, а перекладывают содержимое памяти одной переменной в другую. Решить проблему поможет библиотека OwenStringUtils, разработанная компанией ОВЕН.

Библиотека позволяет:

• конвертировать кодировки;

• работать с подстроками;

• форматировать вывод переменных типа DATE/TOD/DT/REAL

// неправильная конвертация
// wsMessage получит значение "òåñò"
wsMessage := TO_WSTRING('тест');
// правильная конвертация
// wsMessage получит значение "тест"
wsMessage := OSU.CP1251_TO_UNICODE('тест');
// sDateTime получит значение '02.04.2019 08:11:30'
dtDateTime := DT#2019-04-02-08:11:30;
sDateTime := OSU.DT_TO_STRING_FORMAT
(dtDateTime, '%t[dd.MM.yyyy HH:mm:ss]');

Большой набор функций для работы со строками можно найти в библиотеке OSCAT Basic. Часть из них повторяет функционал OwenStringUtils, но присутствуют и уникальные: например, зеркалирование строки и преобразование числа в строку с его HEX-значением.

Помимо видимых символов (букв, цифр, знаков препинания) строка может содержать спецсимволы, которые называются управляющими последовательностями. С их помощью, например, можно организовать перевод строки для вывода нескольких сообщений в одном элементе визуализации.

sMessage := ‘Один$r$nДва’;

В редакторе CODESYS для ввода спецсимволов используется знак ‘$’.

Строки и массивы

Как было сказано в начале статьи, строка представляет собой массив символов. CODESYS V3.5 позволяет осуществлять индексный доступ к строке – как к массиву значений типа BYTE (для STRING) или WORD (для WSTRING). Это удобно при работе с файлами и реализацией протоколов обмена. На рис. 6 приведен пример обработки строки в цикле FOR для определения позиций символов, разделяющих значения. Это может потребоваться при чтении информации из файлов формата .csv.

VAR
sRecord: STRING := '123;456;789';
sSeparatorChar: STRING := ';';
auiSeparatorPos: ARRAY [0..10] OF INT;
i: INT;
j: INT;
END_VAR

j := 0;
FOR i:= 0 TO LEN(sRecord) DO
IF sRecord[i] = sSeparatorChar[0] THEN
auiSeparatorPos[j] := i;
j := j + 1;
// TODO: добавить проверку
// для верхней границы массива
END_IF
END_FOR

Несколько примеров на реальных объектах

Обработка Аварий и вывод на экран

Делал для Молочного завода морозильную камеру, где нужно мониторить параметры температур, и на СПК107 выводил аварии на экран, когда авария срабатывала по уставке. Прилагаю скриншоты:

Небольшой кусок кода обработки аварии:

Лепка таблицы CSV для архивации

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

Как раз реальное применение функции CONCAT.

Отправка SMS через модем ПМ01

Было несколько проектов с применением данного модема, скажу честно стабильно всё работало несколько лет. Было реализовано и в CDS 2.3 и CDS 3.5.

В квадрате выделил пример применения переменной STRING.

Это пока всё. Примеры программ в телеге.

Если есть вопросы, пишите в комментариях, чтобы каждый желающий мог получить ответы.

Ставим два таймера, один с замкнутым выходом, другой с разомкнутым. Данный пример отображает работу гидравлического механизма с двумя катушками Y21 и Y22.

В параметре D2001 выставляете необходимую задержку времени. Этот же параметр можно вывести на панель оператора, любую, где есть драйвер этого ПЛК.

Если будут вопросы, пишите.

Центральный процессор ПЛК во многом действует как процессор обычного компьютера, но мы не часто находим спецификации, которые хотя бы отдаленно соответствуют его производительности даже в низкобюджетном ноутбуке. Причина в том, что, хотя оба процессора выполняют инструкции, которые являются основными, разница в контексте установки требует совершенно разных стратегий выполнения.

Что на самом деле делает ЦП ПЛК?

Для запуска ЦП должен выполнить несколько отдельных задач, каждая из которых тесно связана со всеми остальными:

• Связь с ПО для программирования и загрузка программы

• Передача данных ввода-вывода через объединительную плату

• Чтение и обновление входных регистров

• Расчет результата каждой строки кода

• Обновление выходных регистров

Загрузка и выполнение программы ЦП программируемого логического контроллера существенно отличается от традиционного компьютера. Для большинства ноутбуков мы называем операционной системой (Windows, MacOS или Linux) фоновую систему, которая загружает и запускает программы и предоставляет пользовательский интерфейс. Но ПЛК не устанавливает и не запускает программы, а также не предоставляет пользовательский интерфейс, к которому можно подключиться с помощью мыши и клавиатуры.

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

Для задачи проектирования кода каждый производитель создает свою собственную интегрированную среду разработки (integrated development environment – IDE), например, Rockwell Studio 5000, Siemens TIA Portal или Beckhoff TwinCAT. Каждая из этих IDE устанавливается на ноутбук или настольный компьютер, создается проект, а затем он загружается в среду выполнения на ПЛК через интерфейс Ethernet (или PROFINET, EtherCAT и т. д.) или последовательный (обычно USB) интерфейс.

В наши дни существует развитые версии ПЛК, которые объединяют среду выполнения и ОС на одном устройстве, бок о бок. Примерами служат встраиваемые ПК Beckhoff или PLCnext от Phoenix Contact. Они позволяют выполнять привычное программирование на типичных языках IEC 61131, а также позволяют устанавливать IDE и другие приложения на основе ОС на самом ПЛК.

Как ПЛК взаимодействует с устройствами ввода-вывода?

Коммуникация печатной платы обеспечивает передачу всей информации ввода/вывода между ЦП и модулями ввода/вывода. Она также может обрабатывать передачу данных на модули связи для подключения к удаленным блокам ввода/вывода.

Соединения на печатной плате в шасси или стойке ПЛК принимают форму многоконтактного разъема, который подает функциональное питание на модули (не питание полевых устройств, но это другая тема) и достаточно линий передачи и приема данных для быстрого сканирования множества модулей за очень короткое время. В зависимости от производителя, эти линии данных могут использовать форму последовательной связи или высокоскоростное соединение EtherCAT.

Некоторые ПЛК имеют фиксированное количество встроенных входов/выходов (малые ПЛК «коробочного» типа), а некоторые из них даже допускают установку дополнительных модулей, но этим моделям по-прежнему требуется соединение данных между ЦП и точками ввода/вывода.

Процессор максимально быстро опрашивает модули ввода и вывода на предмет текущего состояния ввода-вывода и помещает эти значения в специальные адресные регистры в памяти процессора.

Строки кода, где каждый тег или переменная ссылается на местоположение в банке памяти, вычисляются по одной за раз, пока формируется временный выходной регистр. Как только последняя строка сканируется, этот выходной регистр отправляется в каждый выходной модуль. Поэтому выходные терминалы не обновляются в тот момент, когда строка меняется с false на true – это только выглядит так, потому что цикл сканирования ПЛК очень короткий.

Наиболее важные характеристики ЦП ПЛК

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

Для скорости тактовая частота ПЛК не имеет значения. Вместо этого нас интересует время выполнения различных инструкций. Биты, целые числа, числа с плавающей точкой, функции – каждое из этих вычислений требует определенного количества времени, выделенного процессором. Технические описания предоставляют эту информацию свободно, позволяя программисту оценить количество времени, которое потребуется для полного сканирования между считыванием входов и реализацией выходов.

Итак, нас интересует скорость, но вместо тактовой частоты в ГГц, это скорость цикла, измеряемая в мкс или мс. Поскольку каждая программа индивидуальна, нет возможности предоставить спецификацию времени цикла для каждого пользователя.

Что касается хранения программ, нам не нужно обременять себя внешним твердотельным накопителем на 500 Гб. В отличие от компьютера, который хранит изображения, видео и программы десятками, мы храним несколько строк текстового кода, как файл блокнота. Представьте себе самый большой файл .txt, который вы когда-либо видели. Несколько МБ, те так ли? Аналогично, акцент делается не на размере хранилища, а на безупречную надежность.

Обычно объем памяти для хранения программ составляет менее 1 ГБ – только самые крупные промышленные процессы могут приблизиться к этому размеру. Некоторые ПЛК допускают расширение памяти или указывают начальную стоимость моделей ЦП с большим объемом флэш-памяти, но тратить деньги на покупку большего объема, чем вам нужно, бессмысленно.

Какой процессор лучше всего подойдет для моего ПЛК?

Вот основные вещи, на которые вам нужно обратить внимание:

1. Протокол связи, совместимый с вашим ноутбуком для программирования. Если вы покупаете старый процессор с интерфейсом программирования RS-232, убедитесь, что у вас есть кабель и программное обеспечение, соответствующие ему.

2. Достаточно памяти для хранения вашей программы. Сколько вам нужно? Короткий разговор с производителем, скорее всего, прояснит этот вопрос, но если у вас небольшой процесс, то 100 МБ вероятно хватит с запасом.

3. Возможности ввода-вывода. Каждый ЦП оценивается по количеству точек ввода-вывода, которые могут быть подключены к системе. Убедитесь, что у вас их достаточно.

4. Низкое время примерного цикла для обеспечения надежности системы. Опять же, пообщайтесь с производителем, чтобы получить представление о том, сколько точек ввода-вывода и сколько инструкций вам, скорее всего, понадобится, чтобы обеспечить низкую задержку между входными данными и выходными командами.

Теперь, обладая этой информацией при обновлении системы и парка ПЛК вы будет уверены, что не потратите деньги зря.

Советуем также прочитать еще одну статью автора по этой же теме "Объяснение режимов работы центрального процессора ПЛК".

Материал подготовлен Московским заводом тепловой автоматики (МЗТА)

Уважаемые коллеги, с удовольствием делимся экскурсом в прошлое отечественной автоматизации и публикуем историю, рассказанную Михаилом Непомниным – начальником КБ автоматизации ЭПО «Сигнал» о создании одних из первых отечественных аппаратных и программных средств АСУ ТП.

В уже далеком 1988 году я после окончания университета и 5 лет работы в элитном цехе регулировщиком РЭА я перешел в ОМА (отдел механизации и автоматизации), в новое бюро автоматизации поверочных работ (КБ АПР сокращенно). Часть инженеров местного политехнического института калымила, внедряя нам автоматизацию проверки выпускаемой продукции. А мы были у них на подхвате и учились уму разуму или постигали тонкости автоматизации.

Продукцией же были специальные датчики давления, выпускаемые для военных – они производились двух типов. Нас этом я заканчиваю рассказ про сами датчики, поскольку это секретная продукция. А вот автоматизированные рабочие места для их проверки при выпуске секретом не являются. Про них я могу говорить свободно. Тем более, что АРМы сейчас уже не работают на выпуске, заменены на новую модификацию. Так что я даже коммерческую тайну не выдаю.

И так, в конце 1987 года создалось КБ, а в апреле 1988 года я перешел туда инженером-программистом. Вроде бы так моя должность называлась. КБ было преимущественно молодежное. Руководил им грамотный товарищ, который через полгода стал замом Главного инженера, а я стал начальником КБ.

Политех разрабатывал нам АРМы проверки и один АРМ «центральный процессор» для управления процессом и ведения архивов, как на бумажном носителе, так и в электронном виде. Женская часть КБ разбиралась с КД по проверки и помогала в языке высокого уровня ТурбоБейсик сочинять политеховцам программу центрального процессора. Вернее, разрабатывали прогу девчонки при постоянном контроле и подсказке работников политеха. А мужеска часть КБ, на тех же условиях разрабатывала в ассемблере программу для контроллера К1-20 микропроцессорной 580-й серии микросхем.

И не смейтесь над нами. Никаких Виндоус тогда еще не было, ТурбоБейсик был крутой язык и в ассемблере было не западло писать программу. Напомню, что это был далекий 1988-й год. Мы планировали писать программу центрального процессора на отечественной ЭВМ ДВК, но потом разжились IBM-ками. И если на ДВКшках мы в редкие минуты отдыха гоняли компьютерную игру Тетрис, то на IBMках начали кроме игр серьезно изучать языки высокого уровня типа Турбо- и Квикбейсика.

Поскольку я в университете прослушал курс лекций программирования на Алголе и Фортране, а также прошел практику по программированию, я тоже начал вместе с дамами нашего КБ программировать на Бейсике. А не осваивал один ассемблер для К1-20. Изучение Бейсика мне кстати очень пригодилось в дальнейшем. Ну об этом потом. А пока расскажу о составе и характеристиках контроллера К1-20. Это его типовое что ли название. Реально у нас были две опции контроллеров с шифрами МС2702 и МС2721.

На рисунках видно, чем они отличались друг от друга, но в общем и целом контроллеры были почти одинаковы.

Питание 5В было мощное – 3А. Контроллер грелся, но работал. Скажу, что мы успели поставить три АРМа в одном цехе и один в другом. Работа кипела. Собирались внедрять программу «центральный процессор» и увеличивать количество АРМ и диапазон охвата. Но (как часто в жизнь вмешивается это чертово «Но») наступила конверсия и датчики стали нужны в значительно меньших количествах, а с ними не стала нужна и наша автоматизация.

Хотел привести краткие технические характеристики контроллеров, но у меня документации давно нет. А в интернете что-то не нашел. Поэтому пишу, что помню.

Эти контроллеры содержали полноценные микропроцессорные комплекты 580-й серии. С контроллером прямого доступа к памяти, контроллерами прерываний и последовательного интерфейса. Разница была в конструкции пульта и количестве разъемов.

У МС2702 было 3 разъема, но большие. У МС2721 – 5, из которых 4 – меньшего размера, а пятый – такой, кажется, как у МС2702.

В коробочке в фольге микросхема ППЗУ для прошивки пользовательских программ. ЗИП в конденсаторную бумагу завернут, кроме картонной упаковки. Маленькая отвертка присутствует. В общем – кайф или мечта автоматизатора советских времен. Итак, переходим к основной части.

Состав АРМ:

1. Контроллер МС2702 (2721)

2. Блок питания контроллера ГН 09-01

3. Вольтметр В7-28 (В7-34)

4. Блок сопряжения

5. Жгуты

Один тип контроллеров для потенциометрических датчиков, другой – для индуктивных. За давностью лет и начинающимся склерозом, не помню, какой для каких датчиков применялся. Зато помню, какой вольтметр для чего служил. Поскольку В7-28 мог измерять напряжение в долях от опорного, но не мог работать с переменным напряжением, он обсчитывал потенциометрические датчики.

А вольтметр В7-34 работал с индуктивными датчиками. Они питались от напряжений с частотой 400 Гц или 2000 Гц, и спокойно обсчитывались умеющим измерять переменку В7-34. Для потенциометрических датчиков опорное напряжение бралось со штатного блока питания ГН 09-01. Индуктивные же запитывались со специализированного блока переменного тока заводской разработки.

Блок сопряжения состоял из отдельного корпуса и платы коммутации и платы связи с вольтметром. Плата коммутации осуществляла перебор датчиков на коллекторе. Плата вольтметра программировала вольтметры и посылала команду «Пуск» при считывании данных с каждого проверяемого датчика. Корпус служил для подсоединения плат и соединения разъемов внешних жгутов.

Жаль, что у меня нет фото АРМа целиком, фото блока сопряжения и схем АРМа. Могу только по памяти изобразить функциональную или структурную схему АРМа и блока сопряжения.

Все пропало в период перестройки и дикого капитализма. И так промышленный уклад у нас в стране был не очень крепкий. А в период позднего Горбачева и Ельцина стал вообще ни в дугу.

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

Хорошо сейчас процесс потихоньку налаживается.

Еще раз благодарим Михаила Непомнина за рассказ, а также дополним его историей развития Московского завода тепловой автоматики (МЗТА), а точнее кратким перечнем приборов автоматизации, также предшественников современных ПЛК, которые были созданы до событий, о которых идет речь в статье, то есть до 1988 года.

• 1955-60 гг. – первый электронный прибор – ЭР-111-К – «КОМЕГА», дифференциальные манометры и электронные приборы регулирования – РБ-100

• 1960-е – комплекс – КРИСТАЛЛ, регулирующий прибор импульсного действия с бесконтактным выходом – РПИБ, дифференциатор ламповый – ДЛ-Т, электронные сигнализаторы и ограничители температуры ЭСП-К, ЭОС-Т

• 1974 – регуляторы энергетических установок – КАСКАД, КОНТУР

• 1975 – прибор регулирующий – Р25, прибор корректирующий – К15.3

• 1981 – прибор контроля пламени – Ф34

• 1982 – фотодатчик низкочастотный – ФДЧ, блок управления релейного регулятора – БУ21

• 1983 – индикатор положения – ИПУ

• 1984 – устройства для автоматизации промышленной энергетики и теплоснабжения – Р29

• 1986 – программируемый регулятор – ПРОТАР

• 1987 – многофункциональные регуляторы ТЕПЛАР, ПРОЛОГ, прецизионный регулятор температуры – ПРОТЕРМ