Air Assist mit einem MKS DLC32 Board auf dem FluidNC geflasht wurde

Das Signal für den Kompressor stellt das Board im Allgemeinen über den Pin SCL des I2C-Interfaces bereit. An den beiden Punkten GND und SCL liegt dann eine Spannung von ca. 3V, damit lässt sich dann ein Relais schalten. Es muss aber ein Relais-Modul sein, da der Pin SCL mit nicht mehr als 10mA belastet werden darf.
Aber nicht jede mitgelieferte Firmware unterstützt das Signal an SCL, ggf. muss der Controller neu geflasht werden, also vorher mal nachmessen, ob das Signal auch bereit gestellt wird.

Ich hab das hier mal mit einem TS2 gemacht.

Hier findest du ganz unten ein Bild dazu: https://wiki.the-iskens.com/de…r-extras/relaissteuerung/

Und wie Egon schon gesagt hat, nimm ein Relais, das drei Eingänge hat, Spannungsversorgung und einen extra Pin für das Signal. Steht oben in dem Artikel auch.

1. Es hat nichts mit dem SCL Pin zu tun.

2. SSR wäre für die Air Assist Pumpe besser, wirst du merken wenn du dieselbe Phase nimmst wo der Laser angeschlossen ist.

3.Dass ein Pin nur 3V ausgibt habe ich noch nicht gesehen, es waren immer eher mehr.

Im Gegensatz zu der MKS Firmware kann man bei FluidNC den Pin aussuchen "der das Signal unterstützt".

coolant:

flood_pin: NO_PIN

mist_pin: NO_PIN

delay_ms: 0

Den kann man dann auch über die WebUI schalten.

Hallo Skorpi,

das MKS DLC32-Board hat ein I2C-Interface, das direkt vom µC kommt und somit 3,3V hat, deshalb darf es auch mit nicht mehr als 10 mA belastet werden. Ich kenne nur die MKS Firmware und kann deshalb über FluidNV nichts sagen.

nur mal kurz in die Suche eingegeben:
pasted-from-clipboard.png

SCL Pin oder I2C-Interface ist nichts besonderes, ist ein ganz normaler Pin der nur eine "Funktion" hat den die anderen Pins nicht haben.

Am Arduino UNO/Mega habe ich auch 40mA vom Pin abgegriffen und es ist nichts kaputt gegangen oder in Rauch aufgegangen.

Dasselbe wird auch beim ESP32 passieren den ein MKS DLC32 onboard hat.

Also ein SSR sehe ich immer noch als die bessere Lösung für den AirAssist.

Ganz so optimistische würde ich da nicht herangehen, der Arduino UNO/Mega arbeitet mit 5V Betriebsspannung und kann an den Pins schon mal etwas vertragen, der ESP32 dagegen arbeitet mit 3,3V und ist nicht ganz so tolerant. Ein SSR ist sicher die bessere Wahl, allerdings muss man dann, wenn man SCL nimmt, das Signal noch verstärken, sei es die 10 mA einzuhalten oder genügen Spannung fürs SSR bereit zu stellen.

Nochmal als Vergleich:

pasted-from-clipboard.png

pasted-from-clipboard.png

Ja, da kann man sich lange streiten. Ich habe mich hier ran gehalten, man will das Board ja nicht gleich himmeln:

Each digital output pin is associated with its configurable drive strength. Column “Drive Strength” in Table IO_MUX lists the default values.

The drive strength of the digital output pins can be configured into one of the following four options:

• 0: ~5 mA

• 1: ~10 mA

• 2: ~20 mA

• 3: ~40 mA

The default value is 2. The drive strength of the internal pull-up (wpu) and pull-down (wpd) is ~75 µA.

The maximum output current (sink/source) of the ESP32 is 12mA.

Ja, so ein SSR hatte ich zuerst auch dran, aber es scheint da Exemplarstreuungen zu geben, bei mir reichten die 3V nicht immer aus, um das Relais zu schalten, bei einem 2. SSR leuchtete die LED zwar schwach auf, aber es schaltete nicht, deshalb habe ich mich schweren Herzens für das normale Relais entschieden. Die 9 mA liegen noch unter den vorgegebenen 12 mA und somit kann man das bedenkenlos betreiben.

Das schließt sich ja auch nicht aus. Man kann auch ein SSR-Relais mit vernünftiger (Controller-sicherer Beschaltung) nehmen, diese hier:

pasted-from-clipboard.png

Die nehme ich immer, wenn es am Controller geschaltet wird. Die großen SSRs kann man da verwenden, wo man hohe Lasten schalten kann. Da bin ich ganz bei Egon

diese schalten bis 2A oder?

coolant:

flood_pin: NO_PIN

mist_pin: NO_PIN

delay_ms: 0

du könntest auch mit dem delay_ms etwas rumspielen, bin mir nicht sicher obs am anfang etwas später anfängt und am ende etwas später aufhört.

Berichte dann wie es ist, habs noch nicht ausprobiert.

Zitat

delay_ms:

• Type: Integer
• Range: 0 to 10000
• Default: 0
• Details: The delay in milliseconds after the turn on and turn off before more gcode will run

Ah, dann verstehe ich die Erklärung jetzt auch. Es ist ein Delay, das nach dem M7/M8 Kommando (Pumpe an) gewartet wird, bevor weitergemacht wird und auch nach dem M9 Kommando (Pumpe aus) und danach wird weitergefahren. Also ganz stumpf.