Recent Posts

1

V_Buscom / Re: Modbus Data Blocks

« Last post by Cube on December 04, 2018, 08:47:26 PM »

It would appear that I've just somewhat recreated this post (though less eloquently.) Sigh. I guess it's good that I'm finally getting back around to it...

2

V_Buscom / Multiple RTU's, single Data Blocks

« Last post by Cube on December 04, 2018, 08:45:06 PM »

I am trying to build a bit of a monster. Or at least, something that could be very VERY cool. Part of this process sees me learning a lot about MODBUS. Indeed, I'd never really touched it before I started trying to write an interface for it. Now I have a specific need -- a problem to solve -- and it is starting to take shape.

Here's the situation.

I have a single modbus device that only accepts one TCP/IP connection. It has multiple data blocks (registers) that it maintains, and that I sometimes need to update. Presently this device (master) is being connected to by a third party client. I need that third party to be able to maintain it's connection to this device, but I also need to get a connection to it. What I have devised and am trying to implement is this: A kind of multi-connection modbus datablock architecture. Or, put another way, a Modbus Splitter.

Basically I will create my own datablocks in Buscom that will mimic the real ones in the master device. Then I will connect myself as a slave to that master and poll it's registers at the same interval as the original client did. I will then ALSO provide a master and point the third party to me instead of the original master, thus putting Buscom in the middle, but it will actually be serving it's data out of the same datablock that is being polled from the original master. Now I can connect potentially any number of clients to me and share this same data with them as they please. Using pthread rwlocks should ensure data integrity while allowing reads from a significant number of clients simultaneously. (Really, I only need one extra connection.)

Now for the tun part -- doing it!

3

V_Buscom / Re: The MODBUS Plugin Introduces a new Problem to the Plugin Architecture

« Last 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.

4

V_Buscom / The MODBUS Plugin Introduces a new Problem to the Plugin Architecture

« Last 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:

• Prefix all commands with modbus - IE: modbus rtu 1 show
• Modify the base object designation to allow multiple items separated by a delimiter - IE: modbus|rtu|datablock
• Something else?

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.

5

V_Buscom / Re: Asterisk Plugin Eyed on the Horizon

« Last post by Cube on May 17, 2018, 07:46:22 AM »

I thought I'd spend a few minutes outlining some of the features I'd like to implement with this Buscom Plugin.

• Incoming Calls enter Venturii as Events
• Ring Indicator, Voice Mail Waiting Indicator, Call Waiting Indicators all enumerate as VINTs that can be acted on from Decider and/or the web-based user interfaces
• Ability to initiate calls from Venturii / Decider / Web Interface

These are just a few of the things I have been mulling about, and I don't think it would take much to implement them - especially now with the plugin architecture of Buscom.

6

V_Buscom / Re: Modbus Data Blocks

« Last post by Cube on May 16, 2018, 07:37:17 PM »

The Plot And Problem Both Thicken

The Modbus slave driver (interesting function categorization) utilizes the modbus_mapping_t structure type to contain each of the four types of data it can process: bits, input bits, registers and input registers. Each of these point to a contiguous block of memory allocated of either uint8_t or uint16_t, depending on the bits or bytes parts. The way I have my data blocks set up, they need not necessarily be contiguous nor present necessarily. This creates a problem though, when I try to blend the two systems of storing these data types together.

Thinking It Through

Because I want to be able to have multiple slaves serve data off the same block, we have the conundrum of where that block resides. On the one hand I could create a modbus_mapping_t structure within the RTU structure of each virtual Slave RTU, and could cross-link other RTU masters with that block, along with the DataBlocks to pull the VINT data from them. Maybe a better solution is to create external modbus blocks. If I remove my concept of a datablock (which is really just a subset of the main block of data) and create raw blocks of data as the data blocks instead, we could point VINTs at them using the newly implemented value arrays. Imagine then, we create a datablock of, say, a thousand bits and a thousand bytes for each of the pairs of input and output coils and registers within our virtual RTU slave. Now we can point our modbus_reply() function to this block of data, or we can point multiple RTUs at it. Then, we create new construct - maybe called something like a Section, Tag or Subset - which contains a starting address and a length parameter, referencing one of our main blocks of data. This Section gets a single VINT for it's value, but it will make proper use of the array functionality of VINTs now that this has been implemented. We add a Device Status VINT for the entire section (since one is enough) and we have our access in and out of the global data blocks, satisfying both needs with efficiency!

 The one last piece of the puzzle is data concurrency; race conditions and how to prevent them. Since multiple virtual and/or real RTU devices may be accessing the same block of memory, how can we ensure only one uses it at a time, especially when the reply() function potentially blocks? We might be able to use 0 timeout values, gather up all the sockfd's from each RTU device and run them through our own select() call. For that matter, we might single-thread the entire modbus plugin, which would eliminate the need for the locks at all. Interesting. A little daunting, but very interesting...

7

V_Buscom / Asterisk Plugin Eyed on the Horizon

« Last post by Cube on May 16, 2018, 08:54:42 AM »

