Connect a water flow sensor --> will M591 P7 work in Laser mode?
-
@paulg4h said in Connect a water flow sensor in laser mode:
like the smart filament sensor for printers, but is this usable in laser mode too?
Why not? The filament sensor causes the printer to pause. It's your choice, what you put into the pause-macro.
Another option would be an thermistor to check water temp, but that's a slow reaction. -
@o_lampe
A temp sonsor will not be the best solution in case of a leak! -
I think a flow sensor and a thermistor would be the best solution, if any of them are triggered the laser should be pause the job.
Same for the lid switch.
-
@o_lampe said in Connect a water flow sensor --> will M591 P7 work in Laser mode?:
@paulg4h said in Connect a water flow sensor in laser mode:
like the smart filament sensor for printers, but is this usable in laser mode too?
Why not? The filament sensor causes the printer to pause. It's your choice, what you put into the pause-macro.
Another option would be an thermistor to check water temp, but that's a slow reaction.The filament monitor code for laser, magnetic and pulse-generating sensors looks for differences between commanded and measured extrusion. So you can't use it for a laser because there is no extrusion.
OTOH you could configure a dummy fan with tacho, with your sensor connected to the fan tacho input. Then use the daemon.g file to monitor the tacho reading.
-
@dc42
Many thanks, now I get the rpm from the sensor, but maybe you are so kind to tell me how to read the value in daemon.g and check if it is below a threshold and pause the machine in that case.http://192.168.199.203/rr_model?key=fans
returns:
{"key":"fans","flags":"","result":[{"actualValue":0,"blip":0.10,"max":1.00,"min":0.10,"name":"","requestedValue":0,"rpm":203,"thermostatic":{"heaters":[]}}],"next":0} -
@paulg4h
you should have a look to the object model for correct naming... i'm not at the machine...
But it will be something like this:if fans[n].rpm < xxx M25
-
@cosmowave
this is now my daemon.g contentif job.duration = null ; No job ignore sensor reading else ; Check Water Flow if fans[0].rpm < 100 G4 P10 if fans[0].rpm < 100 G4 P10 if fans[0].rpm < 100 M25 M118 S"No Water flow!" ; Check water temperature if sensors.analog[0].lastReading > 35 G4 P10 if sensors.analog[0].lastReading > 35 G4 P10 if sensors.analog[0].lastReading > 35 M25 M118 S"Water to hot!"
-
Now even with three times reading the rpm and the delay the job pauses with the message no water flow.
How can I prevent this?
-
@paulg4h
First: check if your rpm is > 100 -
@cosmowave this works now, many thanks!
-
For everyone now the water flow sensor and even the water temperature monitored by RRF worked and pause the job when the water flow is to low or the water temperature is to high.
I use the YF-S201 as Flow Meter connected to the SKR 1.4T Board on the BLTouch Connector (servo and probe) pins. The thermistor is connected to the bed thermistor input also.
then I add in config.g
; Tools --> Laser Water Flow M950 F0 C"!fan0+^probe" ; Fan 0 uses the Fan0 output, but we are using a PWM fan so the output needs to be inverted, also we are using probe as a tacho input with pullup resistor enabled ; Tools --> Laser Water Temperature M308 S0 P"bedtemp" Y"thermistor" T100000 B4092 ; configure sensor 0 as thermistor on pin bedtemp
then add the daemon.g file with this content too:
if job.duration = null ; No job ignore sensor reading else ; Check Water Flow if fans[0].rpm < 100 G4 P10 if fans[0].rpm < 100 G4 P10 if fans[0].rpm < 100 G4 P10 if fans[0].rpm < 100 M25 ; pause job M118 S"No Water flow!" ; write msg ; Check water temperature if sensors.analog[0].lastReading > 35 G4 P10 if sensors.analog[0].lastReading > 35 G4 P10 if sensors.analog[0].lastReading > 35 M25 ; pause job M118 S"Water to hot!" ; write msg
Many thank's for all your help!
-
@paulg4h
Thanks for sharing!
I'm just wondering, if there's a different way to code this (G4 P10)?
Eg. using a counter variable or iteration?
You can keep it like that, but if there's more code in daemon.g (for Lid control?) you don't want daemon.g to stick in a if-iteration with lots of G4. -
@o_lampe You are right, this is not perfect, maybe I found a better way without G4 P10 but for the lid control this doesn't matter because this is handled by triggers and works without G4
-
@paulg4h
I'm sure you know it already, just wanted to mention that daemon.g runs only every 10 seconds. So you already have a G4 P10 'incorporated'.
Just have to count, how many times in a row your sensors were outside of the zone. -
@o_lampe said in Connect a water flow sensor --> will M591 P7 work in Laser mode?:
@paulg4h
I'm sure you know it already, just wanted to mention that daemon.g runs only every 10 seconds. So you already have a G4 P10 'incorporated'.
Just have to count, how many times in a row your sensors were outside of the zone.G4 P10 waits for 10 milliseconds. G4 S10 would wait for 10 seconds.
To reduce the number of accesses to the SD card, it's best to use an explicit loop in daemon.g like this:
while true G4 S2 ... rest of code ...
This saves RRF from having to keep re-opening the file. You can change S2 to however many seconds you want to wait between tests.
-
@dc42 thanks for the input.
After changing of the daemon.g I am not able to update the file by DWC because it is now opened forever.
How can I update the daemon.g beside change the file on SD card now?
-
@paulg4h said in Connect a water flow sensor --> will M591 P7 work in Laser mode?:
@dc42 thanks for the input.
After changing of the daemon.g I am not able to update the file by DWC because it is now opened forever.
How can I update the daemon.g beside change the file on SD card now?
Rename the daemon.g file from DWC, then reset.
-
@dc42 Thank's again!
How could I use the rpm more reliable to detect water flow, even in DWC the Sensors Fan RPM are shown and jumps between 0 and something between 190 and 210 all the time.
What is the best in sort of functionality and use as low as possible resources in RRF?
-
Is there anybody who can show the best way to monitor such an sensor where the reading is not reliable on RRF 3.3?
Many thanks!
-
@paulg4h I think, it is a signal problem. Do you have an oscilloscope for checking the signal?