@rutku G0 X0 Y0 is probably not reachable. You can set A maximum angle to 180 degree, but this makes no sense, because then the next hotend movement is unspecified (the two distal arms are straight, you cannot rotate from there).
bondus repository was like mine, one bug fixed, something with a special case of an angle.
Do you have a question for the debug_output or video?
@pkos, I'm sorry your Duet appears to be faulty and I approve a warranty replacement. Please send an email to email@example.com and CC your reseller. Include a link to this forum thread and the details of your original purchase. You'll receive a reply with a form to fill out.
For posterior's sake, I figured this out. My custom mCode (M9999 in this case) to reboot the RPi is immediately shutting it down. DWC is still online long enough to process it as an unknown command since execonmcode doesn't return the call and reports unsupported.
It appears a method to reboot the RPi is being introduced in 3.3 (M999 B-1), so this will no longer be necessary.
@ignacmc is the nozzle clean when you probe hot? I usually see a little filament oozing from the nozzle after preheating, so I remove it using tweezers before running auto calibration. Sometimes it probes the first point three or four times, buf after that is generally probes each point twice.
You have your tolerance set to 0.003 in M558, which is very tight and almost certainly less than one microstep. So the slightest change will cause multiple probing. If you are using a glass bed, after the indicated temperature is stable it will take several minutes for the glass to stop expanding and the top surface to reach a steady temperature. So consider increasing the tolerance in your M558 command, perhaps to 0.010.
EDIT: I see that you have already increased the tolerance to 0.02, which is also what I use.
@aitor there was a change to RepRapFirmware several versions ago. Several users complained that when the printer started up, the informational messages shown on PanelDue slowed down the startup sequence, because each message had to time out before the next one was shown. So we changed RRF to not buffer up messages, but instead allow later messages to overwrite earlier ones.
@brian please check that the height of the bottom of the sensor board above the tip of the nozzle is correct, about 1.5mm. When using an uncoated glass bed backed by black paint or black paper, the sensor should trigger when the bottom of the sensor board is between 2.5 and 3.5mm above the bed. That distance will be a little different for other bed surfaces, in particular it is higher for opaque surfaces.
@th0mpy in your position I would be tempted to fit some genuine Gates glass-reinforced belts and see whether they give you the same steps/mm on all towers using equal tensions. I must admit, it never occurred to me to measure the actual steps/mm individually for each tower.
hello well if Y axis is front and back and X is left to right and standing in front of printer my X axis has 2 extruders attached together driven on to chrome bars with a cog belt. so i am going to say no not separate independent x axis but to extruder heads sharing same the same axis if that makes since. I believe there are just enough on the duet with 5 to get me there.
Correct, if the two extruders are on the same carriage then you have enough stepper drivers on the Duet. Some users converted their BigBox machines to IDEX but that was not an E3D product.
@ryanp you have a large Y offset for the probe. Is it hanging off the front of the hot end? It will be prone to exaggerate any movement of the X carriage around the X axis. It’s usually better to align the probe in line with X so it doesn’t pick up this error. However, this can also cause error if the X carriage can rock side to side, but usually this is more obvious, as it creates a sawtooth pattern on the mesh map. Nozzle probes such as piezos can get around these limitations; any offset probe will error unless there is zero play in the axes.
@deckingman is correct; get the bed plane level, and if the bed is inherently level, you shouldn’t need mesh compensation. I don’t tend to run it on my printers, though mine have quite small bed areas. With larger beds it’s more difficult to have a perfectly flat surface, due to the weight of the bad causing sag, or thermal expansion causing the shape to change.
I support this and ask you to add a 'look-ahead' fan control. When the gcode tells the part cooling fan to spin 100% for a specific area (eg. bridges) it takes nn.nn seconds before the airflow really builds up. The nozzle has moved away from the critical area long before.
This is especially true for external berd-air part coolers, where the airflow is spot-on, but the pump is far away.
@chrishamm As of right now ExecOnMCode is a simple API client just connecting to the socket. It is not yet converted to an official plugin. It will be started by a user-provided systemd unit (or arbitrary other means) completely independent of DCS.
@mrehorstdmd Hello Yes, both my machines have toothed pulleys for the location belt teeth touches and toothed idler for the location belt teeth touch and smooth idler for the location back side of belt touches. So they seem it's ok. I wondewr if the pulleys located with motors are may be too small. ...
I guess as a work around (for print files) you could use a post processing script in your slicer to replace all M106 to a macro
So if you replace M106 S125 with
M98 P"0:/macros/valve control.g" S125
Then in your macro do all your math and set valve
You can get the speeds using param(S)