SOLVED: The Orion was not working properly, after switching the whole Orion board everything works as expected!

Hello there,

I am having a problem with the Piezo Orion sensor, it looks like it does not react fast enough or is not sensitive enough-ish...

Situation:
I am having a Duet WiFi board and I am using a genuine Precision Orion sensor as my Z-endstop. I tuned the little potentiometer so that a real light tap with my fingernail forces it to respond, so I figured the tap of the nozzle on the Ultrabase would do the same, well it doesn't.
Instead of triggering reliably it bends the whole gantry upwards, sometimes about 0.8mm sometimes over 2mm until it triggers, or not.

Setup:
Firmware Name: RepRapFirmware for Duet 2 WiFi/Ethernet
Firmware Electronics: Duet WiFi 1.02 or later
Firmware Version: 2.0(RTOS) (2018-06-05b3)
WiFi Server Version: 1.21
Web Interface Version: 1.21.1

Please see the relevant parts of my config:

config.g:
; Drives
; just to clarify Z actually is allowed to travel the 420mm/min
M203 X12000 Y12000 Z420 E6000 ; Set maximum speeds (mm/min)

; Endstops
M574 Z1 S2 ; Set endstops controlled by probe (Z-endstop is Z-probe)

; Z-Probe
M558 P8 I1 H1 R0.5 F420 T6000
G31 P100 X0 Y0 Z-0.1

homez.g:
G91 ; relative positioning
G1 Z5 F6000 S2 ; lift Z relative to current position
G90 ; absolute positioning
G1 X150 Y150 F6000 ; go to first probe point
G30 ; home Z by probing the bed

I can't really make the sensor any more sensible, otherwise it will trigger due to movement and on the same time am running out of ideas. Any help is highly appreciated!

Cheers,
Markus

Update:

The repeated homing seems to work 99% now, I decreased the the current to the steppers from 1600mA to 1300mA in config.g. I am wondering if this might have been the reason behind the problem all the time.

The steppers I am using are the 0.9° high torque motors from E3D, in case you like to read the datasheet, it can be found here: https://e3d-online.dozuki.com/Item/High_torque_motor

What happens sometimes is that when the steppers get a bit temperature the stall threshold seems to be too low and it triggers early, however immediate homing again works fine, regardless the temperature.
Unfortunately it does not work reliable when I increase the stall threshold by 1.

I'd like a simple "Work Hours Meter", whenever gcode is processed it should log time.

I can see how this can be a problem for initial setup where gcode is executed, as well on boot time, but from my point of view this can be neglected. Its not like it has any serious effect when it logs 65min additional time...

For easier implementation the "start gcode" could hold some Mxxx gcode and "end gcode" as well. I don't have any special needs for additional calculation.

However: only counting hours is too simple. My prints often start over night, I leave them in the morning, then I go to work, etc. After the print has finished the machine is idling happily for many hours which then would be counted as "work hours".

IMHO it would also suffice to read the currently logged hours via some gcode command, no need for DWC integration or whatsoever. I solely need this for maintenance purposes. The counter can optionally be reset using some gcode parameter or so.

My 2ct on this topic.

@bot I am able to create the same gcode with PrusaSlicer. It seems to be a bug that both slicers have.

Over at superslicer someone reported something similar, he wanted travel acceleration added as a parameter, if I remember correctly.

FYI, here's the link to the relevant SuperSlicer issue:

https://github.com/supermerill/SuperSlicer/issues/450

toskium created this issue in supermerill/SuperSlicer

closed G-Code flavor RepRap produces wrong M204 commands #450

Hi all,

TLDR;
I built my custom delta printer and it works well. However since I have it enclosed and the build chamber heats up to around 45-50°C I noticed the probe on the smart effector has become somewhat unreliable. Is that a known issue?

So here is what happens:
I start a print while the smart effector is "cold" (room temperature). Before each print I probe the bed and create a heightmap. First print, while the effector is more or less on room temperature the readings are fine, the bed is flat, first layer looks good.

After a couple of hours the print finishes and the effector has heated up to whatever temperature is in the chamber, when printing ABS this is around 45-50°C.

I remove the build surface, pop off the print, put it back in the enclosed printer and start the same gcode again.

Unfortunately the probe now delivers very inaccurate results, it reports pretty hefty low spots of -0.15 to -0.25mm where there clearly are none. I made sure of that using a straight edge.

I can reproduce that behaviour every time I let the printer cool down completely, that happens over night usually, and start the first print. Probing is fine and as soon as it soaked enough heat the probe readings are off the charts.

My current solution is to not probe the bed automatically, that is no big issue from the mechanical/printing perspective since it is flat enough but that also removes the option for me to swap build plates since they have a different thickness.

Just as a heads-up for you all, Merill acknowledged the issue and will have it fixed in Superslicer in the upcoming release.

See: https://github.com/supermerill/SuperSlicer/issues/450#issuecomment-687650047

toskium created this issue in supermerill/SuperSlicer

closed G-Code flavor RepRap produces wrong M204 commands #450

@Phaedrux this seems to be an issue for a long time now. I remember this having me confused when I was building my last corexy but it fell of the stack and I worked around it... Today it resurfaced

FYI, here's the link to the relevant SuperSlicer issue:

https://github.com/supermerill/SuperSlicer/issues/450

toskium created this issue in supermerill/SuperSlicer

closed G-Code flavor RepRap produces wrong M204 commands #450

@bot I am able to create the same gcode with PrusaSlicer. It seems to be a bug that both slicers have.

Over at superslicer someone reported something similar, he wanted travel acceleration added as a parameter, if I remember correctly.

@Veti seems so, I guess it's bug-reporting-time

While digging around in the gcode I found that the slicer uses the following gcode to tune acceleration:

M204 S5000

According to the Duet documentation this is wrong, it should instead be

M204 P5000

since all values represent print moves.

@dc42 could you please verify my findings before I am filing a bug-report over at PrusaSlicer/Superslicer?

Sorry for not mentioning this in my original post: G-Code flavor is already on RepRap.

Hello everybody,

I am having an issue with my current delta printer running RRF 3.1.1 and acceleration control via PrusaSlicer/Superslicer.

In the slicer I can set different acceleration type values like so:

unfortunately my printer uses the default value for everything which results in quite a bit of ringing/ghosting.

The gcode flavor is already set to "RepRap".

Dropping the default acceleration to 1000 solves the issue but makes acceleration for the other features quite slow and adds up to print time.

Am I doing something wrong or is this some feature only Marlin understands?

Cheers, Markus

@dc42 you are right, that slipped my mind, my first delta printer and there is so much to learn. Thanks again!