For the check macro it would be enough to do the coordinates comparison with a tolerance of say 4 steps to decide whether false positive or not (im my case, most real layer shifts are significantly larger)
But for the resume function... well, optical endstops would perhaps work better. They are quite cheap.
Still, better a printed piece with minuscule horizontal layer inconsistencies than spaguetti on the bed.
@DonStauffer Assuming you have the VFAN selector set to 24V those always on pins should be connected directly (via a fuse) to the 24V psu. If your voltage measurements don't show anything odd, you could try connecting them directly to the psu 24V supply and see they still change sound, that would eliminate the Duet2 as a possible cause.
@droftarts Hi Ian, yes, I understand completely and definitely want to do as it is easier for you. And thank you, now I got the idea that I just copy-paste inside those marks, simple :). Now the code is as it is as I have used it with Duet.
@leone it is implemented. What version of firmware are you using?
Note the command all needs to be sent on one line. If you use the Input Shaping plugin it sends a command like this:
G1 Y222.1 F18000 M400 M956 P20.0 S1000 A0 F"37-T1-Y77.1-222.1-20.0-zvdd-42Hz-0.05.csv"
@kcorbedsellig thanks. Regarding recalibrating the driver at address 80 it looks like no M569.1 command has been sent to that driver. Please send the correct M569.1 command and try again.
@justGuner It may also mean that you have an intermittent problem with the wiring that movement during printing triggers. I guess you will find out over time!
@Richard-F yes it's working now .. I was sure it was broken .. Thanks so much ,there is definitely a burn small around out1 ,
, but its working
thanks again 🙂
OK, but it still leaves open what changed? Is there an issue with file handling?
3.5 is a very large update to RRF, particularly with multiple gcode streams, so I'm not surprised that some things will behave a bit differently. @dc42 would have to advise on what exactly may have changed here.
If your original connection method didn't work then adding a 10K pullup resistor between OUT4_NEG (the pin that I think you are calling OUT4 in your post) and +5V from any IO_OUT connector should fix it. That would avoid having to use up the 5V_PWM pin.
I tried this solution and it also works as expected.
The only drawback is that when you first turn on the machine or restart Duet, the fan goes Max speed and it is really loud.
I will keep it using the OUT_9 5V PWM + OUT4_Tach as final solution.
Thanks for all the help and super quick response from all of you!
Well, I'm not entirely sure what caused this error in the first place. After the last error (that I posted above) I powered down the Duet board and the Raspberry Pi and started from a cold start. As of now, I've restarted a print three times (with the same g-code; the restarts were bed adhesion related, not anything RRF was doing) so far and I've been unable to recreate the problem. Pause and resume works without issue or error and as expected.
I'll be keeping a watchful eye on the printer for now.