Posts made by Tinchus

I have read this new feature on 3.6 version. Also read something about prusa doing this.
But I dont clearly see the difference beween phase steppiung and the coolstep feature of the trinamic drivers.
Can someone clarify please?

@fcwilt Thanks for your feedback @fcwilt . To answer both: I dindt knew that probe but... I have exactly the same design for a very hight temperature enclosed actively heatd chamber (it reaches 220 degrees celsius). As far as I can see it is the same (but body in my case is all cnc metal). Works very good but ccuracy is lower than bltouch because of temeprature effects on metal and other details but sill way better than anything else (we have an average error of 0.01mm, wich is way of what it can affect a first layer print ). A good example of a problem being solved in 2 places reaching to the same solution. In this case for the moment I would prefer not having to send a new "touchy" body cnc part (this is how we called this sensor internally) adn try to keep for some more time the blotuch, we have 10 of them deployed)

Regarding the other answer: we can debate if you want in the other topic, because doing it here is like repeaton all again, but trust me: thisis not a mecanical issue. The permanent magnet in no way can be affected by a 50 degrees temp in such way. I would agree if we would be talking of 70/80 degrees. Also they way it manifest is clearlo not a mecanical issue. And as I said in the original post where you can see numerical data, this is happenining on the electronics (blt side, not the duet)

@fcwilt yes. They have very good eclosures, no active heating but as I described on the originalk post, while printing ABS for example I can reach easily stable 65 egrees C, even printing PLA with bed at 50 degrees only, I can reach 45 degrees on the chamber.
I dont really blame bltouch, it is great to my opinion, it is a device that was designed in an era where enclosed printer didnt exist at the common user level.
I also had like 10 printer working with bltouch for years with no issues at all. This issue arised when using the enclosed ones.

In another post I reported some issues with bltouch. At the end conclusion is hard to dispute: bltouch is affected by temperature.
At the moment I really dont have the time to look for a suitable replacement (other bltouch like alternatives probably will have the same issues) inductive/capacitive sensors in wont work with my print beds materials or dont have at the mnoment access to them. So fo the moment, bltouch stays.
Temporal solution now is really ugly: after probing the mesh, I just put a piece of tape to avoid the clip to go down.
Today I did a final tests since I wanted to know if this "pin going down and up" event is a mecanical o electric/electronic.
I did 2 cld prints in order to not damage the pin, and in both prints I did have the event: pin goes down and inmediatly up randomly during print.
Then I repeated the same gcode, but these 2 times, I just disconected the bltouch conector. I monitored both print only for 1 hs (in the previous prints the event would for sure happen at least 1 time in the forst 30 minutes) and there was no event.
So im almost sure this problem is not mecanical, is coming from electronics. Sin ce as stated on the other post noise is discarded as a possible suspect (cable is twisted, also is shielded with special tape, and cable is also away from other cables as fas as possible). Electronics is not my field, but then my guess is something is happening on the bltouch electronics while printing and when electronics temperatures is around 50 degrees.
Hall effect is affected by temperature but I dont know why that would be triggering the pin down event.
So the other suspect is the servo signal being affected somehow??? this queston goes tothe electronics experts here.
So the other question (testing this would really take a lot of time so that is why I prefer to ask) would be: if servo signal could be the problem somehow because of temperature of the electronics, would be good to "shut down" bltouch using the config? Like disabling the pin for example? or disabling both .in and .out pins after msh probing?
Ideas?

Thanks in advance

@chrishamm That solution wont work completely, I tested it. By putting the files on read only mode, they are not protected from the user dwc. DWC (I might be wrong about whi is doing this ) open the files, reads them, and I have seen they are modified on their atributes.

What I did and worked @trulm (my situation is the same as you) is changing the sticky bits on the files;

sudo chattr +i /opt/dsf/sd/sys/*.g
sudo chattr -i /opt/dsf/sd/sys/config-override.g

This bit makes the files imposible to be modified. Do the same with the macros and the filaments directories.
Also, I have modified the html files on DWC deleting the links to the areas I didnt want my student even look, like for example I deleted the posibility to manually introduce a temperature for the hotend and I also deleted the fill area in the console . In that way students can modified temperature, can not enter gcode comands either ,)

@the_K Im not able to replicate the installation on another printer. The same as you it is happening to me: plugin just runs for 1 second. Looking at the logs I can see an error about a camera module, so I installed:

sudo apt -y install python3-picamera2

With this I can start the plugin and stays active. Still, I cant see the camera on DWC

Thanks for the help.

lets close the topic, It is not related really to the duet. I found the problem: if router goes down and then recovers power, at least on this particular router and internet provider, the router and the printer reconnect again, but the dhcp server on router just give the printer internal network config but ont the required config to get out to internet, and also something happens with the internal dns name ".local" wich is not founded again by other devices reconnecting.
Reconnection should happened only after the router reconnect to the ISP.
I added a crontab job every 10 minutes on the raspberry to handle these event, I post the info here just in case somebody else have this "problem":

sudo nano /home/pi/reconnect_wifi.sh :
#!/bin/bash
if ! ping -c 1 -W 1 8.8.8.8; then
sudo ip link set wlan0 down
sudo ip link set wlan0 up
fi

sudo chmod +x /home/pi/reconnect_wifi.sh
sudo crontab -e:

*/10 * * * * /home/pi/reconnect_wifi.sh

