Я обнаружил, что чтение 64 смежных областей памяти (элементов) с использованием Modbus является наиболее эффективным способом получения информации по Modbus с использованием библиотеки rmodbus.
Моя цель - записать информацию о прочтении в простую базу данных, которую можно добывать для создания графиков и таблиц данных на веб-странице и сохранять самое последнее значение в переменной экземпляра.
данные считываются в массив библиотекой rmodbus, где индекс каждого элемента представляет адрес элемента.Тем не менее, я хотел бы преобразовать индекс в восьмеричное значение, так как это соответствует схеме адресации элементов, с которой пользователи уже знакомы, и было бы легче ссылаться в интерфейсе.
редактировать, добавлять детали и уточнять : В данный момент я работаю со следующей схемой:
create_table "elements", :force => true do |t|
t.string "name"
t.integer "modbus_connection_id"
t.string "address"
t.string "eng_unit"
t.integer "base"
t.string "wiring"
t.text "note"
t.boolean "log"
t.datetime "created_at"
t.datetime "updated_at"
end
create_table "events", :force => true do |t|
t.integer "element_id"
t.string "value"
t.datetime "created_at"
t.datetime "updated_at"
end
create_table "modbus_connections", :force => true do |t|
t.string "name"
t.string "ip_address"
t.integer "port"
t.integer "client"
t.text "note"
t.datetime "created_at"
t.datetime "updated_at"
end
Идея состоит в том, что фоновый процесс, вероятно, будет опрашивать Modbus и сравнивать себя для изменений перед регистрацией толькоЭлементы, которые были изменены и были запрошены для входа.Элементы, вероятно, должны храниться как в БД, так и в переменных, которые уже масштабированы, поэтому интерфейсу не нужно беспокоиться об этом.Те, которые не зарегистрированы, все еще хранятся в переменных экземпляра для мониторинга типов отображения полу-в реальном времени.Затем зарегистрированные элементы в их таблице событий будут анализироваться для графиков и таблиц только по запросу пользовательского интерфейса.
Первый вопрос: (наконец-то!). Имеет ли смысл жить с данными в массиве и применять слой, который обрабатывает преобразование индекса (и, как это происходит, соответствующий элемент?)также значение, которое я использую v.collect{|i| i.to_s(16)} для преобразования) или лучше перенести все в хэш, где индекс и значение могут жить долго и счастливо в их наиболее удобной форме?
Первый вопрос edit: Учитывая решение / эволюцию моего вопроса в сторону регистрации только изменений данных в простой sqlite db, и что мне нужно будет отслеживать изменения для элементов, чтобы определить, какие из них изменились между чтениями Modbus, выполняет ли массив или хэшсделать сравнение более эффективно?Должен ли я вообще волноваться?
Второй вопрос: В Rails, принимая во внимание интервал регистрации в одну минуту, будет ли лучше хранить около тысячи точек данных в независимых полях, или я должен оставить их в64 элемента фрагментов и анализ информации о пути к интерфейсу?
Редактирование второго вопроса : Запуск большого количества неизмененных данных в одноминутный «ряд» базы данных кажется очень плоским.Кроме того, он не позволяет легко динамически выбирать элементы для регистрации.Казалось бы, гораздо более уместно делать события «регистратора», а не интервалы.Что довольно неплохо означает, что Первый Вопрос здесь более важный, так как он, вероятно, также станет механизмом проверки состояния.
Полагаю, я без необходимости заново изобретаю колесо с таким откровением, как этостановится очень похоже на существующие «регистраторы».Чтение вокруг SO показывает, что это старый вопрос о входе в БД против FS.Поскольку сам журнал является основой приложения, я склонен входить в БД, скорее всего, из-за прочитанного.
Второй вопрос снова отредактирован : Теперь это вопрос нормализации, все, что я читаю, говорит о том, что для «масштабируемости» требуется денормализация.Моя зарегистрированная таблица «События» будет относительно простой, отметки времени, значения и идентификатор элемента.Должен ли он также денормализовать наиболее распространенные атрибуты из таблицы «Элементы» или объединение нормально в этом относительно небольшом масштабе?1037 *