@mmcc as @droftarts said. For a PT100, if you see positive spikes then a bad connection between the daughter board and the sensor is most likely. If the wires are long or there are any connectors in the wiring then I strongly recommend using a 4-wire connection.

@Argo thanks for reporting this. Please test again with beta 3 when we release it.

@Jarery said in Duet Wifi - Thermistor issues:

Yes I agree a handheld laser thermometer is not great, but it happens to read the nozzle temp accurately at room temp

That's because everything it can see around the nozzle is at room temperature. I repeat, an IR thermometer is useless for reading nozzle temperature. It's reading the average temperature of an area of which the nozzle is a small part.

An FLIR camera may give you a more accurate reading, but bear in mind that the nozzle won't be quite as hot as the melt zone or the heater core.

@MintyTrebor
WORKS GOOD!
Thanks for your help.

@p8blr in that example you would divide your E steps/mm by 1.0036.

The best fit line in the graph in your earlier post showed an intercept of 0.9194 so if using that to provide the parameters you would multiply the steps/mm by 0.9194.

So it looks like the Z stepper was bad, replaced it with an identical one and the mesh compensation is now working properly.. I'm guessing all the z-axis movement during the mesh compensation process was causing more missed steps then the simple repeat probes and non-mesh compensation prints that I did.

@droftarts
I have just atempted this... But my computer or bossa cant find my usb port....maybe try on my mac....

@3DPMicro You can change the number of axes shown with M584 P parameter. This can be manipulated somewhat by defining extra axes in the order you want them to hide, eg define M584 X Y Z B, then M584 A, then A will be hidden before B. But the X, Y and Z are always defined by default, in that order. So currently you can't hide just the Y axis.

I think this has come up before with CNC lathes. Maybe create a feature request better control of this. Perhaps M584 P"Y" could be implemented to hide a specific axis, @dc42 ?

Ian

@Triet You would need to send a M92 E... command. See https://docs.duet3d.com/en/User_manual/Reference/Gcodes#m92-set-axis-steps-per-unit
This is in steps per mm. It's the only way to adjust the extrusion rate apart from M221. If you want it in some other unit, or as a percentage, you could write a macro to convert it for you.

You can change the mixing ratio with M567 on tools with multiple extruders, I'm not sure if you can use it with a tool with only one extruder, and the result wouldn't be much different from using M221.

Ian

@o_lampe this was just for the show, to make it transportable. Using the whiteboard was convenient for demonstration purposes. Now it’s back home, I’m going to mount it to the wall, and see how it draws then. In the past, the board it was mounted on was always laid back a few degrees, which may both help and hinder drawing, by increasing the pressure on the pen.

It’s still not very precise, least accurate at the limits of its range by 1-2mm perhaps. I need to tune the speeds and accelerations a bit more, but we did find at the show that some low frequency, broad band input shaping helped with belt wobble a bit.

I could mount two more motors at the bottom, if I went back to using a full sheet board, but then I’d have to deal with winding the belts/cables onto a spool, and redesign the gondola to have 4 arms. 3 points would limit the drawing area.

It may be that something like the original CoreXY ‘Bot of the Cloth’ would make a better, more accurate, portable plotter. https://corexy.com/botofthecloth/index.html

Ian

Hello @droftarts.
It's ok. I just disabled this option because I didn't understand its purpose. When enabled, it copies the same values ​​from the hotend to the table, it seems like a bug to me.
Thank you.

@torstha if you track the OK responses from each command then you can use the M400 command to wait for all movement to stop. You won't get an OK response from the M400 command until motion has stopped.

Alternatively, use the M409 command to read state.status in a loop and wait for it to become "idle".

@wayneosdias the 4Hz sampling rate only applies to the rate at which data from sensors (configured using M307) is collected and returned from the expansion board to the main board; and to the collection of data from sensors connected to the main board into the object model. The actual sampling in the ADC is much faster on both main boards and expansion boards. Changes to digital inputs are also signalled from expansion boards to the main board very quickly. Likewise when an analog input configures as general purpose input crosses the threshold value.

So it's entirely possible to do the processing you want on your custom expansion board and pass it back to the main board over CAN.

OTOH if you need the data to be passed directly into the Pi (or other computer running OpenPnP) then that would be a reason for bypassing the expansion board processor and CAN and using a separate cable back to the Pi.

@ketirange Turns out a motor connector and cable was faulty, and after replacing it im able to perform a calibration move.

@Macgyver said in Trouble with a if statement decision tree using M291 K:

Is there a command to allow user free text input using the onscreen keyboard?

Try the S7 parameter of M297, https://docs.duet3d.com/en/User_manual/Reference/Gcodes#m291-display-message-and-optionally-wait-for-response.

Interesting problem to solve. I read the intro messages with a different assumption than @droftarts - I assumed you are trying to repair gouges in the PTEX, not dressing the whole base of the ski/snowboard, and my thought was that rather than try to map a gouge, why not have a two step system. Position the "gadget" over the gouge and clamp it to the ski/snowboard. Select one of many pre-defined "patch" shapes. Insert tool #1 in the gadget. Tool 1 is a Dremel tool (or similar and routes a patch to a predefined depth. Then insert tool 2- the PTEX extruder which fills the shape the first tool routed. I can also imagine "custom patch shapes" could be created from a photo of the gouged surface.

@droftarts thank you for the reply and sorry for the late reply.

After sending the message I continued tinkering and searching for clues of why that happened, and I've discovered what was the problem:

By using the BLV mgn profile on Cura, the special option "Set Relative Extrusion" is disabled, meaning that when I was applying the "set relative extrusion" command inside the gcode, the acual extrusion values inside the print gcode were still absolute and exponentially told the machine to extrude more and more filament, more than it could do.

By removing the relative extrusion command, the printer worked like a charm.
After that, I've tried using other slicers like Orca, and it managed to convert to relative extrusion with no problem, with also a lot more of options for me to customize. So I'll probably stick to it from now on.

That was genuinely my bad to not have thought of that before, tomorrow I'll set this post to resolved for the posterity.

@kivlow Please post your full config.g and the response to M122.

Generally, in order of most likely to least likely, spiky temperature readings are caused by:

intermittent wiring - loose connections, poor crimping, frayed wires, dry solder joints. It may only happen when the wiring moves, or when temperature changes. failing temperature sensor - may only show when at temperature Electrical interference - usually from heater or motor wiring running very close to the temperature sensor wiring. Generally shows when machine is operating Power supply issues - faulty or failing power supply, external power spikes (eg large/noisy dc motor on the same electrical circuit starting/stopping) Hardware issues - faulty Duet board. Firmware bug - least likely because this is heavily tested, and would be reported by other users.

Ian

I have also replicated this issue with firmware version 3.5.4 using Orcaslicer GCODE. I was able to recover operation by toggling off "Exclude Objects"

Oddly, this was working fine for slicing normal STL files but occurred when I was running Orcaslicer's built-in pressure advance calibration tests.

@fotomas I can't see anything wrong with your wiring.
I'm not aware of it being possible to damage when programmed as a probe. We do have a few users who haven't been able to get one working recently though. I've only ever tested a v1 microprobe. I don't have a V2.