PLUS+1 User Forum

PLUS+1 Tools => PLUS+1 GUIDE => Topic started by: Lukey on August 28, 2025, 03:26:10 AM

Title: A system with multiple controllers - GUIDE project architecture
Post by: Lukey on August 28, 2025, 03:26:10 AM
How do others go about managing multiple controllers for the 1 system?

Typically for a system with multiple controllers I have a GUIDE project for each controller, this is difficult to manage.
When we can use the IO modules we do so, but they do not always suit.

I thought using MODULES in a guide project would allow multiple controllers however this is not the case.

Is their an easier way?
Title: Re: A system with multiple controllers - GUIDE project architecture
Post by: Fredrick on October 03, 2025, 10:07:19 AM
In multi-ECU systems, I typically designate one ECU as the primary controller, while the remaining units operate as distributed I/O modules. The control logic resides entirely within the primary ECU and is communicated via CAN to the secondary ECUs
Title: Re: A system with multiple controllers - GUIDE project architecture
Post by: Matt on October 06, 2025, 05:03:53 PM
When we can use the IO modules we do so, but they do not always suit.

I have also been creating a GUIDE project per ECU, then writing CAN TX/RX to communicate among them.

I'm curious what the additional controllers are providing that the IO modules don't already provide. Is it just a need to distribute logic? So far I've tested one MC and several IO (combination of IOX and OX) and didn't seem to hit a roadblock that would require a controller instead of an IO module.

In multi-ECU systems, I typically designate one ECU as the primary controller, while the remaining units operate as distributed I/O modules. The control logic resides entirely within the primary ECU and is communicated via CAN to the secondary ECUs

In the case of a controller, a display, and IO modules, I've taken a similar approach. However I have found it tedious to write the CAN messaging between the controller and display whereas the IO modules come with that already included.
Title: Re: A system with multiple controllers - GUIDE project architecture
Post by: Lukey on October 07, 2025, 02:06:47 AM
I have had to use controllers when using some library blocks that only work with controllers.
1 example was a Danfoss orbital motor rotary sensor, the feedback i required from the input was the .per, which from memory is time between pulses, this function is not available on the expansion modules.

My program architecture is to always have 1 master/controller and the rest of the modules being of first preference expansions or else controllers(via rx/tx) that are simply remote I/O.

The issue i have is having multiple controllers requires multiple projects, this is tedious, I was hoping for a better way.
I thought the Modules feature of GUIDE would address this, however i have yet to find a practical application where i would implement different Modules in 1 GUIDE project.
Title: Re: A system with multiple controllers - GUIDE project architecture
Post by: Marbek_Elektronik on October 20, 2025, 09:19:13 PM
Yes, I see it exactly the same way.
Unfortunately, you have to program multiple projects, and you can't establish a connection between them in the Guide.
Only in the service tool can you access everything together.
Sometimes I work with two computers: On one computer, I program the display, and on the other, a controller.
Usually, the display is the master and sends commands to a controller to set outputs or even rewrite EEPROMs or query inputs, etc.
For fast processes, I like to offload the software to the controllers.
Title: Re: A system with multiple controllers - GUIDE project architecture
Post by: samuelhj on October 21, 2025, 06:40:02 AM
Yes, I see it exactly the same way.
Unfortunately, you have to program multiple projects, and you can't establish a connection between them in the Guide.
Only in the service tool can you access everything together.
Sometimes I work with two computers: On one computer, I program the display, and on the other, a controller.
Usually, the display is the master and sends commands to a controller to set outputs or even rewrite EEPROMs or query inputs, etc.
For fast processes, I like to offload the software to the controllers.

What I usually do is I have an excel file with commands listed over CAN and then have multiple guide files, each for each controller, there really isn't an easy solution to this AFAIK. It quickly turns into a logistical nightmare. Creating some flowcharts in draw.io helps with keeping my head sane when doing projects like this to memorize CAN nodes addresses and such. The only way to test this is as previous commenter made about using the service tool and hooking up a workbench to test the whole setup.
Title: Re: A system with multiple controllers - GUIDE project architecture
Post by: Marbek_Elektronik on October 21, 2025, 07:52:24 PM
I have had projects with DP700, MC050 and MC024.
When I close one sub-project, I save the scs file of the project.
So, I can oben it in next poject and look and copy from oter project.
And yes, I copy also a table with can-comunication-messages from one project to another.
So, 3 controllers are easy to manage.
Title: Re: A system with multiple controllers - GUIDE project architecture
Post by: Rem on October 22, 2025, 07:56:36 AM
[...]
When I close one sub-project, I save the scs file of the project.
[...]

Hello,

I do the same thing. Then, I open the SCS files on a second screen. This way, I can browse through the program and check that the CAN messages match.

Another great feature is listing the CAN messages received and sent by each control unit in the programs by creating subpages. This allows you to see the source or destination of a message at a glance.

Have a nice day.