@Phaedrux version is 3.5.3

Yes, sorry for the tricky title LOL.

This ois the issue Im facing: power goes down, so printer goes down and also the wifi router goes down. Or sometimes, and this is worst I think, power of the wifi router goes down and so the printer looses its conection to the network.
When router is on again, the printer seems to not connect again.

My config is a duet3 with SBC (raspberry pi 3 B+)
So in this scenario, the printer continues to print but it is not conected to nwetwork so I cant access DWI.

I guess the reconection should be a task the SBC should do, but it is not doing it.
Should the SBC reconnect automatically when router is on again?

@fcwilt so far I got a tempral solution till I find a proper solution, I modified the start gcode to position the sensor out of printbed and so it doesnt get all the heat, I leave door open so chamber doesnt get hot. After probing I tape the pin to be sure it stays up, then close the door as soon as print start. LOL

I looked for info and I found it: https://reprap.org/forum/read.php?1,873463,873463 reports something very similar. There are other similar posts on other forums too. and the nice find is:
https://www.reddit.com/r/klippers/comments/102ycc3/bltouch_temperature_drift_over_time_seckit_cube/
and pictures of the process: https://imgur.com/a/bJwce1D/

Basically he reposts the same and his solution was to remove the electronics from bltouch body and take it to a cooler place doing a very surgical cabling work.
I have still 2 working bltouchs so I might give a try to this project.

Sorry for blameing duet electronics in the past!!!!!!

I have posted another couple of posts about bltouch configuration and failures. I was never able to use it with some level of confidence. To sum up the other posts: my roblems were bltouch working randomly, sometime the probe is deployed a lot of time, sometime it is not. Sometimes there was a delay of like 2 seconds before being deployed.
Answers to the problems were in general: this was a problem of noise and cabling, somethin g that of course I tried to adress but to me these answers were somehow "not ok" beucase they ignored my comments about me having already replace the cable 3 times, and even replacing the bltouch itself a couple of times.
Any way, in weekends I continued to investigate the issue and now I have finally found a conclusion backup with real numbers and Im able to reproduce (and fix it) the problem.

The problem is temperature. During config time and test time, I even executed like ten times, a script that deplyed the bltouch 100 times and I saw in person that happened, not failing a single time. And then lauched a print and probing was succesful. The another print and probing sometimes failed.
I found the variable: material being printed and the material being used had a bigger bed temperature and hoter nozzle temp. And the important thing here: chamber. The printer has an enclosed chamber, not actively heated but really well closed. When printing PLA, interior temp never rises beyong 35 degrees celsius MAX,. But in the case of PLA or ABS, just preheating the bed to 70 or85 degrees, makes the chamber get to 55 degrees and more in case of ABS (65 degrees C)
Also, even with heatblock being 12 mm away from the body of bltouch all these factors are enough to make bltouch body to reach a temperature between 55 and 63 degrees C. I have measure that using a thermocouple.

I know that many will say that electronics are rated to handle 70/80 degrees with no problem. But this is real and it is happening. Ssomehow the temperaure affects the electronics and bltouch behaviour.

This is not a cable problem: I changed cable 4 times. I remade the crimps like 10 times (all conection on my duets are made by me and they are like a total of 500 conections and I only had problem in 2 or 3 so I can say I know how to crimp a connector)
I have tried 3 v3 bltouch and even 1 V2. And the problem in them were the same.

f bltouch suceeds to complete the initial probing, what happends the is that randomly the pin gets down and up againg, like if there is some electrical noise. I have ruined like 7 pins so far.

Today this idea come to my mind, and I did simple test. I made sure chamber was ambient temp and never more than 40 degrees. No problems at all, print sucessful, no pin up/down events.
The I heated up chamber to 55 degrees in 5 times I tried, 3 of them had problem right in the beginning at initial probing, 2 of them were able to finish initial probing, all 5 times reported pin up/down events.
Inmediately after 5th try, I cooled down chamber and also made sure bltouch was cool, and same gcode but with the chamber door opened and some extra small vent made all error desapear.

So this is my comments about this in case somebody elase had seen this.

Also a small report: M558 P9 C"io7.in" F100 H3.2 R0.2 T6000 A5 B1 , this command should turn off heaters while probing acording to docs in order to avoid noise, but it is not happening or at least on DWC heaters seems to be ON all the time while probing

@engikeneer thanks for the answer. Can you share your config of bltouch?

