I am currently working on building a module for an Apache IoTDB-based Tag-Historian module. However I am completely new to Ignition and struggling a bit with some of the concepts (Like I have to add my S7 devices in the OPC-UA server etc.)
Now I thought: I think I have something to bring to the table: Drivers
Apache PLC4X we currently have drivers I couldn't see in the default installation:
ADS/AMS (Beckhoff)
CAN
CtrlX (WIP)
EIP
Firmata
IEC-60870
KNXNet/IP
Profinet (WIP)
Umas (WIP)
I think there would be quite some benefit if I porvided an open-source PLC4X module.
So would someone here be willing (within the next 2-3 days) to give me a quick walk-through and help with the questions I have? Ideally that person should not only be proficient with Ignition as a user, but also as a developer for developing modules.
Haven't heard of that, will have a look, but I doubt it will help too much, as I'm currently struggling with code-level problems ... trying to build a custom Historian Module based on the existing one ...
I'm currently not trying to build a driver integration module ... that's on my todo list
I'm trying to build a Tag-Historian module that allows sending data to Apache IoTDB.
In order to do so, I've setup a maven project and build that correctly builds and even signs my artifacts and I can easily deploy them to Ignition.
I'm struggling a bit with what makes a Tag-Historian module a Tag-Historian. At first I simply included the ignition TagHistorian in my own one and started with my own classes referencing some of the tag-historian-4.1.18.jar types ... however this module seems to contain various different implementations of a tag-historian which however share some concepts and some code.
I would like my module to not have this dependency, but to implement the parts needed myself. Unfortuantely, I'm totally lost as stuff like this:
How do I tell Ignition that I have a tag-historian module, so it's listed in the Tags/History section?
How do I set things up that I am able to have data sent to my historian?
I guess none of this is covered in the training videos.
Your gateway hook class is handed a GatewayContext object during its setup() call. You need to capture this object for later use, but also immediately use it to tell the gateway was services (extension points) you wish to provide. In this case, you will need to register your historian via context.getTagHistoryManager().addTagHistoryProviderType(...). Your provider type will then supply critical information about its capabilities, and will identify the persistent record type you will use to carry your implementation-specific configuration information (target IoTDB urls, whatever).
As you dig around, you will discover the need to also register a HistorySink when your provider is created.
(I've been poking around at this. Parts of it are fairly opaque, still.)
N.B: This is an instance of the "extension point" pattern we use a lot, covered briefly here:
Note also that while the concept of extension points will stick around in 8.3.0, the entire implementation of them is going to be totally different. I'm going to be saying that a lot - much of what's happening in 8.3.0 is going to be totally different "under the hood" and less visible to end users.
As for your actual historian implementation, it's going to be complicated.
I really can't stress this enough - this whole subsystem is rife with technical debt and is (in my opinion) overengineered. It's in the process of being rewritten dramatically (for 8.3.0) with the explicit goal of ease of maintenance and implementation by third parties.
Many things you might want to do with a custom historian are essentially impossible right now. For instance (as far as I know), all aggregation functions are performed by the gateway - you can't delegate them out to the probably much-more-efficient timeseries DB you might want to connect to.
thanks for this info ... it confirms, partially what I have already seen, so that's at least partially good
I just took a step back and trying to implement something with a clean project with no relation to the tag-historian.jar. Also just installed a fresh and new Ignition instance with minimal installation ... trying to add back stuff (I think I completely ruined my installation with my first approach).
I forwarded your concerns to my boss ... but when I first did that, he just said: But our customer uses Ignition 8.1. So I guess I'll continue learning things and hope that I'll manage to get at least something sort of working.
Right now I noticed with simply registering the historian history provider ... where would I then see anything added to Ignition? I was sort of expecting the "Settings/Tags/Historic Tags" (Not quite sure what it was named, as it's now not being displayed) to come back, but I guess there'll have to be a bit more happening for that to work, right?
If you used my code snip, you would then have your custom historian available in the list of historian types when creating a new historian through the web interface. The web interface would include your persistent record's fields in the following configuration page automagically.
Ok ... so I guess I was on the right track ... just I did one thing wrong:
I thought the "Tag Historian-module.modl" was the implementation of the In-Memory and the SQL Historian and in order to work with a clean installation, I didn't add that module. Turns out it seem to contain not only some implementations, but also the core framework for historians. As soon as I added the module back, I got the Tags/History and inside that I could see my provider.
Yup ... also had the "systemManaged" set to true, which had the element disabled in the dialog, but now I see my new type and hope I'll be able to continune.
These questions aren't stupid at all. In fact, since Module Development isn't officially supported by IA, and digging through the SDK can be....overwhelming and sometimes convoluted...posts like this are a top tier resource.
