Hier stimme ich dir zu, daisy chaining ist beim MCP23S17 erstmal nicht vorgesehen.
Habe auch KA, ob das funktioniert.
Ja, so ist es richtig.
Dann kommen wir zu dem Punkt mit den SS und /CS Pins.
Da wo ich Einspruch erheben muss.
Wenn jeder MCP23S17 seine eigene Adresse bekommt, dann können sie sich einen Pin dafür teilen. Also alle an SS dran....
Hallo,
im Schaltbild is zu sehen das die MCP23S17 Adressen beschaltet sind und zwar mit 0,1,2,3. Deshalb sind auch alle paralell am HSPI des ESP32 beschaltet und nur ein SS
Welchem Schaldbild?
im diesem siehe #11
hi, STEP und DIR sind richtig es ist kein Schrittmotor sondern ein Servo-Treiber (AASD-15A) für einen closed loop AC Motor. der ESP muss das DIR als auch die STEP Signale erzeugen.
Ich habe auch einen Interim Schaltung gebaut, mit ESP32 1x MCP23S17 über SPI mit nur 2 CYT Level Shiftern dran. Diese funktiioniert auch mit 6 Servo-Treiber (AASD-15A) jedoch nicht für eine linear Antrieb wie beim geposteten, 4 Kanal Arduino Controller sondern nur in einem Winkelbereich von 60 Grad (rotary stewart prinzip) nach Homing. Das war nur zum "proof of concept"
und hier ist auch der funktionierende Sketch dazu.
6_kanal-Controller.zip (56,4 KB)
Ja, die LED am ESP blinkt, ich kann den compile-ierten Sketch hochladen, und über den seriellen Monitor Sachen auslesen, wenn ich z.B. den in der Aurdino IDE stehehnden Wifi Scan hochlade.
Das ist mein dritter Controller, aber jedoch der komplexeste bisher.
ich habe auch die Schematas und die Sketches der beiden vorhergehenden unten mal reingeladen, ich habe als Base Sketch das von meinem 6-Kanal ESP32 Controller genommen.
Ja es ist vielleicht nicht der optimalste Sketch aber das was da ist im DIY und im autodidact Modus entstanden.
In Büchern wie "Learn ESP32 with Arduino IDE" von Rui Santos , wird beschrieben und drauf hingewiesen sich die EEPROM.h wie beim Arduino auch beim ESP32 zu nutze zu machen.
Geregelte Position, vermute ich mal.
Dann ist das aus Sicht des ESP ein Schrittmotor.
Ja, aber mit weiteren Funktionen wie torque level und servo ready und enable und fault abfragen
EEPROM.h ist am ESP32 als deprecated gekennzeichnet.
https://github.com/espressif/arduino-esp32/tree/master/libraries/EEPROM
Mach hier keine weitere Entwicklung am ESP32.
Baue vollständig um auf preferences.h
Zum Rest kann ich nicht viel schreiben. Der Sketch im ZIP file ist meines erachtens unvollständig und kann auch mit Nachinstallieren von öffentlichen Libraries nicht kompilieren. Insofern hätte ich die Frage, was konkret du nun noch geklärt haben möchtest? Kannst du einen Sketch machen der genau dein Problem zeigt und alle Abhängigkeiten enthält damit wir dein Problem nachvollziehen können, irgendwas was eine Chance hat bei uns zu kompilieren wäre halt schon notwendig.
Konkret sieht es wie folgt aus:
Der 4 Kanal Controller hat homing und Callibration das er ermittelt die max. Hublänge der Aktuatoren und speichert die Werte dann mit 5mm Reserve zu Sicherheit ab zudem liest er den Torque Wert mit aus.
Der 6 Kanal Aufbau ist esp32 bei dem die Ansteuerung der Servo-driver mit 400khz erfolgt. Dieser hat im Moment kein torque level. Zudem war hier der E-Stop auf dem falschen Pin ausgelegt wodurch ich mir den vspi und i2c verbaut hatte. Zudem ist dies nur für eine Winkelbewegung nach Stewart Prinzip ausgelegt. Aber das Timing Problem ist da gelöst.
Der dritte ist nun die Weiterentwicklung von den ersten beiden. 8 Motoren für linearen Antrieb mit torque Level und Servo Ready,.... der E-Stop wurde auf einen neuen Pin verlegt um vspi und I2c für Erweiterungen auf Pin Header herauszufinden. Der MCP23S17 wurde auf 4 Stk. Erweitert wie auch die Level shifter von 2 auf 8 stk.
Eigentlich liegt der Kern darin den sketch von Controller 2 um die zusätzlichen MCP's zu erweitern und die linear antrieb Funktionen des controller 1 zu integrieren, d.h. die stewart rotary Funktion die die linearen Funktion zu ersetzen.
Für jeden MCP23S17 wirst Du eine eigene Instanz benötigen.
Wenn Du das da oben kannst, geht das auch mehrfach.
Das hatte ich schon gesehen und befürchtet. Im ersten Schritt heisst das, hier auf 4 Instanzen aufzubohren, die Frage ist ob man ein paar Integer und Variablen verwendet soll und jeden mcp einen eigenen Objekt Namen verpasst so wie sie auch im Schemata und auf dem Board benannt sind, MCP23S17_1 (Adresse 0), MCP23S17_2 (Adresse 1), ....
Wenn das geschafft ist. Wäre der nächste Step die Portierung der linear Funktion von Controller1.
Ich wurde vorhin darauf aufmerksam gemacht nicht mehr die eeprom.h zu nutzen sondern alles in die prefeferences.h zu portieren, aber das übersteigt aktuell meine Fähigkeiten, da summieren sich dann die Baustellen, da bräuchte ich dann eure Hilfe wieder
Ja, würde ich so machen.
Das würde ich auf später verschieben, funktioniert derzeit ja noch 
Ich habe schon mal eine Tabelle gebaut in der die MCP'S mit den Pins und den Belegungen der einzelnen Motoren drin steht. Frage ist soll ich diese um einen Int Wert erweitern oder soll ich etwa Objekte/Gruppen pro Motor zusammenstellen.
imho bilden die 4 MCP23S17 eine Klasse mit 4 Instanzen
und die 6 Motoren eine separate Klasse mit 6 Instanzen, wobei dann jede Motor-Instanz einen (Teil) eines MCP23S17 nutzt.
Im Konstruktor der Klasse Motor würde ich mittels Initialisierungsliste den jeweiligen MCP + die zugeordneten Pins übergeben.
Im Programm würde ich dann die jeweilige Motorinstanz ansprechen.
Also das die 4 MCPS eine Klasse mit 4 Instanzen bilden hört sich gut an.
Die 8 Motoren eine Klasse mit 8 Instanzen hat,jede Motor Instanz ist über mehrere MCP-Instanzen verteilt. Zusätzlich gibt es dann noch eine RefIN Klasse mit einer Instanz.
"Im Konstruktor der Klasse Motor würde ich mittels Initialisierungsliste den jeweiligen MCP + die zugeordneten Pins übergeben."
klingt logisch und einleuchtend, ein praktisches Beispiel wäre Hilfreich
hier mal ein bißchen Code:
//pin number for step and direction pins on the MCP23S17_1
const int stepPins[] = {0,1,2,3,4,5,6,7};
const int dirPins[] = {9,10,11,12,13,14,15};
//multiplexers for communicating with all 8 servo controllers.
SPIClass hspi( HSPI );
MCP23S17_1 outputBank( &hspi, 15, 0 );
MCP23S17_4 inputBank( &hspi, 15, 2 );
Frage wie mache ich das bei MCP23S17_2 und MCP23S17_2 da diese die Pins 0-7 als outputBank haben und die Pins 8-15 inputBank sind?
Deine Grafik in #11 ist für mich zu unscharf.
Designe mal die Motorklasse und die MCP Klasse inkl. den member Variablen für die Pins.
Dann helf ich gern mit der Initialisierungsliste für die Motorklasse sofern ich dass noch checke.
Aber es scheint halt dass du pro Motor
einen MCP für Step_xx und einen pin übergeben musst
einen MCP für die Dir_ und einen pin
einen MCP für den SigIn und einen pin
3 mal MCP für die SigOut_ und den jeweiligen Pin
Bitte in Code-Tags, dann sieht das besser aus.
Was denkst Du, ist dies?
MCP23S17 outputBank( &hspi, 15, 0 );
MCP23S17 ist die Klasse aus der Bibliothek und outputBank ist ein Objekt dieser Klasse. Den Konstruktor findest Du in MCP23S17.h.
Auch in scharf nützt sie nicht, da die Motorpins den MCP-Pins noch nicht zugeordnet sind. Also Step_M1 hängt lt. Plan in der Luft.