Posts made by Skimmy

@dc42 If I execute stop.g via M0 at the end of my gcode-file, is it ok to have M0 inside of stop.g again to shut off the heaters?

I did an extensive code-check and talk with CR3D and also didn't come to a solution.

For example: a 5-point bed-calibration works fine (a G32 (call to execute bed.g with 5x G30 in it)

Every G30 command works, but as soon as you start a G29, things start getting weird.

ah, thx for clarifying. Then, the docu is a bit misleading

https://duet3d.dozuki.com/Wiki/Gcode#Section_M569_Set_motor_driver_direction_enable_polarity_and_step_pulse_timing

Dnn (firmware 2.0 and later, only applies to TMC2660 and TMC22xx stepper drivers) Driver mode: 0=constant off time, 1=random off time, 2=spread cycle, 3=stealthChop or stealthChop2. The default is spreadCycle for TMC2660 drivers and stealthChop2 for TMC22xx. In stealthChop mode the drivers will switch over to spreadCycle automatically at high speeds, see the V parameter.

If I do send

M569 P0 S0 D3

via console, I get the error message:

Error: M569: Driver 0 does not support mode 'stealthChop'

But the docs clearly say that the DUET uses TMC2660 and lists TMC2660 as stealth chop capable. Am I missing something?

Im running the latest firmwares with a DUET + DUEX5:

Firmwarename: RepRapFirmware for Duet 2 WiFi/Ethernet
Firmware Elektronik: Duet WiFi 1.02 or later + DueX5
Firmware Version: 2.02(RTOS) (2018-12-24b1)
WiFi Server Version: 1.22
Web Interface Version: 1.22.6

@martin1454 said in Feedback about this nozzle:

From what I have seen from others, it really works well - just as long as it is not made by the chinese.

To be fair, my "original" airbrush adapters are made in china, too. I just had to find the quality supplier!
On the way to this, I got more than 300 bad nozzles, just with some measurement off or leaking or such.

Any idea what to do with it? XD XD

Title says it all. I broke it.
I touched the back of the board with an active 24V wire. The only function the board still has: When I power it via USB, the 2 LEDs for 5V light up.
What to do with it now? I don't want to throw money at it to get it repaired (unless it is <50€ in total). But can someone do something with it? Salvaging parts or stuff? I am willing to ship it worldwide for 6,20€.

Hello!

I would like to talk about how best to assign several heaters to one tool. I want to create heating zones of different temperatures on a single tool.

Currently I solve this with a second or even third "dummy" tool by assigning it another "standby" temperature.

I would like to talk to you about how you handled this.

Before bricking my beloved DUET with bad wiring and testing it on my own, I would rather ask to do it right:

In case I want to add an external reset-button, is it ok to pull PIN44 of the extension header to GND via a simple microswitch? And, in addition, do I need a debounced switch or will any generic do?
Do I need to add a pull-down resistor or is it already done in the CPU like on arduinos?

I did test it via macro.

This did not work:

[[language]]
; SetNetwork macro to set up access to dummy test Wifi network
M552 S0;
G4 S5;
M589 S"test123" P"test123" I192.168.178.250;
G4 S5;
M552 S2;

This works everytime:

[[language]]
; SetNetwork macro to set up access to dummy test Wifi network
M552 S0;
G4 S5;
M589 S"MEINDUET" P"MEINWIFI" I192.168.178.250;
G4 S5;
M552 S2;

Noticed, that since using RC3, changing from M552 S2 over M552 S0 to M552 S1 doesn't work sometimes.
Using the makro:

[[language]]
M552 S0;
G4 S5;
M552 S1;

sometimes results in:

[[language]]
WiFi module  is idle Failed to change WiFi mode (code -7)

executing the macro or M552 S1 again does work in this case.

@dc42:

Have you tried firmware 1.21RC3 yet? I made a change that should improve it, see the release notes.

I updated to RC3 on firmware and webserver, and RC4 on the interface, and a quick test with:

[[language]]
M589 S"test123" P"test123" I192.168.178.250;

didn't work. Back to all capital letters and 8 per parameter and it is functional again.

short feedback:
I was not able to install the combined-firmware file conveniently. I needed to rename it to "…WiFiFirmware" to get it to install automatically. Upgraded from RC2 to RC3.
otherwise, everything works like expected.

Ok, i fiddled around this evening and found out, that the accesspoint works EVERY TIME, when using:

8 caps letters for SSID and 8 caps letters for the password. Example:

[[language]]
M589 S"MEINDUET" P"MEINWIFI" I192.168.178.250;

As soon as the SSID contains lowcase-letters or numbers, it doesn't work anymore. Same for the password. And using less or more digits than 8 doesn't work too.

Haha, found the bug with "Geschwindigkeit" by myself… Another funny "fault" is the german translation for "invert display". It translates to "Farben invertieren" what means "invert colors". Correct translation would probably be "Anzeige invertieren". Maybe you could add this to some bug-reporting list if you like

@dc42:

Even though I haven't yet been able to reproduce this, I've added it to the list of issues to investigate before the 1.21 firmware release.

ok, thank you.

I did remove all M586 commands, but everything is still the same.

Is there a way to call a macro automatically after boot up? This way I could force to load a macro with M552 S2 in it after the boot up…

ok, changed config.g to:

[[language]]
; network
M586 P0 S1                      ; Enable HTTP
M552 S2                         ; Enable network
M586 P1 S0                      ; Disable FTP
M586 P2 S0                      ; Disable Telnet

Restarted (from the prompt in the webinterface after changing the config). Then:

[[language]]
SENT: M552
READ: WiFi module is idle

If I put M552 S1, the Duet connects to my homenetwork, if I put M552 S2, the duet starts the accesspoint (wifi module is providing accesspoint…).
But it does not start it on its own after bootup.

Currently running (downloaded today):

[[language]]
Firmware Version:	1.21 RC2 (2018-02-15 build 2))
WiFi Server Version:	1.21 RC2 
Web Interface Version:	1.20

I configured M589 like said here , like so:

[[language]]

file config.g:
; network
M552 S0 ;
M589 S"MY_PRINTER" P"psswrd123456" I192.168.2.100 ;  access point
M586 P0 S1                      ; Enable HTTP
M552 S2   

But this only works, when I send "M552 S2" AGAIN via console, after the board booted. I did put "M552 S2" into the config.g, but appearently, this doesn't help?! Do I have to put the M552 S2 somewhere else?
Before I do send M552 S2 via console, the DUET creates an unsecured network called "AI-THINKER_0AEB5B", which I can connect to, but can not reach the web-interface. After sending M552 S2, the network "MY_PRINTER" is available (and the blue LED on the wifi-module is on) and the "AI-THINKER…" network disappears.

Does "a little" mean: "after the currently executed commands are done"? Or does the DUET interrupt mid-command?

Can someone specify a bit more in detail what is going to happen AFTER executing an M112 midprint or mid-homing or something else?
I assume, every command in the bugger is getting executed UNTIL the internal gcode buffer reached the point where M112 is listed? This way, it is more like a delayed stop?! (just assuming)
What if M112 is executed while homing? Or a long G1-move?

If I may "hijack" this thread, bc it relevant for my topic. I do drive a big Delta with NEMA23 motors and set the drivers to 1500mA. I do blow along the board (above and beneath) with a big 80mm fan on one side, and a "pulling" 80mm fan on the other. This alone leads to thermal shutdown of one or more drivers after several hours of printing. I did put some small self-glueing heatsinks on the underside and now it doesn't overheat anymore.
Now I am wondering, if I do something wrong via config? Because everything I read about the cooling states, that I should be good with minimal airflow.