Hello. I have a doubt about bltouch config. On bltocuh docs, they state that a 100 milsec wait time has to be set in order to "wait" for bltouch to be ready (wait for what? I dont know). So the example config they give for inserting into the start gcode of the slicer is:

M280 P0 S160 ; BLTouch alarm release
G4 P100 ; delay for BLTouch
G28 ; home
G29 ; auto bed leveling

This 100 milsecs delay should also be inserted on Zhome file too like:
M280 P0 S160 ; BLTouch alarm release
G4 P100 ; delay for BLTouch
G30 ; home Z by probing the bed
M913 Z100
G1 Z6 F200
M564 H1

Or it is not necesary since the bltouch configuration on config.g is:

M558 P9 C"io7.in" F100 H3.2 R0.2 T6000 A5 B1

Where the R value of 0.2 inserts a 200 milsec wait time for the proble to be ready each time probing is requested?

Deployprobe.g also has:
M280 P0 S160
G4 P100
M280 P0 S10

Should that 100milsec be there or it is not necesary?

Sorry for the late update. In my case problem is solved. I used the spyglass plugin. I got it from here: https://plugins.duet3d.com/plugins/SpyglassWebcamServerPlugin.html

The build instructions... never used them. I just downloaded the pluging, intalled through DWC interface, on the general settings I completed the url http://printer2.local:8080/stream (later I noticed theat hostname was automatically replaced by the internal ip number)
And it works perfect.

The raspi image I have is a brand new one, nothing extra installed or removed but userland in order to have some commands to verify the cam that seems to not be installed by default:

sudo apt install cmake
git clone https://github.com/raspberrypi/userland
cd userland
./buildme
sudo cp build/bin/* /bin/
sudo reboot
and then tested camera with raspistill -o image.jpg

I really dont know if userland had any effect on camera installation but since bookworm removed any easy way to activate/deactivate the camera (to the level of knowledge I have at least) I installed userland in order to have some debugging on the camera. With raspistill at least I knew the camera was there and detected and then I just installed the pluging
I hope it helps

@droftarts thanks a lot!

Hello. I have update since some weeks to 3.5.4 version. I ahve a duet3, sbc raspberry 3 b+
I have a raspi camera attached. I really use it from time to time, jsut to check sometime if print is ok from remote. It used to work very well on previous version, on this one I know raspbian has changed to bookworm (I say it like if I really know what it is jajajaj)
To my surprise doing the sudo raspi-config in order to activate the camera no longer exist. Si I dont know if the camera is there or not,
Can somebody point on how to activate de camera please?
Thanks inadvance

@chrishamm Then this is solved, thaks a lot for the help

@chrishamm Ok, thanks. Just to be clear for me: this means what if I modify daemon.g, the old file is moved to a .bak file, and that .bak file is still being executed untiil next restart. If I want the new daemin to be excuted, that .back file need to be deleted. It is like this how it works?

If annswer is yes, I think it worth adding this info to documentation regarding daemon.g, I was really going crazy believing I did something wrong at my daemion.g editing LOL

Hello. due3 board, SBC mode with 3.5.4

I have this on my daemon.g

while global.daemonactive
	if state.status != "processing"
		if (heat.heaters[0].current > 60)
			M42 P3 S1
		else
			M42 P3 S0
	G4 S2

I have this because in some situations I prefers to set the variable to false and so stop daemon from working instead of renaming the file. Not really much use. But today I edited daemon.g nd I just added an echo command. I saved the file. So I was expecting to see the echo command being executed and the result on the console. It never happened. I went crazu ike for 10 minutes trying to find a typo mistake, or something. The echo command was never being executed. I checked the global variable value and it was ok with a true value.

The echo command was in the else section. The M42P3 S0 was being executed, I know that because that switch turns off and ON a led. If I manually executed the M42 P3 S1 command (with all heater off and coldf) I could see the led being turned on and after 2 secs daemon.g tuned it off. So daemon was working, the if sentence was ok. The echo command was just not being executed.

Then without any modification I restarted the printer. And this time everything worked as expected. I sidenly started to get the echo command results on the console.

So, It looks like the daemon.g is not being updated if you edit the file. Tjhe file is updated, but the daemon alredy on memory still is the old one?

Im doing something wrong to update daemon.g? starting it and stopping it using the variable works ok

@chrishamm I solved the problem (so close the topic as solved please). I dont know the causes but this is how it is working now:

.- In config.txt I commented the line

#disable_fw_kms_setup=1

By doing this and rebooting, I can see the raspberry logo at boot but then again all goes white and stays there

So again in config.txt I made the change:
dtoverlay=vc4-kms-v3d to dtoverlay=vc4-fkms-v3d

And these 2 changes solved the problem. Everything in "normal " now, The camera is not working either but it is detected.

On the other printer I checked, and disable_fw_kms_setup=1 is not commented... Documentation says this uses kernel defaults. So my guess is since the difference between both raspi images is the date and I can see a difference on kernel vlaues, there is something internal that makes all this trouble to me.

Either way, it is solved. Thanks for the help