Topics created by clegg78

@gloomyandy

That was it!!
98e5a1ef-b040-4570-9f12-bf331d30ccb1-image.png

At some point I put that script in there as well. I didnt realize Stop.g gets called at the end of every job now.

@droftarts Sounds great, just wanted to be sure I wasn't pulling from the wrong repo or anything 😉

I tried to monitor the sensor status, but I suppose I made an error somewhere.

I always get "OK" status when reading the sensor status after an error.

var StatusTest = sensors.filamentMonitors[0].status if {var.StatusTest} = "sensorError" M291 P{var.StatusTest} S1 ;M291 P"Filament Sensor - Sensor Error" S1 M24 M99 if {var.StatusTest} = "noDataReceived" M291 P{var.StatusTest} S1 ;M291 P"Filament Sensor - No data received" S1 M24 M99 if {var.StatusTest} = "tooMuchMovement" M291 P{var.StatusTest} S1 ;M291 P"Filament Sensor - tooLittleMovement" S1 M24 M99 if {var.StatusTest} = "tooLittleMovement" M291 P{var.StatusTest} S1 ;M291 P"Filament Sensor - tooLittleMovement" S1 M25 else M291 P{var.StatusTest} S1

This look like I don't read the right value or it's refreshed since the event was raised and called the filament-error.g

Any help will be appreciated

@dc42 I upgraded to the 3.4.1 RC that is posted and it seems to have remedied a most of the disconnections! I am seeing the max Output buffers go to 26, but in general no (or many less) crashes or reconnections like was happening before.

M122 === Diagnostics === RepRapFirmware for Duet 2 WiFi/Ethernet version 3.4.1rc1 (2022-05-03 09:34:00) running on Duet Ethernet 1.02 or later + DueX5 Board ID: 08DGM-917NK-F23T0-6J1F6-3SD6T-1GBWD Used output buffers: 7 of 26 (26 max) === RTOS === Static ram: 23868 Dynamic ram: 74972 of which 0 recycled Never used RAM 9088, free system stack 96 words Tasks: NETWORK(ready,203.0%,218) HEAT(notifyWait,5.1%,307) Move(notifyWait,209.7%,283) DUEX(notifyWait,0.0%,24) MAIN(running,149.4%,425) IDLE(ready,0.1%,30), total 567.3% Owned mutexes: === Platform === Last reset 23:10:43 ago, cause: software Last software reset at 2022-05-14 14:04, reason: User, GCodes spinning, available RAM 9256, slot 1 Software reset code 0x0003 HFSR 0x00000000 CFSR 0x00000000 ICSR 0x0041f000 BFAR 0xe000ed38 SP 0x00000000 Task MAIN Freestk 0 n/a Error status: 0x0c Aux0 errors 0,1,0 Step timer max interval 0 MCU temperature: min 42.8, current 45.7, max 46.8 Supply voltage: min 23.8, current 23.9, max 24.2, under voltage events: 0, over voltage events: 0, power good: yes Heap OK, handles allocated/used 99/3, heap memory allocated/used/recyclable 2048/670/646, gc cycles 0 Events: 1 queued, 1 completed Driver 0: standstill, SG min 3 Driver 1: ok, SG min 0 Driver 2: ok, SG min 0 Driver 3: standstill, SG min 0 Driver 4: ok, SG min 0 Driver 5: ok, SG min 37 Driver 6: ok, SG min 9 Driver 7: ok, SG min 10 Driver 8: standstill, SG min n/a Driver 9: standstill, SG min n/a Driver 10: Driver 11: Date/time: 2022-05-15 13:15:30 Cache data hit count 4294967295 Slowest loop: 350.13ms; fastest: 0.14ms I2C nak errors 0, send timeouts 0, receive timeouts 0, finishTimeouts 0, resets 0 === Storage === Free file entries: 8 SD card 0 detected, interface speed: 20.0MBytes/sec SD card longest read time 22.2ms, write time 10.3ms, max retries 0 === Move === DMs created 83, segments created 54, maxWait 25947876ms, bed compensation in use: mesh, comp offset 0.000 === MainDDARing === Scheduled moves 18853, completed 18813, hiccups 0, stepErrors 0, LaErrors 0, Underruns [356, 0, 0], CDDA state 3 === AuxDDARing === Scheduled moves 0, completed 0, hiccups 0, stepErrors 0, LaErrors 0, Underruns [0, 0, 0], CDDA state -1 === Heat === Bed heaters 0 -1 -1 -1, chamber heaters -1 -1 -1 -1, ordering errs 0 Heater 0 is on, I-accum = 0.0 Heater 2 is on, I-accum = 0.7 === GCodes === Segments left: 0 Movement lock held by null HTTP is idle in state(s) 0 Telnet is idle in state(s) 0 File is doing "G1 X-24.463 Y21.930 E0.0324" in state(s) 0 USB is idle in state(s) 0 Aux is idle in state(s) 0 Trigger is idle in state(s) 0 Queue is idle in state(s) 0 LCD is idle in state(s) 0 Daemon is idle in state(s) 0 Autopause is idle in state(s) 0 Code queue is empty === Filament sensors === Extruder 0: pos 2.11, errs: frame 1 parity 0 ovrun 0 pol 0 ovdue 0 Extruder 1: pos 328.01, errs: frame 0 parity 0 ovrun 0 pol 1 ovdue 0 === DueX === Read count 1, 0.00 reads/min === Network === Slowest loop: 161.96ms; fastest: 0.00ms Responder states: HTTP(0) HTTP(0) HTTP(0) HTTP(0) FTP(0) Telnet(0), 0 sessions HTTP sessions: 1 of 8 Interface state active, link 100Mbps full duplex

