Posts made by rmriggin

@dc42 did my first ever hot air chip removal and install and I am pleased to report that it is working perfect again! Thank you!

@dc42 would either of these work?

https://www.digikey.com/product-detail/en/texas-instruments/SN74HCT02DR/296-14861-1-ND/562563

https://www.digikey.com/product-detail/en/texas-instruments/SN74HCT02PWR/296-31831-1-ND/3506070

@dc42 I just noticed that I had been running the fans on 5v rather than system voltage. Changing the jumper to the system voltage and fans are working again so I guess what was powered by the 5v would have been the hotend fan, part cooling fan, and paneldue. I can still communicate with the printer and connect to the web control although I have not tried directly connecting to the priner via the micro USB port. The heaters still all turn on full blast when the board is powered on so at the moment I have disconnected the hotend and bed heater.

My duet wifi v1.04 running 2.02RC4 heaters started acting up. As soon as the printer is powered on the bed and hotend heaters turn on at seemingly max power output and temps keep climbing until thermal protection kicks in. I also noticed that my paneldue screen no longer displays... while typing this I just checked the paneldue control board and the 5v input mosfet is blown... could it have taken out the 5v output on the duet and if so how could that cause the heaters to be stuck on?

@dc42 the hotend temp reads lower than it should currently sitting in room where ambient is about 68F it's reading at 0 to -1-2 C. I used the default values for the firmware thermistor config at the duet firmware config page. The bed temp sensor values are between 80-90C regardless of whether there is a sensor connected or not. When sensor is disconnected for hotend it reads the expected 2000F.

My Duet .6 running 1.22 is reporting a temp of 90C with or without a sensor connected. The MCU temp reported is around 32 C which is more in line with ambient temp and what the bed typically would report when I have used other boards (RAMPS 1.6/Marlin 1.1.9, MKS SBASE 1.4). So it appears there is an issue with the thermistor input for bed but I have no idea of how to troubleshoot/test that theory.

@dc42 said in Firmware 2.0RC1 and 1.21.1RC1 released:

@rmriggin said in Firmware 2.0RC1 and 1.21.1RC1 released:

Just updated to the latest 2.0 RC and had a print just stop with no error or message 6 hours into a print. Print looked excellent and came back to it and it was just stopped with print head still over the print like it just stopped in the middle of a layer. The bed and nozzle were not at temp still either. I'll have to lookup the and to pull log and see if it shines any light on what happened.

I'm sorry to hear that you had a crash. It's possible that you hit the bug reported by @BMMal in the second post in this thread. Please can you run M122 and post the software reset data from that report.

@dc42 it happened again at the same height into a print (25mm)

M122
=== Diagnostics ===
RepRapFirmware for Duet 2 WiFi/Ethernet version 2.0(RTOS)RC1 running on Duet Ethernet 1.02 or later
Board ID: 08DDM-9FAMU-JW4S4-6JKD4-3SJ6R-92YRV
Used output buffers: 3 of 20 (9 max)
=== RTOS ===
Static ram: 28484
Dynamic ram: 95388 of which 16 recycled
Exception stack ram used: 324
Never used ram: 6860
Task NETWORK ready, free stack 448
Task HEAT blocked, free stack 1260
Task MAIN running, free stack 3800
=== Platform ===
Last reset 07:41:11 ago, cause: software
Last software reset at 2018-05-11 01:00, reason: Hard fault, spinning module GCodes, available RAM 6516 bytes (slot 3)
Software reset code 0x4033 HFSR 0x40000000, CFSR 0x00010000, ICSR 0x0441f803, BFAR 0xe000ed38, SP 0x200049dc
Stack: 00444d4f 00424f82 61000000 0042afda 21000000 0000000a 20000180 200001e0 00000000 000000f8 00000000 00000000 2000b3c8 2000a480 00000000 000000f8 20004cf4 a5a5a5a5 a5a5a5a5 a5a5a5a5 00424fc3 2000b3c8 0042afe1 00000000
Error status: 0
Free file entries: 10
SD card 0 detected, interface speed: 20.0MBytes/sec
SD card longest block write time: 0.0ms
MCU temperature: min 46.2, current 46.7, max 54.8
Supply voltage: min 24.1, current 24.2, max 24.4, under voltage events: 0, over voltage events: 0
Driver 0: standstill, SG min/max not available
Driver 1: standstill, SG min/max not available
Driver 2: standstill, SG min/max not available
Driver 3: standstill, SG min/max not available
Driver 4: standstill, SG min/max not available
Date/time: 2018-05-11 08:41:38
Slowest main loop (seconds): 0.006040; fastest: 0.000069
=== Move ===
Hiccups: 0, StepErrors: 0, LaErrors: 0, FreeDm: 240, MinFreeDm 240, MaxWait: 0ms, Underruns: 0, 0
Scheduled moves: 0, completed moves: 0
Bed compensation in use: mesh
Bed probe heights: 0.000 0.000 0.000 0.000 0.000
=== Heat ===
Bed heaters = 0 -1 -1 -1, chamberHeaters = -1 -1
=== GCodes ===
Segments left: 0
Stack records: 1 allocated, 0 in use
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
serial is idle in state(s) 0
aux is idle in state(s) 0
daemon is idle in state(s) 0
queue is idle in state(s) 0
autopause is idle in state(s) 0
Code queue is empty.
=== Network ===
Responder states: HTTP(0) HTTP(0) HTTP(0) HTTP(0) FTP(0) Telnet(0) Telnet(0)
HTTP sessions: 1 of 8
Interface state: 5
=== Expansion ===

