Posts made by MiR

I think I have just the right youtuber to make you think again about not converting your nice machine:

https://www.youtube.com/playlist?list=PL0hguDEHeIJtMbYSpsPsbnc2gNPdG0nvh

Have a lot of fun with your new toy!

Michael

They do it in Fusion 360, but only for turning the laser off 8-( :
But this is easy to fix with a custom Postprocessor.

G0 S255 M4

G0 S50 M4

G1 S0

also in Fusion change is quite low as you can only define one power setting per action.

Other tools like laserweb use the S parameter in a much more aggressive way for laser raster (grbl):

G1 X0.10 Y0.10 S0.0000
X0.20 S57.4706
X0.40 S57.8562
X0.60 S58.2353

for smoothieware it uses a value between 0 und 1.0 for S :

G1 X0.10 Y0.10 S0.0000
X0.20 S0.5765
X0.40 S0.5739

This is the code created by "Grbl Laser" Postprocessor:

%
(1001)
G90 G94
G17
G21

(2D-Profil1)
G54
G0 S255 M4
G0 X24.9 Y0.3
G1 Y24.9 F1000
G1 X0.1
G1 Y0.1
G1 X24.9
G1 Y0.3

(2D-Profil2)
G0 S50 M4
G0 X62.5 Y12.5
G3 X37.5 Z0 I-12.5 F1000
G3 X62.5 I12.5
G1 S0
M30
%

from Duet Doku I see that

G94 Set units per minute feed rate mode is missing but I guess that is ok as mm/min is default for Duet
G17 Select the XY plane (for arcs) (maybe also does not matter)

Spindle on is done with G0 S255 M4
Spindle off is done by G1 S0, not sure if a M5 is needed here or not

M30 is the only strange candidate,

for grbl it is

M30 Program Pause and End

on Duet it is

M30: Delete a file on the SD card

but propably also ok because no file parameter is given.

I will try that code early next week, my Laser is not where I am right now...

Did somebody already create a Laser capable Postprocessor for Fusion360?

Hacking the GRBL postprocessor to be Duet compatible is pretty straightforward, but I do not want to duplicate work that was already done, I found one discussion via search that was about the CNC Postprocessor but It does not look like something already got implemented (and CNC and Laser mode are two (slightly) different things anyway.

I did find out today that the new laser mode is available in the 2.02 beta.

Now I am asking myself how to best use it with a CO2 power supply.

Those supplies have two inputs, one PWM or analog imput that defines laser power (called IN) and two Pins (TL and TH, one active low, one active high) to turn the laser on/off.

http://www.jnhyec.com/en/newsxx2.asp?signid=&infoid=133

What I do at the moment (I am still using smoothieware for my laser, but I am not too happy with it's performance) is that I put the IN pin to +5V (enabling full power) and then use the pwm signal from smoothie on the TH pin to contol output power.

This works well but the power supply is making quite some high pitch noises because (I guess) the Laser is switched on/off at the very high pwm frequency.

Perhaps a better way to operate the power supply would be to have the PWM signal on all the time and to turn on/off the laser with a second pin.

The function of the pin would be to switch state on every begin/end of a G1/G2/G3 , the PWM signal would go to IN and the switch pin would go to TL or TH, which ever is better for making sure that the laser does not fire on boot.

Is this something that is doable/makes sense? Did anybody already try this?

Michael

I have good WiFi connectivity, RSSI -43dBm, Broadcom chipset based router. Have upgraded to latest firmware and beta9 server, could do two small prints of 30 minutes without issue, this morning I could not reconnect. Unfortunately i accidentally turned off the pc i used for usb logging, will retry tonight.

I yesterday isolated the Duet from interference by first putting two alumnium plates on top of the printer and then placing the Duet above this metal shield, see attached picture.
Later, during a print last night I lost connectivity and could not reconnect. I tried another trick by rebooting my router to check if the Duet reconnects after the WiFi signal is back, it did not. All my other devices reconnected as usual and duet also reconnects when it is not in this 'broken' state.

David, can you please check my comments a little higher than this last comment, I‘d like your idea if what I saw is something worth following up or just a crash. At least the sympthons look exactly the same as a random crash, at keast from what I see in the logs of the router

I also have random disconnects, sometimes a few seconds after startup, sometimes shortly after starting a print. The only pattern I see is the pattern on what I see with station Info provided by my router. Besides that everything feels random, crashes after a few seconds, no problems to connect after several hours of idle after a print, I have it all

Not sure if this is helpful or something totally different:

I can now create the Ajax Errors whenever I want. Turns out that it is good enough to remove G32 and G28 from my GCode file (I reconnected the steppers), then I only need to change temperature when the printer is heating up for the 2nd layer and I get the disconnect (most likely because Duet crashes, the whole gcode behaves a little strange without the homing command)

Do you have a watchdog process running that restarts duet? In that case I am perhaps onto something, if not then what I am seeing is simply a crash that kills duet plus wifi, no more, no less.
Just in case I have uploaded the gcode here:

http://temp.michael-ring.org/D_Delta2LowerPulleys.gcode

Michael

I today disconnected the stepper motors and removed G28/G32 from the gcode file I wanted to print.
Shortly after I started the print I got a disconnect, funny thing is that the disconnect was nearly in the same moment when I changed the printer temperature. After that I was unable to reconnect and I saw:

tx failures: 3
and
rx decrypt failures: 242 in sta_info command on the router.

Is it possible that problems on the duet cause it to crash and wifi is not properly recovered in the process? One thing I read was that decrypt failures can come from a wpa2 key changing unexpectedly.

I let the printer run over night, no disconnect and the print job ran through without an issue.

What I saw this morning is that the wires of one stepper motor were running close to the wifi antenna, I will do a test tonight with stepper motor wires disconnected. tx failures are still 0 and also no decrypt errors reported by the router.

@David: Could it help when I provide remote debugging for you? I could set up a pc with windows on it that is also connected to duet's usb

I today tested latest firmware 1.20beta4+WifiServer1.20beta2, unfortunately the test ended with an Ajax error when I started printing a real file.

But, to start at the beginning, I first simply let autocalibration run for quite a while (30++ minutes) and all was fine.
Then I edited a gcode file stored on the printer, saved it and started printing the file.
Shortly after that I saw the Ajax Disconnect Error message.

RSSI Values and Noise Floor are very good, Powersave is disabled (see flags, no PS in flags) and the WiFi Card is still associated and answering fine to sta_info but the TCP-Stack is dead, cannot ping the Duet

in network 2897 seconds
flags 0x1e03a: WME N_CAP AMPDU AMSDU
per antenna average rssi of rx data frames: -39 -43 -45 0
per antenna noise floor: -95 -96 -95 0

What I see in sta_info is that after the error happend I have rx decrypt errors and one tx error, before the error decrypt failures were 0:

tx failures: 1
rx decrypt succeeds: 30153
rx decrypt failures: 144

Not sure if this means anything, at least it looks suspicious.

I have now rebooted the board and have directly started the print job, right now it runs for 30 minutes, decrypt errors are still 0 and tx failures are also 0.

Michael

Thank you very much for the plugin, I will test it when I am back tomorrow evening…

Fortunately with cura 3.0.3 and latest update from autodesk fusion directly sending a print from fusion360 to cura now works again.

This means that with your plugin I can go from fusion360 via Cura directly to the printer, without actively creating a temporary file on my computer..... Nice!

At least when I checked with sta_info about a week ago the module was reporting powersave capability to the AP

This article:

http://bbs.espressif.com/viewtopic.php?t=133

mentions a parameter for esp8266 to disable powersave on the chip itself, at least when in client-mode.

„You can use wifi_set_sleep_type to set sleep type for power saving and set NONE_SLEEP_T to disable power saving.“

@David: Could this be worth a try?

When you look at the schematics of the effector you‘ll see that the LEDs on the effector are more or less directly connected to the power supply via the mosfet for turning on the cooler for the hotend.

So the brightness of the LEDs will directly follow the output voltage of your power supply. This explains the flickering of the LEDs when you switched to PWM mode.

To solve this you could try to connect an electrolytic capacitor to the H–fan+ H–fan– pins on either the effector side or on duet side. This should even out the flickering, but will most likely leave you with a dimming of the leds when the pwm kicks in. Ths could be solved by wiring a Zener–diode in parallel to the LEDs.

But David should comment on that, my active days of building electronics are long gone.

I upgraded anyway, it took a little longer until I was unable to use the connection.

Fun thing is that I still see packet exchange between AP and duet:

RSSI: -40 dBm
TXPacketCount
176423
RXPacketCount
20352

a little later:

TXPacketCount
176799
RXPacketCount
20744

I can also still access station stats of the duet:

/cfg/system/root # wlctl -i wl0 sta_info 5C:CF:7F:37:8A:E3
[VER 4] STA 5C:CF:7F:37:8A:E3:
aid:5
rateset [ 1 2 5.5 6 9 11 12 18 24 36 48 54 ]
idle 1 seconds
in network 1857 seconds
state: AUTHENTICATED ASSOCIATED AUTHORIZED
flags 0x1e13a: WME PS N_CAP AMPDU AMSDU
HT caps 0x112c: SGI20 STBC-Rx
tx total pkts: 177054
tx total bytes: 47635359
tx ucast pkts: 23995
tx ucast bytes: 3712620
tx mcast/bcast pkts: 153059
tx mcast/bcast bytes: 43922739
tx failures: 1
rx data pkts: 21124
rx data bytes: 6136443
rx ucast pkts: 21112
rx ucast bytes: 6134771
rx mcast/bcast pkts: 12
rx mcast/bcast bytes: 1672
rate of last tx pkt: 72222 kbps - 19500 kbps
rate of last rx pkt: 6000 kbps
rx decrypt succeeds: 17064
rx decrypt failures: 88
tx data pkts retried: 0
per antenna rssi of last rx data frame: -47 -40 -41 0
per antenna average rssi of rx data frames: -46 -40 -40 0
per antenna noise floor: -94 -97 -96 0
tx total pkts sent: 23994
tx pkts retries: 2400
tx pkts retry exhausted: 1
tx FW total pkts sent: 64
tx FW pkts retries: 0
tx FW pkts retry exhausted: 0
rx total pkts retried: 2116

Are you able to turn of Powersave on the esp? I see in the stats that PS flag is set, I have seen numerous errors with Powersave on WiFi

I just upgraded to 1.19.2 and I see the same issues as described in callil's comment above.

Does it help if I do Airtraces with my Mac? If yes, should I do this with 1.19.2 or should I upgrade to 1.20 beta?

The interesting thing I am seeing is that the duett is still associated to the AP but it is not answering to pings.