Automatic Module Detection and Configuration on Revolution Pi

[martin_lf_work]

Hi Revolution Pi community,

I'm working on a project where I want to leverage the Revolution Pi system’s expandability and industrial I/O modules. My goal is to create a product with a unified interface that users can interact with entirely through my application, avoiding the need for them to manually use PiCtory to arrange and configure I/O modules.

I noticed that Revolution Pi is capable of detecting which modules are connected and where, as described in the PiBridge article. However, it seems that this detection process is only used to compare against the configuration file, and if there is a mismatch, the system goes into an error state. What I’m wondering is, why can't this automatic detection be leveraged to configure the modules? It seems like an opportunity to make the system more user-friendly and avoid some of the manual configuration in PiCtory.

My end goal is to generate the configuration file automatically through my application, allowing users to simply connect modules without having to open PiCtory or manually arrange anything. This way, I can present a seamless experience to the user within my application. Is there any documentation or guidance available on how I can generate the necessary configuration file programmatically? I’d like to avoid reverse-engineering PiCtory and the config files, so any help in this direction would be greatly appreciated.

Thanks in advance

[u.biakoup]

Hi martin_lf_work ,

Thank you for reaching out! You're absolutely right—there is indeed a great opportunity to make the Revolution Pi system even more user-friendly by automating the I/O module configuration process. The good news is that the source code for Revolution Pi is open and available, which can help you achieve your goal without needing to reverse-engineer anything.

You can find all the necessary source code and documentation in our GitLab repository here: Revolution Pi GitLab Repository. This should give you access to everything you need to programmatically generate the configuration file and integrate it into your application.

By diving into the repository, you'll be able to understand how the PiBridge works and how the system handles configuration files, allowing you to automate the process and provide a seamless experience for your users.

Best Regards

Ulrich Kouatang Biakoup | field application engineer

[martin_lf_work]

Hi Ulrich,

Thank you for your response.
I appreciate the suggestion to look at the GitLab repository, but I've run into a few roadblocks while trying to locate the source code for PiCtory or any detailed documentation regarding the generation of configuration files. Specifically, the Documentation folder in the repository is empty, and I haven't been able to locate the source code for PiCtory itself.
The closest I got to PiCtory was the URL in the cockpit source code, so I know that it's hosted on port 41443 and written in PHP.

I've been primarily investigating the piControl repository since I know it interacts with the configuration file and reads the JSON data. From what I've gathered, the configuration file contains an array of devices with fields such as productType, position, offset, inp, out, and other device-specific configurations (like debounce time, PWM, etc.). I've managed to deduce part of the structure, but I'm still missing some of the exact values, particularly around fields like offset and productType.

Here’s an example of the structure I’ve been working with (including some notes I've made along the way):

Code: Select all

{
    // The Devices array contains a list of physical devices to be configured
    "Devices": [
        {
            "productType": 1, // Identifies the device type (e.g., DIO, DI, DO), exact value is unknown but between 1 and 12288
            "position": 32, // Address of the device, example value for the first module
            "offset": 0, // Memory offset, exact value is unknown
            "inp": { "sensor1": "active", "sensor2": "inactive" }, // Input configuration
            "out": { "motor1": "on", "motor2": "off" }, // Output configuration
            "config": { "debounce": 10, "pushPull": 1, "pwm": 5 } // Additional device-specific settings
        }
    ],
    // Connections define logical links between devices
    "Connections": [
        {
            "srcGUID": "device1-guid", // Source device ID
            "srcAttrname": "sensor1", // Input from source device
            "destGUID": "device2-guid", // Destination device ID
            "destAttrname": "motor1" // Output to destination device
        }
    ]
}

While this gives me a general idea of the structure, reverse-engineering C code to figure out the exact configuration format is proving to be quite time-consuming, so any additional documentation, or pointers to specific repositories in the GitLab that could help me figure out the exact structure and values, would be a huge help.

Thanks again for your guidance, and I look forward to any advice or insights you can provide.

Best regards,
Martin

[martin_lf_work]

Hi Ulrich (u.biakoup), I just wanted to follow up on the discussion we had a few weeks ago. Have there been any updates on this topic? I’d really appreciate any additional guidance if available.