Best posts made by toskium

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