Отправлено: 04.06.08 17:25. Заголовок: MBAGZU: Типы данных

В рамках разработки следует определится с набором применяемых для обмена типов данных. На данный момент список типов следующий:

- BIT
- INT16
- UINT16
- INT32
- UINT32
- INT64
- FLOAT32
- FLOAT64
- DATE
- TIME
- DATETIME
- STRING

стоят следующие вопросы:

1. Структура сложных типов DATE, TIME, DATETIME - насколько плотно упаковывать? Насколько сложно, например, вынимать один или несколько битов из 16-и разрядного регистра в разных контроллерах? Понятно, что при реализации на С\С++, как на SCADAPack32 это не проблема, но как с другими контроллерами, применяющими RLL, FBD и другие средства разработки? Если не упаковывать, то страдает вместимость областей обмена, т.к. величина пакета обмена ограничена. Нужен компромисс, но для этого следует сформулировать правила. А ведь есть еще Windows формат DATETIME - удобно отсчитывать события и интервалы, просто складывая и отнимая FLOAT64.

2. Реализация типа STRING - что взять за основу? Cишный ASCIIZ или Pascal`евскую строку с байтом размера впереди? Вариант с ASCIIZ сейчас представляется более предпочтительным. Второе - какую кодировку брать базовой? DOS CP866, Windows 1251, KOI-8R, KOI-8U и т.п. Пока склоняюсь к Windows 1251. A может вообще использовать только транслитерацию?

3. Вводить ли поддержку BCD формата? Некоторые контроллеры без него жить не могут, может и программисты тоже?

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

 Отправлено: 10.06.08 12:40. Заголовок: Ответ #1 от Кондратьева Романа

Во первых, о типах:
Считаю благоразумным составить единую общедоступную таблицу с пронумерованным списком "душе угодных" типов (напр. до 256 шт).

1. на сколько плотно: думаю тут правильным было бы "узаконить" нестандартные подтипы DATE TIME, типа: TShortDate TDirectLogicData, TFloat64Date и т.д. а после воткнуть их на законных основаниях в уникальную таблицу..
1.1. PS таким образом можно вести реестр всевозможных сложных типов.
1.2. Предлагаю в контроллерах ввести структуру имеющую стартовую ячейку Начала Спецификации Буфера Обмена (СБО) устройства, а также Начала Данных Буфера Обмена (ДБО), а также их размеров в [Бт].. Таких структур можно в контроллере указать несколько следующих друг за другом (назовем их группы опроса).
Стартовая ячейка будет указываться в таких контроллерах как Direct, ScadaPack.. где сложно "двигать" этот базовый адрес и ячейка будет доступна для редактирования по месту на таких контроллерах (напр. RTU188) кот. могут этот адрес легко поменять..
1.3. Формат последующих за базовой ячейкой данных будет содержать метаданные, где каждый последующий байт будет содержать номер типа в таблице. Т.о. имеем четкую инфу о порядке параметров, их размеров, о типе (вид представления).
1.4. Непременно программист тут спросит, а как же узнать период опроса и названия параметров в таких метаданных?
Просто . Достаточно с устройством распространить файл конфигурации устройства для OPC-сервера. Там и названия, и адреса по-умолчанию, и группы опрашиваемые с разным периодом и типы всегда указываются..
1.5. Как сопоставить телеМеханику какой файл конфигурации от какого объекта автоматизации в поле? Хм.. ну тут думаю проблем не возникнет, если следующие за базовым адресом ДБО базисные данные будут содержать версию, дату билда и id разработчика)
1.6. Пример: на переферийный узел канала связи установили новый объект. Разработчик Верхнего Уровня (РВУ) дает команду телемеханики "инициализация", указав СБО и ДБО. В этот момент читается метаинформация с групп и запоминается в ТМ. Тут РВУ видит тип устройства, разработчика, зав. номер и прочее.. Подбирает файл конфигурации для OPC и смело подключает это устройство однозначно.

2. Почему бы не оставить все эти типы? TWideString TShortString, TASCIIString...

3. Почему бы нет? Заложить эту информацию в сам тип.. TBCDInt

4. Опять же это можно отнести к сложным типам.. TShortFloat16, TInt16Div10, TInt16Div100?

Не думаю, что метаданные будут слишком большой расточительностью, но даже если и будут, то всегда можно уйти к свободному формату для каждой версии устройства индивидуально - задав данные только в файл - конфигурацию для OPC..! :)
Другой вопрос захотят ли это реализовать зажравшиеся в собственных нотациях и спецификациях к чужим девайсам РВУ? )))

 Отправлено: 10.06.08 13:09. Заголовок: Меня интересуют огра..

Меня интересуют ограничения, накладываемые на использование типов кустовыми контроллерами и их средствами разработки, ну и конечно, контроллерами станций управления АГЗУ применительно к типам.

Метаданные вещь хорошая, но, прежде чем подцепится уникальная для АГЗУ часть данных, должна сразу и безо всяких изменений в ПО, поддерживающем разрабатываемый стандарт, заработать основная часть, т.е. поддержка некого абстрактного типа АГЗУ. А вот потом можно вычитывать метаданные и уточнять подробности, писать наверху поддержку всякого рода визуализаций и т.п. Но в это время уже должен работать обмен по стандарту и обеспечивать минимально-необходимый набор функций опроса и управления АГЗУ.

Вообще-то идея начальной точки обмена -адрес СБО, ДБО и т.п. уже заложена ( см. зона "Описание Установки" в тезисах).

 Отправлено: 13.07.08 18:53. Заголовок: Есть ли смысл придер..

Есть ли смысл придерживаться правила по выравниванию полей в Modbus структурах?

однорегистровые поля - не выравниваются;
двухрегистровые поля (FLOAT32,UIN32 и т.п.) - по нечетным номерам регистров (четным смещениям);

например, многие Modbus устройства не допускают обращение к двухрегистровым переменным по номеру регистра внутри одной пары, например, по номеру 1 лежит float32 переменная, тогда любая попытка чтения с адреса 2 вызывает исключение "Illegal address".

Кроме того, введение правила по выравниванию начальных адресов многорегистровых типов может положительно повлиять на переносимость исходного кода, написанного с использованием структур\записей\объединений и уменьшить количество ошибок, связанных с автоматическим выравниванием (alignment) полей сложных типов компиляторами.