@dc42 misread the command and did a M112 which cleared log so I guess I won't know what caused that print failure.

Just updated to the latest 2.0 RC and had a print just stop with no error or message 6 hours into a print. Print looked excellent and came back to it and it was just stopped with print head still over the print like it just stopped in the middle of a layer. The bed and nozzle were not at temp still either. I'll have to lookup the and to pull log and see if it shines any light on what happened.

So far so good with the latest release. On the last one I would have long prints with large file sizes fail with an unable to read source error. I do all my printing using the web interface and uploading there BTW. I don't know if I finally have my printer dialed in or just better filament but I'm getting the best prints I have had to date. Forgot to mention, I am using a Duet Ethernet.

Following the CoreXY config guide all movement per wiki guide steps are correct x movement test moves x and y in positive direction and y movement test x moves in positive direction and y in negative. X and Z homes correctly but Y homes in the opposite direction. X Y and Z move in correct direction when manually jogged. So the issue is that while Y will move in the correct direction, it homes in the opposite direction. I’m using normally closed switches in the min position on all axis.
On a separate note, using the online firmware tool does not give the enstop location selection option (they are visible but greyed out).

@dc42:

It sounds to me that you have a short in the cable or the sensor between the +3.3V and ground pins.

Of all things it ended up being the 5V/INPUT VOLTAGE jumper not being seated/making connection

Sensor works now but the only issue I am having is that there is no LED whatsoever. In the web control I can see the z probe change values when probing but the LED indicator on the piezo board does not illuminate whatsoever. I have attempted to provide 5v and ground to the LED pins on the board to no avail.

A version with the duet with the tmc2130 and the ability to do sensor-less homing would be a godsend IMO.

@DjDemonD:

Can you measure the resistance between 3.3v and GND on your duet board (is there a nominal value? I'd measure mine but I'm away from home). If its happening with ir sensor and piezo sensor it's not likely to be the sensors that are both shorted.

I get a steady 3.3v when checked with my meter on all of the 3.3v pins. I get no resistance reading between ground and the 3.3v pins however.

seems to be an issue unique to my duet board because when testing with another sensor (dc42 ir sensor) the same issue occurs. Also tested with an inductive sensor and the same problem. If I use the 3.3v VIN on any endstop pin or the z probe pin on the duet I end up with the board dying (for lack of a better explanation) until I unplug the wire from whatever 3.3 VIN port its connected to.

I have an odd issue in that if I have anything connected to the VIN pin on any endstop or the probe connector the duet becomes unresponsive until I unplug the VIN wire regardless of using the VIN pin on the z endstop connection or the z probe connection. Any ideas?

With the exception of mine having been in commission I'm now having the same issue you are

@dc42 M552 S1 command get accepted then console reads out M105 ten times an then loses connection and reboots and ethernet interface does not activate.

another issue I am having with it is that the z axis will not home. When selecting z home on the paneldue or in s3d the z axis moves in the opposite direction (up) and stops after traveling 50mm in the opposite direction of the z axis endstop. x and y homing works properly and goes to the endstop limit and stops.

it remains lit. A little update. I formatted the sd card and reloaded it with the default sd card files and renamed the sys-prusai3 to sys and the board now boots. However if I try to load my config created with the configuration tool it will not boot from the sd card. So as it is right now it will only boot in a usable state if it is loaded with a default config.g. I tried doing a print and despite being able to heat the bed and nozzle it seems confused as to what direction it is homing in despite the endstops working and triggering correctly via the indicated board lights for the endstops. I am using active high for endstops with x y and z being placed at low end but if I try to add the endstop config to the config.g it will not boot from the sd config (M574 X1 Y1 Z1 S1 ; Define active high microswitches). Also the ethernet module does not come online. Seems like it may be time for a warranty inquiry