Hmm, well after some more prints still on 3.1.1 I got the layer shifting again. So I guess the problem is something else...

@Phaedrux I can but what object model would I use in my conditional statements such as:

if fans[6].requestedValue != 1
...

Thanks.

edit: state.gpOut[6].pwm worked!

Thanks for that clarification! When I saw the language for multiple end stops I guess I misunderstood. I'll check that link

@sebkritikel it was my slicer acting weird and specifically for the profile I use for the duplication printing, it was failing.

I've been running 3.1.1 for a bit and just tonight, ran in a similar problem. I'll create a new thread with the exact issue.

Just about the same, maybe slightly higher on the E0. I will check on some bigger prints coming up on the numbers, I just re-disabled the sensor as I am worried about it pausing again overnight for no reason.

For some reason the forum wont let me edit that post to fix a typo in the M591. :
M591 D0 P3 C10 S1 R20:150 L25 E40
M591 D1 P3 C11 S1 R20:150 L25 E40

The full M122 is here:

=== Diagnostics === RepRapFirmware for Duet 2 WiFi/Ethernet version 2.05 running on Duet Ethernet 1.02 or later + DueX5 Board ID: 08DGM-917NK-F23T0-6J1F6-3SD6T-1GBWD Used output buffers: 3 of 24 (21 max) === RTOS === Static ram: 25712 Dynamic ram: 95048 of which 0 recycled Exception stack ram used: 480 Never used ram: 9832 Tasks: NETWORK(ready,628) HEAT(blocked,1232) DUEX(suspended,160) MAIN(running,3728) IDLE(ready,160) Owned mutexes: === Platform === Last reset 03:26:30 ago, cause: software Last software reset at 2020-01-05 12:19, reason: User, spinning module GCodes, available RAM 9864 bytes (slot 1) Software reset code 0x0003 HFSR 0x00000000 CFSR 0x00000000 ICSR 0x0441f000 BFAR 0xe000ed38 SP 0xffffffff Task 0x4e49414d Error status: 8 Free file entries: 8 SD card 0 detected, interface speed: 20.0MBytes/sec SD card longest block write time: 0.0ms, max retries 0 MCU temperature: min 41.7, current 42.6, max 43.4 Supply voltage: min 23.9, current 23.9, max 24.1, under voltage events: 0, over voltage events: 0, power good: yes Driver 0: ok, SG min/max 40/1023 Driver 1: standstill, SG min/max 406/1023 Driver 2: standstill, SG min/max 401/1023 Driver 3: standstill, SG min/max 0/238 Driver 4: standstill, SG min/max not available Driver 5: standstill, SG min/max not available Driver 6: ok, SG min/max 15/1023 Driver 7: ok, SG min/max 29/1023 Driver 8: standstill, SG min/max not available Driver 9: standstill, SG min/max not available Date/time: 2020-01-05 15:46:07 Cache data hit count 4294967295 Slowest loop: 6.28ms; fastest: 0.09ms I2C nak errors 0, send timeouts 0, receive timeouts 0, finishTimeouts 0, resets 0 === Move === Hiccups: 0, FreeDm: 155, MinFreeDm: 97, MaxWait: 0ms Bed compensation in use: mesh, comp offset 0.000 === DDARing === Scheduled moves: 86200, completed moves: 86160, StepErrors: 0, LaErrors: 0, Underruns: 0, 0 === Heat === Bed heaters = 0 -1 -1 -1, chamberHeaters = -1 -1 Heater 0 is on, I-accum = 0.1 Heater 1 is on, I-accum = 0.5 === GCodes === Segments left: 1 Stack records: 3 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 doing "G1 X85.111 Y104.983 E1.2412" 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 === Slowest loop: 15.26ms; fastest: 0.05ms Responder states: HTTP(0) HTTP(0) HTTP(0) HTTP(0) FTP(0) Telnet(0) Telnet(0) HTTP sessions: 1 of 8 Interface state 5, link 100Mbps full duplex === Filament sensors === Extruder 0: pos 75.23, errs: frame 1 parity 0 ovrun 0 pol 0 ovdue 0 Extruder 1: pos 227.81, errs: frame 0 parity 0 ovrun 0 pol 0 ovdue 0

Thank you for the explanation re multi material. SInce I am currently struggling with registration of two nozzles due to a slight bend in a heat break, I can fully appreciate this. Further, when it comes time to a set up a multi head system, I can see this feature to become critical.

Phaedrux, thanks for moving this onto the wish list.

@dc42 said in Dual Magnetic filament sensor and Endstop limitations/mapping:

suggest you use those for your filament monitors. See the table at https://duet3d.dozuki.com/Wiki/Using_external_stepper_motor_drivers for the pinout.

Thanks @dc42 That is what I was looking for!!

No you do not have to move offsets to the tpre and tpost files. But you need to account for the fact that within the tpre and tpost files, any motion commands will now have tool offsets applied unless you prefix them with G53.

Yep, that was the issue DC42, I started to figure that was the problem when I was thinking of the alignment I have on this printer - Justified to the left side so I had to set the offset to 0 on the X Axis hot end. Now it prints great!

Thanks,
Joe

I figured it out. It was just an issue with the home macro files that were generated by the configurator.

Choose one of your tool Z offsets to be zero, then specify the Z probe trigger height and the Z offset of the other tool relative to that.

Note, in firmware 2.02, tool offsets are not applied within the tool change files. In firmware 2.03beta3, they are.

If you want to do ditto or mirror printing, you will need to get the two tools at the same height.