Last night I was reading through the API documentation for Asterisk, the free telephone service platform, and I believe there is a new plugin on the horizon for integrating with that system. Many (!!) years ago I set up an IBM XT computer with a Monochrome (green) display whose sole purpose was to open up a terminal, issue the AT+CID=1 command to a Hayes modem in one of it's many ISA slots and listen for the Caller ID data coming in off the phone line. Even then, it was perhaps overkill, but it was a rather convenient way to log incoming call history. Much later, early versions of Venturii had a Maestro module that provided similar logging of the call data, but also provided the ability to do things with this information by sending it to Decider. Thus we had a light that would flash whenever family called so we knew without having to get up if we should rush to answer the phone.

Now, having moved away from a land line and having a pure VOIP solution, my caller ID system still technically works, but I've had it in mind since the switch-over to integrate at an IP level to Asterisk itself. As it turns out, their AMI protocol (Asterisk Management Interface) appears to be just the ticket, allowing events to be reported through the connection and even calls to be originated and directed through this API. As with all things, it is only a matter of time now.

8

V_Buscom / Modbus Data Blocks

« Last post by Cube on May 16, 2018, 08:47:55 AM »

Originally my design was to have RTU devices own DataBlocks. DataBlocks are arrays of bytes which are either read from or written to by modbus commands. Each of these bits or bytes would have a corresponding VINT associated with it, and thus we could apply Venturii nomenclature to Modbus Remote Terminal Unit devices in a fairly sane way. This was all up and running and worked well, however as I've been working on this project my understanding of Modbus has grown and so too my desire to extend the functionality of this plugin even further.

The problem

We are integrating with a Modbus system that at present only accepts a single connection; subsequent connection attempts succeed but are immediately closed. When we disconnect the incumbent system, we can connect Buscom's Modbus plugin and interact with the Modbus devices through the connection, but this cuts off all access to the legacy system.

A Solution In The Works

I was talking to one of my colleagues about this problem, and he suggested we "Y-Connect" the TCP socket. Not a terrible idea, but because Modbus is a query/response system, it's not as simple to just cross-connect the thing like an NCC-1701 warp core. However the suggestion got me thinking, and the more I thought, the more I liked the idea that came to mind. What if, I thought, we open up the data blocks to more than one RTU device. We could even create slave RTU devices in the Buscom plugin, that would simply serve up data from one or more linked data blocks. In this way we could act as an intermediary between the existing Modbus equipment, legacy system, and continue to develop and interact with the hardware ourselves concurrently -- all on this same Modbus connection. In fact, this virtual data block could serve as an information for multiple RTU masters.

Using this topology we could shoe-horn the Buscom/Modbus plugin in between those systems. One RTU Master device would query the existing field hardware, update it's own copy of the registers & coils (stored in data blocks within the Bustom/Modbus plugin) and we would act as a slave to the legacy system which would poll [[us]] for updates. Our slave would serve up the correct coil and register data to the legacy host which would be none the wiser that it was talking to an intermediary now instead of the field hardware directly, and we can ourselves peek and poke at the data in situ.

9

V_Buscom / Lenel OnGuard Integrates with Venturii

« Last post by Cube on March 22, 2018, 05:30:56 PM »

Buscom now has a plugin to talk to Lenel OnGuard through DataConduIT. Of course, you need to buy a DataConduIT license from Lenel for your particular installation, but once you've laid out that chunk of cash, integrating your OnGuard Access Control System with Venturii is free. Here is what is presently supported:

• Venturii automatically generates DeviceIDs and appropriate VINTs for all the Readers, Inputs and Outputs in the OnGuard System.
• Reader Mode (Card Only, Locked, Unlocked, Card And PIN, PIN or Card, etc.) enumerates as a VINT with a source of Reader Mode.
• Door Forced Open, Door Held Open, Door Forced Open Masked, and Door Held Open Masked annunciate as separate VINT Sources with the same names.
• Access Control Doors can be opened from Venturii by sending a Desired Value of 1 to the corresponding "Open Door Command" VINT source.
• Input status from all Reader Inputs and Alarm Panel inputs enumerate as a VINT.
• Input Masked Status of all Reader Auxiliary Inputs and Alarm Panel Inputs enumerates as a VINT with a source Masked. Setting the desired value of this VINT will control the Masked state of the corresponding Input.
• Output status from all Reader Auxiliary Outputs and Alarm Panel Outputs enumerate as a VINT. Setting the Desired Value of this VINT controls the output (0=De-Energize, 1=Energize, 2=Pulse).

More features are coming soon! This means that you can use any of the web-based user interfaces to view the status of various points within your Lenel OnGuard Access Control System, or you can create new ones with the new User Interface System, code named ProximaVenturii. More details on that will also be coming soon!

10

Decider / Re: New Feature - TORX Time Definitions

« Last post by Cube on February 20, 2018, 04:18:07 PM »

I saw this topic here and wanted to give some feedback on it, mostly for posterity. This feature I use every day, and is probably one of the best features within Decider's time management system. I have it automatically turning off all the lights in the house after everyone's gone to work, I have it acting as a thermostat for my garage with some calculations and comparisons, I have it watering the lawn, gardens and hanging planters at the correct times and with the correct amount of water - it is a VERY versatile feature!