@chrishamm

Managed to downgrade to the stable release but now not 100% confident in the system.

Was getting errors about something not being loaded and then incorrect passwords and then in connected but then error again.

@pickett there is an example at https://docs.duet3d.com/User_manual/Connecting_hardware/Fans_connecting

@tekstyleI know this is an old post, but I was searching for the same thing today and found the answer here :

https://github.com/Duet3D/RepRapFirmware/wiki/Object-Model-Documentation

After tuning are you able to run the heater normally or does it still fault?

@phaedrux Thanks, I have the following

d31af541-d905-4335-85de-74cd1494a013-image.png

In that case, there is no problem with loading different M307 in a macro. config-override.g is just a macro itself.

@gallaghersart from what I understand now, it can be handled in daemon.g, maybe in a submacro for better structure.

You'd have to make extensive use of variables. The macro could be something like this (mockup):

determine RGB values for each individual "light" (=group of LEDs), much like @zapta 's example, according to your specification. Store in variables (e.g. "R_group1, U_group1, B_group1, R_group2 ...")

send M150 string at the end of the macro:

M150 R{R_group1} U{B_group1} B{B_group1} S{[number of LEDs in first group]} P{P_group1} F1 M150 R{R_group2} U{B_group2} B{B_group2} S{[number of LEDs in second group]} P{P_group2} F1 M150 R{R_group3} U{B_group3} B{B_group3} S{[number of LEDs in third group]} P{P_group3} F0

this way, all RGB values for the whole strip would be send at once, which was what my initial confusion was about.

If this macro is called regularly in daemon.g, it should all be quite smooth.

another thing is "blinking"; this would be more difficult. It could be done with a variable for brightness that is changed in each iteration of daemon.g, e.g.

P_group1 = 255 (initialised once at start, e.g. in config.g) P_group2 ... P_sign = 1

then in daemon.g:

if {P_group1} == 0 || {P_group1} == 255 P_sign = -P_sign if {P_group1} < 255 && {P_group1} > 0 P_group1 = P_group1 + (P_sign*5)

this way in each iteration of daemon.g, the brightness value is changed. the speed of blinking is dependent on how often daemon.g is called (I understand that this can be adjusted) and the value added in the last operation (e.g. 5)

note: not tested, just what I imagine could work.
I think there has been a request for a more elaborate way of handling LED colours before. Until then, we'd have to work like this.

best, Niklas

@phaedrux Good to know. Thanks.

@adammhaile

Hi,

Well I setup the M208 parameters I set the min/max values so that X=0 Y=0 is the CENTER of the bed.

But in any case, as I understand it, the tool offsets are relative to X=0 Y=0.

It's easy to verify if the values are correct. With a tool selected then a G1 X0 Y0 should move the nozzle of that tool to X=0 Y=0.

Frederick

I think I figured out my problem. The tool was configured to control both fans. So I removed fan0 from that. Second the Q value was so low the fans would not turn unless at 100%. Setting this value to 65000, allowed the fans to work at all values. I think I am good now

@dc42 Perfect. Thanks!

@o_lampe There may be other advantages to using servos in a printer, beyond quieter operation. Servos will enable much higher acceleration and jerk settings (but increased operating noise, and probably ringing) which might improve extrusion by keeping the extruder running at full print speed for a larger percentage of the print time. That has to have some effect on the pressure in the extruder.

If someone is trying to run their printer hard, and runs into the limits of the steppers, they might have skipped steps, etc. The servomotors absolutely will not skip steps unless a solid object gets in the way of the mechanism.

Closed loop steppers are probably better for printers than servos, and probably wouldn't require pulley or gear reduction to get sufficient resolution (compared to cheap iHSV motors). Other servos may have optical encoders and provide the necessary resolution without belt or gear reduction.

It turns out that there is a down spike or up spike in the hotend temperature signal on my machine that appears to coincide with the hotend heater turning on and off respectively. Presumably these spikes are, quite understandably, interfering with the auto tuning algorithm and are causing it to produce parameters which result in "temperature rising much more slowly than the expected" heater fault errors.

