Duet not extruding on x axis and panel due has no screen
-
Still difficult to tell from the video but I'd say David's assumption is probably correct. The fact that it has done a small cube near the centre of the bed, where the bed height probably doesn't vary that much ( due to the small size) would bear that out. The larger the object, the more any inaccuracies in bed level will show up. It may also just be a case of poor first layer adhesion by perhaps too low a bed temperature. In any case, I'd say it's almost definitely a mechanical issue.
Ref the relative/absolute extrusion thing. Most people choose to use relative extrusion but it's not obligatory. The important thing is that the slicer and Duet are both set to the same. If the slicer is set to use relative extrusion, then you need to set the Duet to relative using M83 in your config.g. Conversely, if the slicer is set to absolute then you need to set Duet to absolute by using M82 (instead of M83).
-
Preferably, include the M83 or M82 in your slicer start gcode, then it doesn't matter what the setting in config.g is.
-
I'll check the slicer code and see if it changes but for the bed level the second video is printed hovering 20mm off the bed doing the same issue so bed level wouldn't be a factor since it's not near the bed and there is no filament pushing thru the extruder but I'll reset my config g file and see if that was my issue all along
-
Also I couldn't get it to print the cube again that failed too
-
If it's printing 20mm off the bed, then perhaps Z homing isn't always stopping at the correct height.
I only saw a link to one video in your earlier post.
-
I re tried the m82 and m83 commands with the print head off the bed with resliced files and same thing extruder stops in same places
-
Like David, I saw the one video file. From your description, it's sounding like you have a bad connection on your extruder stepper motor wiring.
-
I have to go to work in a little bit but when I get home I will run a new stepped motor wire straight from the extruder to the duet bypassing the cable chain and see if it changes I have two extra connectors and extra pins from the original parts when I got the duet
-
Ok so I got home from work and completely removed the motor except for the extruder gear and ran a new jumper from the duet to the motor and it appeared to fix the issues as the gear seemed to run smooth so I guess I'm gonna delete my cable chain altogether because I'm assuming it pinched one of the coil wires I do really appreciate y'alls time helping me with my issue I know y'all are busy people and have always answered my questions super fast I constantly recommend this board to people on the forums I belong too and not just the product but your service behind it but one last question is it possible to run 2 wifi boards or would it be better to run the Ethernet version on the other I'm building a new build it's a long way off from electronics yet but I want to use a duet board on it ?
-
It is no problem to run two Duet Wifi boards on the same network, or one Wifi and one Ethernet. Or two Ethernets even.
-
The problem with your cable chain probably isn't that the wire is being pinched, it's probably a poor crimp connection at one end, that does or doesn't make contact depending on which way the wire is pulled.
If you put two or more Duets on the same network, they must all have different MAC addresses. The WiFi does this automatically. For the Ethernet you need to use the M540 command in config.g to change all but one of them from the default.
-
Glad you got it fixed and yes, as David pointed out, don't give up on the cable chain. It's most unlikely that all the strands of the wire broke somewhere in the middle of the run, but much more likely that it was poor connection at one end.
-
Actually I believe I spoke too soon I started everything back up was trying to make sure everything homed and moves like it should and it did then I shut everything down to make sure the bed was still level I fired it back up and the x motor started skipping back and fourth across the rail wildly and no extruder again so I'm at a loss I know all the pins are good I checked them tried swapping motor wires with the y axis cause it seemed ok and tried to move the x again it started jumping around again I have no Idea where to even start now cause it acts perfect then it freaks out and starts weirdness I've tried fighting with it since about 8 pm it's now 3:44 am and it act fine then something will act up sorry for the the trouble but I've ohm'd wires checked connections checked voltages and schematics and it will do what I ask it then I try to repeat and it goes nuts for some reason
-
Intermittent faults are always a pain. You haven't mentioned your Panel Due since the first post. Is that working as it should or do you still have problems with that too?
-
No the panel due still no screen but I can hear the sound of the buttons being pressed when I touch the screen and the fault isn't internment anymore I tried using the motor cable from one of the z axis motors to the x motor cause I know the z axis moves like it should and nothing anymore x or e motors you can feel them get there holding tourqe but no movement at all I tried using the x motor cable on the z axis to see if it did the same and it moves like it should just fine same with y axis motors
-
I've tested a little more and the x axis will move now dont know why its the same motor wire from the y i was testing it with i have the motor out just sitting on the machine same with the e didn't but nothing on e still at all no matter what can't even feel the motor engage to hold it in place
-
It's very difficult to diagnose from a distance. I'm wondering if it's a power supply issue. Maybe it's only just able to supply a small amount of power so that when you try to drive one or more motors, the voltage drops. Are you able to measure the voltage at the input terminals of the Duet? Preferably when you try to drive a motor. Also, after you've tried to move the extruder and X axis motor, could you run M122 and post the results of the diagnostics. I, or more likely David, might be able to spot something in that.
-
Ok will will measure the terminal voltages and run the M122 command and post the findings to you I will have to do it in just a little bit as I have to finish up an animation so I don't get behind on it but I will do it as soon as possible again thank you
-
ok i finished my work and started back looking at the printer i found the problem with the x motor is the cheap cable wire that was supplied with the printer i made a new one with some better wire like i did for the e motor and its working fine again so i ordered quality wire for all the motors (it kinks if you look at it worng) as that too is going to get replaced immediately so that issue is solved wire will be here monday. as for the e motor even with a new cable i get nothing i also remapped to the e1 driver and still got nothing tested with 2 different cables and 2 different motors on both drives same results with both test. i checked the voltage at the duet terminals and it was at 11.99v so the voltage looks good and this was what i got when i ran the M122 command
8:00:34 PMM122
=== Diagnostics ===
Used output buffers: 1 of 32 (4 max)
=== Platform ===
Static ram used: 20320
Dynamic ram used: 72784
Recycled dynamic ram: 1104
Stack ram used: 968 current, 2940 maximum
Never used ram: 33924
Last reset 00:01:22 ago, cause: power up
Last software reset code 0x0003, HFSR 0x00000000, CFSR 0x00000000, ICSR 0x00400000, BFAR 0xe000ed38, SP 0xffffffff
Spinning module during software reset: GCodes, available RAM 33576 bytes (slot 0)
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 32.8, current 37.1, max 40.0
Supply voltage: min 11.9, current 11.9, max 12.3, under voltage events: 0, over voltage events: 0
Driver 0: standstill
Driver 1: standstill
Driver 2: standstill
Driver 3: standstill
Driver 4: standstill
Date/time: 2017-05-20 20:00:34
Slowest main loop (seconds): 0.002307; fastest: 0.000035
=== Move ===
MaxReps: 0, StepErrors: 0, MaxWait: 0ms, Underruns: 0, 0
Scheduled moves: 0, completed moves: 0
Bed compensation in use: none
Bed probe heights: 0.000 0.000 0.000 0.000 0.000
Probe change coordinates:
=== Heat ===
Bed heater = 0, chamber heater = -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
Code queue is empty.
=== Network ===
WiFiServer is running
SPI underruns 0, overruns 0
=== Webserver ===
HTTP sessions: 1 of 8 -
Ok I did get e1 to work for some reason it didn't assign the number in the config g file when I gave the command so I went back and tested both e0 and e1 and e1 works as should e0 nothing but it's still strange because from my understanding of the m122 command it didn't show any fault at least that I read in it
