Topics created by Chriss

@jay_s_uk It seems like I instantly felt in love with BtnCmd. 😄

Cheers....

@Chriss you are right, the M308 documentation was misleading. I have removed the reference to the maximum number of sensors being 32. Thank you for pointing this out.

@chrishamm said in duetpluginservice(-root) not starting....:

@Chriss said in duetpluginservice(-root) not starting....:

Is there a am64 repo for that? I would like to play with that in a VM.

No. You could build it from the sources for different architectures but since it requires an SPI link to work I guess that's rather pointless.

OK, so no VM than, I will grep a other PI than for testing that.

@Chriss said in duetpluginservice(-root) not starting....:

I'm confused that I'm the only person reporting that, I used the most recent raspberry image from the duet homepage and I did not altered anything.

If anything went wrong during start-up, the journal should tell you. No idea why they were empty on your machine, though. They should be enabled by default. What variant are you using, 32 or 64-bit, with or without GUI?

64 and without GUI.

Cheers, Chriss

@dc42 Thanks... that makes sense that it is not working as expected than. 😄 And that explains the behaviour too. Let me get that together somehow.

@gloomyandy said in All Positions "n/a" after"G30 Z-99999" ?:

@Chriss said in All Positions "n/a" after"G30 Z-99999" ?:

Four out seven I would say

None of those examples show the use of Z-9999? As I mentioned above the only documented use of Z with a special value of -9999 (or below) is in the section "G30 with a P parameter"

Oh yes, that is true, we misunderstood us here.

The use of two (different) speeds supplied via the F parameter adds an extra "fast" probe to the probing process, this first probe is always discarded (as it it will probably be less accurate) and the number of probes as defined by the A parameter are then performed. The reason for this is to allow a fast initial move to get the probe near to the target (which is not always the bed) followed by the actual probing movements (which are performed from the dive height). This typically allows for a faster probing operation when the probe is a long way from the target. Makes sense to me.

Yes, all of that makes sense to me too. The problem is that you have two parameters colliding here. F1:2 specifies at least two probing moves, and a A1 which wants only one probing move. The scope may be different, I understand that A is the hard stop for the S parameter. But this is not fully logical to me than too. I would expect that the A has an impact of the 2nd F parameter only. So you have one fast move to have a "guess" where the end is and than two ore more precise moves till you have a low derivation.
Long story short, what I would not expect in any of this cases that t he axis run into a "n/a" state after one probe when you do a "A0" which I tired. It may helps to simply deny the use of "A0" or understand "A0" as: "Te user do not want to reprobe" and ignore the 2nd F parameter. Putting the axis in

If you do not want this initial fast probe then just specify a single value to the F parameter in a M558 setting. I'm fairly sure you can change the F and A settings without needing to specify the other M558 parameters.

I have learned in the past that this is/was not a good idea. I had some strange behaviours when I executed M558 without the full set of wanted parameters. I think that I lost some of the parameters than from time to time.

Why should it make any difference to the behaviour of the probing move whether I specify a P when I use Z-99999? As far as I remember was Z-99999 supported before the P parameter was implemented. I may have a wrong understanding but I think that I need to use the Z-99999 at every other G30 if Z is already homed, or is this the wrong understanding already?
In my world is there no relation between P and Z-99999 but I may be wrong.

Cheers, Chriss

OK, the printer has won. I will rebuild the endstop. The Y homing works perfectly when the printer lays on its side. It miss behaves as soon as it is back on its feed. I think that the microswitch has a problem. Case closed, back to the workshop.

I rebuild the toolhead including the extruder and it seems to me like the problem is gone now. I will do some more test prints but I think that we can close the problem now.

Cheers, Chriss

@droftarts Nice.. my FF is not freaking out anymore. I hope that certbot has set a reminder. 😉

@Phaedrux That is what I want to avoid. The macros folder is in git and shared between printers etc. And I do not want to search the needle in the job hay stack every time I need one of the files.

Cheers, Chriss

@dc42 Thanks David, I will place two files in a folder than, one to start it which will contain a M32 "/macros/bla_bla/test-file.g" only. Nice.... (My bad that I was unable to find the command in the docu again. 😞 )

@Chriss yes meta commands, function names and variable names are case sensitive.

@Chriss said in Jerk/M566 how to find the ideal setting?:

@br7408 Thanks... that sounds like a very cool way to find the right values. .... I will give it a try....

I literally reconfirmed this again yesterday.

I was printing a partially radiused object (120 mm fan shroud), and I figured I'd lower the jerk a little just to see if I could get a slower start on the straight edges, to help the IS work a little sooner. As soon as I dropped outside wall jerk to 540, I could hear the steppers ratcheting on radius moves, and the outside wall of the radius was choppy. Went back to 600 and it was fine again.

I think jerk is literally one of the only settings that my printer really can consistently tell me what the minimum acceptable setting is.

Now this is a 4 motor corexy.... I don't know if that would make a difference.

@droftarts Thanks a lot... it looks much better now. At least to me. 😉

To my future me:

This works:

M568 P0 S250 A2 M116 M568 P0 S150 A2 M116

@gloomyandy No no... I'm sorry if you misunderstood me, please bare with me, I'm German. 🙂

let me add a cable to ground the revo, just to strike this problem out. This will mean to me that I have to pull the plug of the printer and we loose the opportunity to have a look at a memory dump or similar according to my other problem.

Cheers, Chriss

@chrishamm Thanks, I will ignore it than. There are enough more urgent thinks on my table.

Cheers, Chriss

I play with my backup and upload script a bit, and produced some errors with the DWC too:

[chriss@leela 2.4-250]$ ./upload.sh Already up to date. macros filaments macros menu sys [chriss@leela 2.4-250]$ ./upload.sh Already up to date. macros filaments macros menu sys 2024/04/12 08:57:22 Post "http://192.168.1.69:80/rr_upload?crc32=3eeea27d&name=0%3A%2Fsys%2Fconfig_DEBUG.g&time=2024-04-12T08%3A57%3A22": EOF [chriss@leela 2.4-250]$ [chriss@leela 2.4-250]$ [chriss@leela 2.4-250]$ ./upload.sh Already up to date. macros filaments macros 2024/04/12 08:57:41 Post "http://192.168.1.69:80/rr_upload?crc32=4304999f&name=0%3A%2Fmacros%2FMaintenance%2F95_Noozle_220c.g&time=2024-04-12T08%3A57%3A41": read tcp 192.168.1.8:48524->192.168.1.69:80: read: connection reset by peer menu 2024/04/12 08:57:41 Duet currently not available sys [chriss@leela 2.4-250]$

I just checked, I have only two taps in one browser open to the DWC. I reduced the open taps to one and I still get errors.... :?

Cheers, Chriss

Have you tried running the same gcode file again to see if i stops at the same point?

Please share a M122 report after each reset.

Also please share your config set.

@Chriss the prototype E3D tool changers used a servo to lock/unlock tools, but it didn't last long enough, so E3D switched to using a small stepper motor. Your clone may be different.