Yes that is correct. 5K resistor between ground and the exp.e3stop and taking the signal from exp.e3stop to Arduino. My wiring is a complete mess so I've provided a diagram instead.
Posts made by vasparshin
-
RE: 3.2 Servo making a grinding noise on reboot/M999
-
RE: 3.2 Servo making a grinding noise on reboot/M999
As per DC42 comment, I have added a 5K resistor between the pin (exp.e3stop) and GND and my issue is solved - the voltage spike at startup/shutdown is minimized and the pin can be used to send signals to an Arduino during operation without hazard of stray signal being send from reboot.
-
RE: 3.2 Servo making a grinding noise on reboot/M999
Thank you for explaining, I will try your suggestions. Just to be clear, do you mean putting a resistor between ground and the pin I wish to use as external IO signal (not sure what you mean by pni)? Is there a benefit to using an inverter/gate VS the resistor?
Did this behaviour change from RRF 2? I do not believe this was the case before but perhaps I haven't noticed it.
Also, I just tried to use the Fan0 pins for IO control but realised why I didn't originally - I am unable to get a signal below 0.4V and it maxes out at 12V, which is too high for Arduino (with max PWM set to 40% I could make it work). I am not sure why the voltage minimum is 0.4V - is this PWM related (shouldn't be a massive issue as Arduino threshold is over 2V)?
In any case, the voltage spikes to ~3.3 for about 1 second upon reboot - same issue as with the extra IO pins. -
RE: 3.2 Servo making a grinding noise on reboot/M999
Seems like I may be having a similar issue - I am using the exp.e3stop and exp.e4stop pins on the Duet WiFi as external signals for Arduino control, I just updated to RRF release 3.2. In my config.g I have:
M950 P0 C"exp.e3stop" Q500 M950 P1 C"exp.e4stop" Q500 M42 P0 S0 F500 M42 P1 S0 F500
After reboot, for about 1 second the pins are set high, and also they try to go high after reboot has been triggered just before the shut off. You can see in this video (apologies for birds nest of wiring). I do not believe this behaviour was present on RRF 2, but since I upgraded I am not keen on reverting and for time being will try to just use some fan pins and see if they have the same issue.
-
RE: G30, G32 Issues on Duet WiFi CoreXYU with inductive probe
Can be marked as solved, thanks everyone who tried to help.
It turned out to be a kinematics related issue - changed the following:
M669 K5
to:
M669 K1 X1:1:0:0 Y1:-1:0:1 Z0:0:1:0 U0:0:0:1 ; select coreXY mode with kinematics matrix for coreXYU
and the issue is now completely solved, homing and mesh bed works as it should (the solution/proper gcode was found here)
@dc42 if you have time, any idea as to why K5 mode of M669 which is meant for coreXYU gives this weird homing issue? I have tried explicitly changing M669 K1 back to K5 with the same matrix and the issue returned, with K1 it is working normal.
-
RE: G30, G32 Issues on Duet WiFi CoreXYU with inductive probe
@Veti
Thank you for suggestions,
I have reverted to correct offset (set 0, 0 to see if anything changes), no change.
Have tried P8 instead of P5 and lowered probing speed, no difference.
Previously was on 3.0 stable and had the same issue. Might try 3.1.1 if nothing else helps.@Phaedrux
Home X (Y and U is the same code):G91 ; relative positioning G1 H2 Z5 F6000 ; lift Z relative to current position G1 H1 X-235 F1800 ; move quickly to X axis endstop and stop there (first pass) G1 X5 F6000 ; go back a few mm G1 H1 X-235 F360 ; move slowly to X axis endstop once more (second pass) G1 H2 Z-5 F6000 ; lower Z again G90 ; absolute positioning
Home Z - also sets X & Y to 0 afterwards while setting Z correctly
G91 ; relative positioning G1 H2 Z5 F6000 ; lift Z relative to current position G1 H1 Y-215 F1800 ; move quickly to Y axis endstop and stop there (first pass) G1 Y5 F6000 ; go back a few mm G1 H1 Y-215 F360 ; move slowly to Y axis endstop once more (second pass) G1 H2 Z-5 F6000 ; lower Z again G90 ; absolute positioning
Bed.g is just G29 for now
M122:
=== Diagnostics === RepRapFirmware for Duet 2 WiFi/Ethernet version 3.2-beta4 running on Duet WiFi 1.02 or later + DueX2 Board ID: 08DDM-9FAM2-LW4SD-6J1F8-3SD6P-T3W7X Used output buffers: 3 of 24 (13 max) === RTOS === Static ram: 24108 Dynamic ram: 102372 of which 48 recycled Never used RAM 3520, free system stack 190 words Tasks: NETWORK(ready,176) HEAT(blocked,308) DUEX(blocked,35) MAIN(running,379) IDLE(ready,20) Owned mutexes: WiFi(NETWORK) === Platform === Last reset 00:00:19 ago, cause: software Last software reset at 2020-12-02 12:14, reason: User, GCodes spinning, available RAM 3444, slot 0 Software reset code 0x0003 HFSR 0x00000000 CFSR 0x00000000 ICSR 0x0041f000 BFAR 0xe000ed38 SP 0xffffffff Task MAIN Error status: 0x00 MCU temperature: min 39.9, current 41.1, max 42.7 Supply voltage: min 24.3, current 24.4, max 24.6, under voltage events: 0, over voltage events: 0, power good: yes Driver 0: position 0, standstill, SG min/max not available Driver 1: position 0, standstill, SG min/max not available Driver 2: position 0, standstill, SG min/max not available Driver 3: position 0, standstill, SG min/max not available Driver 4: position 0, standstill, SG min/max not available Driver 5: position 0, standstill, SG min/max not available Driver 6: position 0, standstill, SG min/max not available Driver 7: position 0 Driver 8: position 0 Driver 9: position 0 Driver 10: position 0 Driver 11: position 0 Date/time: 2020-12-02 12:14:30 Cache data hit count 29327380 Slowest loop: 3.32ms; fastest: 0.21ms I2C nak errors 0, send timeouts 0, receive timeouts 0, finishTimeouts 0, resets 0 === Storage === Free file entries: 10 SD card 0 detected, interface speed: 20.0MBytes/sec SD card longest read time 1.0ms, write time 0.0ms, max retries 0 === Move === Hiccups: 0(0), FreeDm: 169, MinFreeDm: 169, MaxWait: 0ms Bed compensation in use: none, comp offset 0.000 === MainDDARing === Scheduled moves 0, completed moves 0, StepErrors 0, LaErrors 0, Underruns [0, 0, 0], CDDA state -1 === AuxDDARing === Scheduled moves 0, completed moves 0, StepErrors 0, LaErrors 0, Underruns [0, 0, 0], CDDA state -1 === Heat === Bed heaters = 0 -1 -1 -1, chamberHeaters = 3 -1 -1 -1 Heater 1 is on, I-accum = 0.0 === GCodes === Segments left: 0 Movement lock held by null HTTP is idle in state(s) 0 Telnet is idle in state(s) 0 File is idle in state(s) 0 USB is idle in state(s) 0 Aux is idle in state(s) 0 Trigger is idle in state(s) 0 Queue is idle in state(s) 0 LCD is idle in state(s) 0 Daemon is idle in state(s) 0 Autopause is idle in state(s) 0 Code queue is empty. === Network === Slowest loop: 16.04ms; fastest: 0.00ms Responder states: HTTP(0) HTTP(0) HTTP(0) HTTP(0) FTP(0) Telnet(0), 0 sessions HTTP sessions: 1 of 8 - WiFi - Network state is active WiFi module is connected to access point Failed messages: pending 0, notready 0, noresp 0 WiFi firmware version 1.25beta0 WiFi MAC address 60:01:94:73:61:69 WiFi Vcc 3.33, reset reason Turned on by main processor WiFi flash size 4194304, free heap 23408 WiFi IP address 192.168.31.20 WiFi signal strength -60dBm, mode 802.11n, reconnections 0, sleep mode modem Clock register 00002002 Socket states: 0 0 0 0 0 0 0 0 === Filament sensors === Extruder 0 sensor: ok Extruder 1 sensor: ok === DueX === Read count 1, 3.09 reads/min
M98 P"config.g":
HTTP is enabled on port 80 FTP is disabled TELNET is disabled Error: Invalid kinematics matrix Error: Invalid use of P parameter
Trying to figure out why kinematics matrix is invalid now, not sure what P parameter it is - is there a way to get the line number of error?
M669 gives:
Kinematics is CoreXYU, matrix: 1.00 1.00 0 0 1.00 -1.00 0 1.00 0 0 1.00 0 0 0 0 1.00
-
G30, G32 Issues on Duet WiFi CoreXYU with inductive probe
Having some very strange issues related to Z - probing using a NPN NC inductive probe on a CoreXYU running latest 3.2b4. This is the probe, and probe value reads as either 0 or 1000 when triggered. It is connected to the Duet 2 probe pins.
When G30 is called, after probing in the middle of the bed the X and Y coordinates are reset to 0.
When something like G30 P0 X20 Y50 Z-99999 F600 is called, after the probing the machine moves VERY FAST to X0 Y0 afterwards. If several of points are probed in such a way (like with G32), the movements back to 0, 0 are increasingly fast and motors start skipping.Have tried various different parameters for CoreXYU to simulate CoreXYUV as well as G1 H parameter change and G30 with different S values but nothing seems to work as it should.
Below is the config relative parts:
; Drives M569 P0 S0 ; physical drive 0 goes forwards - X M569 P1 S0 ; physical drive 1 goes forwards - Y M569 P2 S1 ; physical drive 2 goes forwards - Z M569 P3 S0 ; physical drive 3 goes forwards - E0 M569 P4 S1 ; physical drive 4 goes forwards - E1 (W) M569 P6 S1 ; physical drive 5 goes forwards - U (TMC Chip on Extrudeo Expansion Board) M584 X1 Y0 Z2 E3:4 U6 ; set drive mapping - X and Y switched to allow for correct X direction (depends on how the motors are plugged) M350 X16 Y16 Z16 E16:16 U16 I1 ; configure microstepping with interpolation M92 X160.00 Y160.00 Z3200.00 E830.00:830.00 U160.00 ; set steps per mm M566 X800.00 Y800.00 Z300.00 E1000.00:1000.00 U800.00 ; set maximum instantaneous speed changes (mm/min) M203 X5000.00 Y5000.00 Z1400.00 E5000.00:5000.00 U5000.00 ; set maximum speeds (mm/min) M201 X500 Y500 Z250 E500:500 U500 ; set accelerations (mm/s^2) M906 X1200 Y1200 Z1200 E1000:1000 U1000 I25 ; set motor currents (mA) and motor idle factor in per cent M84 S30 ; Set idle timeout M669 K5 ; select coreXYU mode ; Axis Limits M208 X0 Y0 Z0 U0 S1 ; set axis minima M208 X160 Y240 Z150 U80 S0 ; set axis maxima ; Endstops M574 X1 S1 P"xstop" ; configure active-high endstop for low end on X via pin xstop M574 Y1 S1 P"ystop" ; configure active-high endstop for low end on Y via pin ystop M574 Z1 S2 P"nil" ; configure Z-probe endstop for low end on Z homing M574 U1 S1 P"e0stop" ; Filament sensors M591 D0 P2 C"duex.e3stop" S1 M591 D1 P2 C"duex.e4stop" S1 ; Z-Probe M558 P5 C"zprobe.in" H5 F600 G31 P999 X0 Y0 Z0.2 ; set Z probe trigger value, offset and trigger height P5 M557 X0:160 Y15:240 S25 ; define mesh grid ; Heaters M308 S0 P"bedtemp" Y"thermistor" T100000 B4092 ; configure sensor 0 as thermistor on pin bedtemp M950 H0 C"bedheat" T0 ; create bed heater output on bedheat and map it to sensor 0 M307 H0 B1 S1.00 ; enable bang-bang mode for the bed heater and set PWM limit M140 H0 ; map heated bed to heater 0 M143 H0 S120 ; set temperature limit for heater 0 to 120C M308 S1 P"e0temp" Y"thermistor" T100000 B4725 C7.06e-8 ; configure sensor 1 as thermistor on pin e0temp M950 H1 C"e0heat" T1 ; create nozzle heater output on e0heat and map it to sensor 1 M307 H1 B0 S1.00 ; disable bang-bang mode for heater and set PWM limit M308 S2 P"e1temp" Y"thermistor" T100000 B4725 C7.06e-8 ; configure sensor 2 as thermistor on pin e1temp M950 H2 C"e1heat" T2 ; create nozzle heater output on e1heat and map it to sensor 2 M307 H2 B0 S1.00 ; disable bang-bang mode for heater and set PWM limit M308 S3 P"duex.e2temp" Y"thermistor" T100000 B4092 ; configure sensor 3 as thermistor on pin duex.e2temp M950 H3 C"duex.e2heat" T3 ; create chamber heater output on duex.e2heat and map it to sensor 3 M307 H3 B1 S1.00 ; enable bang-bang mode for the chamber heater and set PWM limit M141 H3 ; map chamber to heater 3 ; Fans M950 F0 C"fan0" Q500 ; create fan 0 on pin fan0 and set its frequency M106 P0 C"E0_Heatsink_Fan" S1 H1 T45 ; set fan 0 name and value. Thermostatic control is turned on M950 F1 C"fan1" Q500 ; create fan 1 on pin fan1 and set its frequency M106 P1 C"E0_Part_Fan" S1 H-1 ; set fan 1 name and value. Thermostatic control is turned off M950 F2 C"fan2" Q500 ; create fan 2 on pin fan2 and set its frequency M106 P2 C"E1_Part_Fan" S1 H-1 ; set fan 2 name and value. Thermostatic control is turned on M950 F3 C"duex.fan3" Q500 ; create fan 3 on pin duex.fan3 and set its frequency M106 P3 C"E1_Heatsink_Fan" S1 H2 T45 ; set fan 3 name and value. Thermostatic control is turned off M950 F4 C"duex.fan4" Q500 ; create fan 4 on pin duex.fan4 and set its frequency M106 P4 C"Chamber_Fan" S1 H-1 ; set fan 4 name and value. Thermostatic control is turned on M950 F5 C"duex.fan5" Q500 ; create fan 5 on pin duex.fan5 and set its frequency M106 P5 C"Chamber_LED" S1 H-1 ; set fan 5 name and value. Thermostatic control is turned off M950 F6 C"duex.fan6" Q500 ; create fan 6 on pin duex.fan6 and set its frequency M106 P6 C"Electronics_Fan" S1 H-1 ; set fan 6 value. Thermostatic control is turned off ; Tools M563 P0 D0 H1 F0 ; define tool 0 G10 P0 X0 Y0 Z0 ; set tool 0 axis offsets G10 P0 R0 S0 ; set initial tool 0 active and standby temperatures to 0C M563 P1 D1 H2 F0 ; define tool 1 G10 P1 X20 Y0 Z0 ; set tool 1 axis offsets G10 P1 R0 S0 ; set initial tool 1 active and standby temperatures to 0C
Any advice would be much appreciated, as I can not seem to find a similar issue on the forums.
-
RE: Gcode Meta Commands for sensing filament
Hi, has this been implemented yet?
-
RE: E0 always on
If you disconnect the E0 heater wiring from the Duet, does the E0 led still stay on?
Are you certain that the back of the board isn't shorting against anything?
If the answers to the above are yes and yes then it sounds like a fault on the board, which could be diagnosed using a multimeter.
I've disconnected everything from the board and taken the board of the mount and it still has the same issue. Could you help me diagnose it? I have a basic multimeter. Thanks
Edit Quote Answer Delete Report
-
E0 always on
I have a strange problem with my duet 0.8.5 running 1.18 dc42 fork. The e0 is permanently on from the moment the board is powered on. This issue seemed to occur after messing with the source voltage (changing 12v to 24v and back) as well as erasing and reflashing the firmware (i managed to heat up the hotend and stop the heating fine before that). The weird part is that the e0 is on regardless of whether the SD card is in or not which makes me think that it is a wiring problem independent of the gcode. The e0 LED is also permanently on. I have tried to reflashing the firmware again and changing the Vin to 24V and back as well as changing the config.g (very new to gcode so probably didn't make a difference).
Can someone advise me if this is a software/hardware fault and how i would go on about resolving it? At the moment I've changed the gcode so that I can use the second extruder but it's a messy solution as i have to set the temperature of the first one to heat it (using paneldue).