ruby-on-rails - Modbus 记录器进入数据库和数组处理策略

Question

我发现使用 modbus 读取 64 个连续的内存位置(元素)是使用 rmodbus 库通过 Modbus 检索信息的最有效方法。

我的目标是将读取的信息记录在一个简单的数据库中，可以挖掘该数据库以在网页上生成数据图表，并将最新值存储在实例变量中。

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 并与自身比较更改，然后仅记录已更改且已被要求记录的元素。元素可能应该存储在 db 和已经缩放的变量中，这样前端就不必担心了。未记录的那些仍然保存在实例变量中，用于半实时抬头显示类型监视。然后，仅当 UI 请求时，才会对事件表中记录的元素进行图形和表格解析。

第一个问题:(终于!)使用数组中的数据并应用处理转换索引的层是否更有意义，(并且碰巧相应的元素值作为好吧，我使用 v.collect{|i| i.to_s(16)} 进行转换)还是最好将所有内容都转移到一个 Hash 中，这样索引和值就可以从此快乐地生活在他们的最有用的形式？

第一个问题编辑:鉴于我的问题的确定/演变方向是仅将数据中的更改记录到一个简单的 sqlite 数据库中，并且我将需要跟踪元素的更改以确定哪些元素在 modbus 读取之间发生变化，数组或散列是否更有效地进行比较？我应该关心吗？

第二个问题:在 Rails 中，假设记录间隔为一分钟，将大约一千个数据点保存在独立字段中会更好，还是我应该将它们保留在 64 个元素 block 中并解析信息正在前往界面的路上？

第二个问题编辑:将大量未更改的数据运行到数据库的一分钟“行”中似乎非常平坦。另外，它不允许轻松动态选择要记录的元素。使“记录器”基于事件而不是基于间隔似乎更合适。这很好地意味着第一个问题在这里更重要，因为它也可能成为状态检查机制。

我猜我是在不必要地重新发明一个带有那个启示的轮子，因为它变得很像现有的“记录器”。阅读 SO 表明，登录数据库与 FS 是一个古老的问题。由于日志本身是应用程序的基础，因此我倾向于登录数据库，根据我的阅读，很可能是 sqlite。

第二个问题再次编辑:现在是规范化的问题，我正在阅读的所有内容都表明“可扩展性”往往需要非规范化。我记录的“事件”表将相对简单，时间戳、值和元素 ID。它是否也应该对 Elements 表内部最常见的属性进行非规范化，或者在这个相对较小的规模上是否可以连接？

有人喜欢 Ruby 日志框架/gems/bundles/plugins/whatever 吗？

Answer 1

我不认为这个问题在其他地方得到了回答 :) 你可能是 SO 上唯一使用 Rails 和 Modbus 的人。我有 Rails 和 Modbus 经验，除了我的 Modbus 经验是在 .net 紧凑框架上使用 nmodbus。我不知道我能为您提供任何明确的答案，但我可以分享我使用的方法。

当我们轮询设备时，我们会立即对数据应用任何解析、缩放或转换(但我们没有 1000 个值)。然后将数据记录到数据库中。现在任何想要使用数据库的客户都不知道 modbus，他们也不关心；问题从了解 modbus 转移到应用程序真正关心的内容(电压!)。在您的场景中，我会尝试将此轮询应用程序与您的 Rails 应用程序完全分离。

现在为什么不可能解耦 - 1000 个数据点。那是个问题。出于争论的考虑，即使您能够将此数据规范化为 50 个表，那也是 50 个表，每个表有 20 列……糟糕。我不知道有什么简单的方法可以记录 1000 个数据点，但构建基本上是持久哈希表的方法可能行不通。

要求 Rails 知道如何解析寄存器值的坏处在于，现在您的 Rails 应用程序已经了解 Modbus(不是在读取寄存器级别，而是在解析级别)。此外，如果您想使用 Rails 以外的客户端，该应用程序也需要解析知识。也许这就是您的 Rails 应用程序的全部意义所在？ Rails 应用程序知道如何对 Modbus 读数进行切片和切 block ，并为用户/客户提供一个很好的 UI/web 服务来使用。

这些都是很好的问题，但如果不进一步了解您正在构建的内容，就很难给出具体的建议。至于规范化 - 反复试验。两种方式都试一试。我不能说诸如“如果你的 sqlite 表中有超过 40 列，它就会分崩离析”之类的话 - 你只需要遇到这样的话......