Venturii Forum

Venturii Software => V_Buscom => Topic started by: Cube on December 03, 2018, 01:47:49 PM

Title: The MODBUS Plugin Introduces a new Problem to the Plugin Architecture
Post by: Cube on December 03, 2018, 01:47:49 PM
I was very excited about the new plugin architecture. It was going very well, and several of the more "built-in" modules had been successfully converted to full blown standalone ones without much ado - including Lenel OnGuard's plugin and the one I'd created for talking to Simplex panels (well, listening to would be nearer the mark.) I started attempting to rebuild the MODBUS module as a plugin, and then decided to try to bring as much of the original code over as possible. That, however, is when I ran into the first new snag in this plugin architecture. The Base Object Name.

In Buscom, you have some core functionality that is accessed by top level items through vterm (the command line interface) such as channel or xmq. When you load a plugin, the plugin adds it's own base object as part of the linkage process, so that buscom's command handler knows what commands to pass on to the plugin's command handling routines. In the past, these have all been single items, but with the modbus module, I had designated multiple top level objects, including rtu and datablocks. This presents a problem, since you can at present only have one top level base object name.

There are a couple of ways to work around this:

Personally, I am leaning towards the second option because it keeps in line with the rest of Venturii's norms, and offers the most flexibility for this and future plugins. It does, of course, require modification to the buscom code itself to strip out and parse the multiple base object names, but that is minor and trivial, really. Good. I'm glad that's settled.
Title: Re: The MODBUS Plugin Introduces a new Problem to the Plugin Architecture
Post by: Cube on December 04, 2018, 02:45:16 PM
... So I implemented the multiple base object name feature, tested it, got it all 100% and then realized that the modbus command handlers were already designed to be prefixed with modbus on every command (so basically option number one.)

In any event, we've added a new feature to Buscom that could be useful down the road.