- В этой теме 10 ответов, 3 участника, последнее обновление 1 год, 11 месяцев назад сделано
.
-
Записи
-
В общем забил я на время — пусть пользователи заботятся 🙂
И я опять немного за старое 🙂Строки и Время (добавил и не только время)
Мне тяжело разбираться с исходным кодом и кучей ветвлений, просто выскажу свое предположение, а вы подумаете.Есть основная БД, где каналы хранятся в double. И если у нас тип данных строка, то она обрезается до 8-ми байт ascii автоматом. Чтобы вывести всю строку надо сделать массив, ну и применить различные формулы для ее сохранения в массив.
Если у нас Время (DateTime), то мы его должны самостоятельно привести к double.
У каналов есть ID но не от 0 до окончания INT а можно задавать любые значения.
И все механизмы системы так понимаю взяв данные канала сперва обращаются так или иначе к ячейки Форматы чтобы правильно потом отобразить.
Ну в расчет не берем RapidGate, который может не думая перегонять данные, или еще какие-то модули. (Наверное вот тут будет затык)Если добавить в Форматы тип Object и для Строк и таких вещей как DateTime просто создать свои параллельные БД с зеркальными ID каналов основной базы ?
По идее может получиться даже в рамках 6-й версии.Зато в БД Object можно сохранять не только DateTime, но и его же вместе с TimeZone, потому что в объект так понимаю можно запихнуть и object[] где первым будет непосредственно DateTime с сохранением Kind свойства, а во втором TimeZone передаваемого времени. А так же в object можно запихивать и структуры и хоть черта лысого. Ну будет ограничение на длину байт объекта и строки для этих БД.
Но уже хоть что-то.
з.ы. Всего лишь идея, не знаю, насколько она реализуемая в рамках именно 6-й версии, но вроде как и концепция общая не пострадает.
Много букав. Не читал. У меня вообще была идея, чтобы строки хранить в Alarm или событиях. Так сороковая переменная есть. ?
Но просто данные как строка это не обязательно Alarm или событие. Их придется как-то их там игнорировать.
з.ы. вообще в рамках например 7-й версии я бы рассматривал не реляционную БД а Графовую. Там есть пару преимуществ для работы Scada систем. Это изначальные связи (Объект, Устройство, время и т.д.) и главное разные типы данных и разное их количество.
А. Из опыта работы с Historian. Там тоже можно хранить строки. Но хранят в отдельное таблице и представление два типа данных, где строка берётся из отдельной таблицы. То есть в первом столбце будет Double, а во втором строка. Если строки нет, то там Null.
ну я этот вариант и предлагаю для версии 6. Строки и Объекты хранить в отдельной таблице.
Можно даже например если Строка — то пихать ее в туже таблицу Объект.
Всего одна доп таблица появится. Зато с временем и структурами будет проще, что увеличит функционал даже в рамках 6-й версииЕсли появится описанная выше база данных, то также потребуется доработать под неё API архивов и TCP-протокол обмена между Сервером и приложениями-клиентами. Далее потребуется изменить web API. То есть изменения пойдут по всей цепочке, причём в обе стороны. Станет сложнее и медленнее.
Пока не появится новый отлаженный редактор схем, а также веб-Администратор, подобные изменения точно не перевесят по приоритету.
@Mikhail я не спорю про приоритету, Редактор схем сейчас важнее, как и Администратор.
Я пишу это больше как идею, а вы свое творение знаете лучше всех. И можете примерно прикинуть что и где придется менять и вставить в новый Редактор и Администратор в коде заглушки сразу, под реализацию идеи в дальнейшем. Чтобы и новый Редактор и Администратор потом не пришлось переписывать.
В общем работа со временем для RapidScada это боль.
Сервер UTC, все остальное это «когда рак на горе свистнет».+ 1-2 расчетных канала для отображения и вычисления разницы со специальными формулами, полностью возложенными на пользователя.
Например при обмене временем между модулем, сервером и Web.
При чем преобразование введенного времени со стороны web сразу к UTC приведет к противоположному эффекту при передаче команды в модуль из-за отсутствия информации о том, какое это время и какая TimeZone была со стороны web.з.ы. Альтернатива для версии 6.
1. научить Web отправлять время не только в виде строки со стороны клиента но и в виде массива байт. Пользователь сам выбирает в настройках.
09.09.2024 0:36:00 — тут всегда больше 16 байт
2. Если передача массивом байт, то достаточно 16-ти байт, два раза по double, первое это LocalTime (клиента) в double, второе это UTC time
3. В каналах делается массив длиной 2, Формат Дата и время, Дата, Время
Узнать разницу во времени между двумя датами не проблема. Нарушений структуры БД не будет. Переделок минимум. Определять команду CmdDataStr или CmdData для формул вроде не проблема. Позволит определять временную зону клиента. А так же между серверами.
- Для ответа в этой теме необходимо авторизоваться.