Request for comments/ideas (need versatile software & electronics controllers)

[ArticCynda]

Hi everyone,

I'm in the design phase of an automation project, in which my team will be in charge of the control electronics and software, and another team will be doing the mechanical design. Due to time, budget, and resource limitations, electronics, software and mechanical design must proceed in parallel with each other because the deadline is rather short. This means my team will need to start designing electronics before the mechanical systems are completely designed, hence without knowing which inputs must be processed and which actuators must be controlled.
What is known at his point in time, based on a previous design iteration, is that a small number (ca. 5 to 10) of low power DC motors (12V, < 20W) will need to be controlled, along with one or two stepper motors, and several actuators at 230V AC. There are also a variety of inputs to process, including mechanical switches and magnetic proximity switches.

Because the control (= software) side of the project is a relatively simple state machine, a small microcontroller such as an ESP32 will suffice.

The question is, how can the microcontroller be interfaced with a number of actuators and inputs in a modular way, when the exact number of actuators and inputs is not known during design phase?

In the previous iteration of the project, we ended up with a hugely complex contraption of I2C IO expanders and an impossible cable mess to solve the problem for the proof of concept, which we absolutely wish to avoid. We can't use a PLC based solution, and also don't want to end up stacking Arduino style or RPi style shields/hats on top of each other!
Instead, we're considering options such as a custom back plane PCB where modules for different actuators and inputs can be clicked in as needed, but have not decided on what such a back plane should look like nor what its communication protocol should be. Perhaps there are other solutions which we haven't thought about yet.

We welcome any suggestions, comments, and ideas!

Best regards,

AC

 

[andre_luis]

Because the control (= software) side of the project is a relatively simple state machine, a small microcontroller such as an ESP32 will suffice.

I had an unfortunate experience using the ESP32 with strict interrupt-based timing requirements in the Arduino platform; for some reason the ISR does not handle well with the Wifi library in the intrinsic RTOS of the Arduino. Since you mentioned a stepper motor, it reminded me of a case where I had to control electro mechanical actuators on a bagging machine with resolution in the range of 50-100ms. On the other hand, developing the programming directly in baremetal compiling with ESP-IDF would be a painstaking task. I recommend making a list of your requirements/constraints and sharing it here so that we can give more accurate insights of your .

 

[danadakk]

Possibly a SOC based solution, where you can expand, or contract, easily, both analog and digital
interfaces.

Here is whats on the SOC, multiple copies in many instances :

Regards, Dana.

 

[dick_freebird]

A mature system development would maintain a set of ICDs
(Interface control document) to ensure that such efforts have
an agreed-upon set of constraint, goals, standards etc.

For example you might both work on defining a limited set of
connectors that both the electrical and mechanical camps find
acceptable,

 

[KlausST]

Hi,

I2C first came to my mind ...

But the more I read I think an SPI based backplane may be more suitable.
I currently use SPI with 8 members on the ESP32.
3 hardware lines (ports) are used as address fed to a HC138 in combination with the standard /SS line.
So you get 8 individual /SSx lines for 8 slots. (Or 4 slots with 2 /SSx lines)
Every time before I want to communicate with an SPI member I call a small function that sets
* the address lines
* SPI speed
* SPI mode
If you need more adresses, then I recommend to feed them as binary lines on the bus, so every member may use these "sub adresses" or not.
(Somtimes a small SPI EEPROM per card is useful for: card ID, calibration data, maintenance data....)

It depends on wiring (length, connectors, capacitances, ..) whether you need drivers on the SPI lines.
If you want to improve the bus regarding EMI/EMV you may use LVDS (or RS485) differential signalling. (Not needed for the /SSx lines)

Klaus