My first thought is that, due to my convoluted 12/24 VDC power system - v2max_duet_upgrade_dual_power_accelerometer_v1.0.pdf, there is some sort of VSSA-DC ground mismatch occurring when the heater goes from on to off during the auto tuning cycle. The effect is greater at higher temperatures - see below. My thinking is that, as thermister resistance is lower at higher temperatures producing a lower voltage at the Duet input pin, any change in VSSA-DC ground levels would have a relatively larger impact at higher temperature.

To my mind, the drop in temperature occurring when the hotend heater turns off suggests a lowering of the DC ground ground level relative to VSSA producing a higher voltage at the Duet input and visa versa when the hotend heater turns on.

The image below shows the difference in the temperature signal spikes at 245 vs 195C and the zoomed in lower panels show the point in the auto tuning process when the pump is turned on as well as the behavior reported by the tuning algorithm. Looking at the 245C temperature signal it is amazing that the algorithm comes up with anything at all!
Spike Magnitude 245 vs 195.png

For the moment, in order to have good response to cooling pump transitions etc, i will need to hand tune a set of parameters for every 5C or so due to the increased spiking effect at higher temperatures causing instability. Temperature chart below shows response for 225C "optimized" tuning at initially 225, then 235 and finally 230C.
Test Image 27.png

The approach i took to get past the expected rise rate error was to (somewhat counterintuitively to my dim mind) lower the R and/or C values until the error resolved, get the hotend up to temperature, then increase R until the "spikiness" in the temperature response at steady state resolved followed by adjustment of the dead time to remove the slow oscillation but retain responsiveness to cooling changes. For most temperatures, a fairly significant reduction of the auto tuning generated C parameters was required in order to avoid the expected rise error heater fault after the manual adjustments.

On the off chance it may be of some to use to someone running into a similar situation with a less than ideal hotend temperature signal causing the auto tuning algorithm to generate expected rise rate error heater faults, some data from my testing and resolution process is included below.
Tuning Table.png
It is interesting to note the effect of nozzle height above the bed (last 4 lines of the table above) and cooling pump speed on the cooling off:on C parameters. Based on some flow visualization studies i did with the pump duct, i suspect the paradoxical reduction in C parameter differences at full pump speed may be due to a bigger proportion of each air jet stream escaping under the lower surface of the duct at higher velocities and consequently reducing impingment on the nozzle.

I will try another hotend with the same heater/thermister setup shortly to see if the problem follows and at some point in the next few months will finally convert the machine to straight 24V.

Thank you @dc42 @o_lampe following both of your advise I was able to get duplication mode working.

Much appreciated!

@massimilianoconti yes

@sniper23 said in Uneven Fixed Delta Printer bed with Bltouch and 3D Touch:

Well, that didn't work. did the calibration and M500, still same.

Did you leave the M501 in, to auto load the overrides?

Can you show what is in the config-override.g file?

@dc42 said in Behavior of G1 command with H parameter:

@surgikill said in Behavior of G1 command with H parameter:

I am trying to run a G1 Z15 H1 command. It is my understanding that it should move the Z axis in the positive direction until either one of the conditions are met, I.E. move the Z axis until it hits the endstop, and only move it a maximum of 15mm.

To achieve that for certain, you need to be in relative movement mode, i.e. send G91 before the G1 H1 command. Send G90 to revert to absolute mode.

This worked. Thank you very much.

@deez3443 said in Two thermisor on chamber and limited heater:

Do you have any idea how to use autotune correctly in this system? At best, I will set it up manually.

Given a 300W chamber heater, I had no luck with autotuning. Temperature rise was simply too slow. In the end, I figured out parameters that gave me just some rare heater warnings - they indicate, at least, proximity to a proper model of the heating process.

Finally, I enhanced the fault tolerance with M570 H3 P300 T25, as my heated chamber is (due to the weak heater) quite an inert system. However, you might wish to use other parameter values.

@dc42 you're right in the latest beta of prusaslicer the menu appears in reprap flavor

I completely agree with he braided cable idea. My X, Y, and Z motors are all braided but I used a flat cable on the extruder thinking it would be better for the cable chains. Bad decision.