At the faire I would have had it switch to wifi hotspot and at home it would have gone back to connecting to my home wifi, so it was more than on/off (if that's a clue)
I might try upgrading that but it'd be another band-aid. This problem has been popping up for years now and, like with me, the last time "it just went away" and was no longer pursued but it keeps re-occurring. That's the part that makes it frustrating.
This has come up before but I've never seen a satisfying solution to this. For a long time I was uploading my files at 600Kibs plus speeds. I took my Printer to a faire and when I hooked it up again (after MRRF was canceled). my upload speeds went down to 40Kibs again. I've tried different routers in different locations (NetGear and Asus). I've tried changing channels with no results.
M122 P104 S200 gives me 2Mbytes/sec so the SD card isn't the problem either. Has anything else come up since all the previous upload issue posts have been idled? Thx
Firmware Name: RepRapFirmware for Duet 2 WiFi/Ethernet
Firmware Electronics: Duet WiFi 1.02 or later
Firmware Version: 2.04RC1 (2019-07-14b1)
WiFi Server Version: 1.23
Web Interface Version: 1.22.5
@zapta said in Filament Sensor plus timelapse issue:
It was powered by the E0 end stop. I don't know (yet) where the Duet 3.3v rails starts and ends. Only the signal came from the CS5 pin.
@zapta Sorry, this goes beyond my expertise. This is the relay I used The relay I'm using is this guy: https://www.amazon.com/gp/product/B01M0E6SQM
I did not add anything additional to this. I did just read about the power spike. One would think that when you buy a unit like this it's built in. Then again...
@t3p3tony I have no scientific equipment to validate this but I did go through some 12 attempts of the same benchy with different parameters and all failed as the exact point in the macro (different layers), right after
M42 P60 S255
The relay I'm using is this guy: https://www.amazon.com/gp/product/B01M0E6SQM
VCC and GND on relay came from E1 end stop, signal came from pin CS5
So for the many tries with different values, it was always the same story. As M42 P60 S255 was executed (at random layers changes) the filament sensor would error out. I can only conclude a "power spike/drop" when powering a relay (3v) to trigger the camera remote was causing this issue.
I've now redesigned my remote setup and eliminated the relay. The remote is now directly powered via pin CS5 (P60). It now correctly finishes my print and I tested the sensor for stall and all seems to be working.
I wonder though if it would be possible to check for multiple consecutive before completely stopping the print. Once the power fluctuation is over all works well again.
case TypeLaserMessageTypeError:
lastErrorCode = val & 0x00FF;
sensorError = true;
break;
I'm good for now. Thanks for responding.
@t3p3tony the cable is long (about 3 meters) but the problem only occurs when I run the snapshot code. The error must occur between:
;turn on shutter and wait 800ms
M42 P60 S255
G4 P800
;turn off remote
M42 P60 S0
as I find the M42 P60 S0 never executed (camera stuck taking pictures).
The relay controlling the camera is powered by E1 end stop (could it cause a power drop next door?).
The cable to the sensor is separated from all other cables running to Smart Effector.
I think I'm running into a problem with my Duet Filament Sensor Laser combined with taking images at every layer change.
following is my image taking code (executed at every layer):
G60 S1
G91
G1 Z40 F9000
G90
G1 X0 Y0 F9000
;turn on shutter and wait 800ms
M42 P60 S255
G4 P800
;turn off remote
M42 P60 S0
;based on bad lighting give time for picture to be taken.
G4 P2000
;return to last stored position
G1 R1 X0 Y0 Z0 F3600
Basically I'm taking a 3 second break every layer and I think this messes up the Filament sensor and averages of moved filament. I get filament sensor failed errors.
Is there anyway to avoid this?
current M591: M591 D0 P5 C3 R90:120 E6.0 A0 S1
I tried playing with the A parameter switching from A1 to A0 and changing parameter E from e3 to e6
Also, error says: Extruder 0 reports sensor not working
What triggers that error (it's different from the jam/filament out error)
@dc42 Thx, M84 U followed by G92 U0 does the trick
@dc42 Okay found the solution (or I should say the cause to the problem). My printer, the crazy Delta one with a moveable bed, uses a 4th axis defined as U. Since it's defined as U it becomes part of the homing process. The problem is that U is used only a few times a year (mostly at shows) but runs hot every time after it homes.
Because of that every print of mine starts with M84 U (to shut it down). This the cause of the problem.
All code has DoFileMacro(gb, PAUSE_G, true); made conditional with AllAxesAreHomed()
because of M84 U they are not and thus pause.g is not executed.
I'll have to do something else to stop U from overheating.
@dc42 any way to turn on full blown debugging?
@dc42 confirmed. I did try to put a pause.g under macros to chain call the pause.g under sys. Didn’t help either
@doctrucker tried that (renamed to Pause.g) did not change anything. Thx
@core3d-tech move all files to different SD card which made no difference. I took a video (shorter one this time) of the process
M98 P"pause.g" DOES execute it properly.
Here is my config.g:
; Configuration file for Duet WiFi (firmware version 1.21)
; executed by the firmware on start-up
;
; generated by RepRapFirmware Configuration Tool v2 on Sat Nov 17 2018 21:05:24 GMT-0600 (Central Standard Time)
; General preferences
G90 ; Send absolute coordinates...
M83 ; ...but relative extruder moves
M665 R182 L360 B150 H1240 ; Set delta radius, diagonal rod length, printable radius and homed height
M666 X0 Y0 Z0 ; Put your endstop adjustments here, or let auto calibration find them
M584 X0 Y1 Z2 E3 U4 ; using extra stepper using the second extruder driver
; Network
M550 P"C3Dt/bd" ; Set machine name
M552 S1
;M552 S2 ; Enable network
;*** Access point is configured manually via M587
M586 P0 S1 ; Enable HTTP
M586 P1 S1 ; Disable FTP
M586 P2 S1 ; Disable Telnet
; Drives
M569 P0 S1 ; Drive 0 goes forwards
M569 P1 S1 ; Drive 1 goes forwards
M569 P2 S1 ; Drive 2 goes forwards
M569 P3 S0 ; Drive 3 goes backwards
M569 P4 S0 ; Drive 4 goes backwards
M350 X16 Y16 Z16 E16 U16 I1 ; Configure microstepping with interpolation
M92 X80.00 Y80.00 Z80.00 E415.00 U100 ; Set steps per mm
M566 X600.00 Y600.00 Z600.00 E1200.00 U400 ; Set maximum instantaneous speed changes (mm/min)
M203 X30000.00 Y30000.00 Z30000.00 E1200.00 U6000 ; Set maximum speeds (mm/min)
M201 X8000.00 Y8000.00 Z8000.00 E1000.00 U1000 ; Set accelerations (mm/s^2)
M906 X2100.00 Y2100.00 Z2100.00 E800.00 U600 I30 ; Set motor currents (mA) and motor idle factor in per cent
M84 U S10 ; Set idle timeout
; Axis Limits
M208 Z0 U0 S1 ; Set minimum Z and U
M208 U85 S0 ; set maximum U to 85
; Endstops
M574 X2 Y2 Z2 S0 ; Set active high endstops
; Z-Probe
M558 P5 R0.4 H10 F2400 T6000 ; Set Z probe type to effector and the dive height + speeds
;*** Remove this line after delta calibration has been done and new delta parameters have been saved
G31 P100 X0 Y0 Z-0.1 ; Set Z probe trigger value, offset and trigger height
M557 R145 S40 ; Define mesh grid
; Heaters
M305 P0 T100000 B4138 R4700 ; Set thermistor + ADC parameters for heater 0
M143 H0 S160 ; Set temperature limit for heater 0 to 160C
M305 P1 T100000 B4138 R4700 ; Set thermistor + ADC parameters for heater 1
M143 H1 S280 ; Set temperature limit for heater 1 to 280C
;bed pid
M307 H0 A90.0 C700.0 D10.0 S1.00 V0.0 B1
;volcano pid
;M307 H1 A630.3 C313.2 D5.9 S1.00 V21.6 B0
;e3d pid
M307 H1 A521.7 C247.7 D2.8 S1.00 V22.3 B0
; heater fault detection
M570 H1 P30 T30
; Fans
M106 P0 S0.0 I0 F500 H-1 ; Set fan 0 value, PWM signal inversion and frequency. Thermostatic control is turned off
M106 P1 T45 S0.999 ; Set fan 1 value, PWM signal inversion and frequency. Thermostatic control is turned on
M106 P2 L230 T40:65 H100:101:102 ;controller fan turn on when MCU reaches 40Celcius or when TMC26.. report over temp
; Tools
M563 P0 D0 H1 ; 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
; Automatic power saving
M911 S10 R11 P"M913 X0 Y0 G91 M83 G1 Z3 E-5 F1000" ; Set voltage thresholds and actions to run on power loss
;load detailed z-probe file
G29 S1
; set the laser filament monitor
M591 D0 P5 C3 R40:120 E3.0 S0
; Custom settings are not configured
; turn off camera pins (from 3.3 to 0)
M42 P60 S0
M42 P61 S0
M501
Here is my pause.g:
; pause.g
; called when a print from SD card is paused
;
; generated by RepRapFirmware Configuration Tool v2 on Sat Nov 17 2018 21:05:25 GMT-0600 (Central Standard Time)
M83 ; relative extruder moves
G1 E-10 F3600 ; retract 10mm of filament
;move hot end up
G91 ; relative positioning
G1 Z20 F6000 ; lift Z by 20mm
G90 ; absolute positioning
G1 X0 Y-150 F6000 ; go to X=0 Y=0
@dc42 Thanks got getting back, I've moved it to the other thread https://forum.duet3d.com/topic/11598/pause-g-is-not-working/2
@t3p3tony that is exactly what happens. all actions that result in M25 DO NOT execute the pause.g
Like you said and as the video shows, the m25 will stop the hot-end but nothing else. None of the pause.g code is executed (I've also put a M291 in pause.g to see if it would pop up something).
This applies to all pause actions:
Pause from PanelDue
Pause from Web interface
Pause from filement sensor.
The M25 you see in the log above comes from pressing pause (I've actually no called M25 directly from console). The log above is the output from M111 P3 (it captures all gcodes)
I will try what @dc42 suggested and move things over to another sd card. That said, it did also delete the pause.g from web interface and recreated it to see it that made a difference yesterday. It did not.
I posted earlier about my filament sensor not executing the pause.g
https://forum.duet3d.com/topic/11597/filament-sensor-not-executing-pause-g/2
but now I figured out pause.g is not working at all when a pause it triggered from interface or filament sensor. Just the M25 is executed but pause.g is not
When I create a dummy pause.g macro under macros and call:
M98 P"0:/sys/pause.g"
the sys/pause.g executes fine so it is not an issue with the actual pause.g code.
update: calling M98 P"pause.g" executes the file as well.
Kinda stuck
Firmware Name: RepRapFirmware for Duet 2 WiFi/Ethernet
Firmware Electronics: Duet WiFi 1.02 or later
Firmware Version: 2.03 (2019-06-13b2)
WiFi Server Version: 1.23
Web Interface Version: 1.22.6
Update: tried rolling back to 2.02 and it doesn't work there either
Update: Ran M111 P3 S1 and here is the log from Yat:
file: G1 X-8.974 Y-10.573 E10.69672
file: G1 X-9.655 Y-10.773 E10.74225
aux: M408 S0 R88
file: G1 X-10.296 Y-11.079 E10.78779
file: G1 X-10.874 Y-11.481 E10.83299
file: G1 X-11.538 Y-12.157 E10.89377
file: G1 X-12.040 Y-12.955 E10.95421
file: G1 X-12.362 Y-13.846 E11.01498
file: G1 X-12.486 Y-14.786 E11.07576
file: G1 X-12.483 Y-35.083 E12.37747
file: G1 X-12.396 Y-35.787 E12.42300
file: G1 X-12.196 Y-36.469 E12.46854
http: M25
Paused print, file offset=1926
Resume state saved
aux: M408 S0 R88
I only see M25 and no sign of pause.g called.
This just got better, even using the pause button does not execute my pause.g. Just M25
I've installed the filement sensor (laser) and expected it to run the pause.g when triggered. I'm not seeing it though
my pause.g is as follows:
M83 ; relative extruder moves
G1 E-10 F3600 ; retract 10mm of filament
;move hot end up (only custom code).
G91 ; relative positioning
G1 Z50 F6000 ; lift Z by 150mm
G90 ; absolute positioning
G1 X0 Y0 F6000 ; go to X=0 Y=0
When the filement sensor triggers it pops up the message for "too little movement" but there is no execution of pause.g
The hot end simply remains in place (creating a melting spot on the print). It does not go to X0 Y0 and it does not move up 150mm (the piece I added).
Am I doing something wrong or is pause.g simply not executed?
youtube video of lack of pause.g (unlisted)
Firmware Name: RepRapFirmware for Duet 2 WiFi/Ethernet
Firmware Electronics: Duet WiFi 1.02 or later
Firmware Version: 2.03 (2019-06-13b2)
WiFi Server Version: 1.23
Web Interface Version: 1.22.6
@dc42 is there a estimate time on these runout macros? I naively assumed this would be there when I purchased the laser sensor.