Navigation

    Duet3D Logo

    Duet3D

    • Register
    • Login
    • Search
    • Categories
    • Tags
    • Documentation
    • Order
    1. Home
    2. GoremanX
    • Profile
    • Following
    • Followers
    • Topics
    • Posts
    • Best
    • Groups

    GoremanX

    @GoremanX

    11
    Reputation
    79
    Posts
    6
    Profile views
    0
    Followers
    0
    Following
    Joined Last Online
    Location Vermont

    GoremanX Follow

    Best posts made by GoremanX

    • Frequent Heater Faults on High Temp Chamber (500c)

      I have chamber heaters that can go up to 500c. I have them mapped as chamber heaters using the M141 command. According to the documentation, M141 must come before M143 (which is used to set the max temperature for a heater). However the default max temperature for a chamber heater is something significantly less than 500c. I assume it's 125c, same as for bed heaters.

      In any case, when my heaters are above that default (either because they're still cooling down from a print or the print is paused) and I restart the board, I get an instant heater fault on reboot because M141 sets the heater as a chamber heater before M143 sets its max temperature in config.g. This is becoming very frustrating.

      Has this order dependency been eliminated in a forthcoming version of RRF?

      posted in General Discussion
      GoremanX
      GoremanX
    • RE: Frequent Heater Faults on High Temp Chamber (500c)

      @whosrdaddy The chamber doesn't get to 500c, just the heaters do. They're ceramic IR emitters with built in thermocouples. They heat whatever they're pointed at without doing much to heat the ambient air. Plus the enclosure is enormous and has a filter that recirculates the air from top to bottom, so things don't get THAT toasty in there. Basically, as long as the emitters are on and hot enough, then the object being printed can't dissipate its heat through the air, it can only do so through the build surface. So its internal temperature tends to stay the same as the bed's temperature. Meanwhile the electronics inside the enclosure aren't getting fried. It's been working great for nylon, ABS, PETG, etc with zero warpage, even with very large prints (the bed is 24" diameter).

      posted in General Discussion
      GoremanX
      GoremanX
    • RE: Frequent Heater Faults on High Temp Chamber (500c)

      @whosrdaddy No, no air blown directly over the print area. The air from the BOFA filter gets blown in through a 90 degree elbow so it gets circulated around the periphery of the enclosure below the heated bed, starting directly under one of the IR emitters.

      And no cold air to the heatsink. Ambient air temp rarely gets much higher than about 70c anyways when printing ABS, typically it's more like 40c. This is plenty adequate for cooling the heatsink of the Mosquito Magnum using the stock 25mm fan. I've considered switching to a water cooled Mosquito, but haven't seen a need to yet.

      I do however have an external air pump for part cooling, for when I need to do bridging and such. It blows through a tube into a Berd air ring

      IMG_20210105_112349.jpg .

      posted in General Discussion
      GoremanX
      GoremanX
    • Adding a Toggle

      When I have an M80 command in config.g, I get this handy "ATX" toggle on the DWC dashboard for turning the power supply on and off. It's a nice feature.

      Is it possible to add other toggles? Perhaps something that turns a GPIO pin on and off? Like for example the "out9" fan pin that I use to control an external 110v outlet mounted on my printer? That would be really handy, too.

      Right now it's a "fan" with a minimum speed of 255 so that I get a slider in DWC that turns the outlet on when it's set to anything but 0. This works, but it seems kludgy and I'd really like to have a neat toggle.

      posted in Duet Web Control wishlist
      GoremanX
      GoremanX
    • RE: M500 Always Fails

      It's also super comforting to know that I'M NOT DOING ANYTHING WRONG and there's nothing wrong with my setup that'll bite me later. That was my main concern.

      posted in Duet Web Control
      GoremanX
      GoremanX
    • RE: External 5v Source

      @oliof Yes. If you're feeding 5v to the board from an external source (either from a Pi or through the ext_5v pin), then you no longer need to use the onboard 5v converter. Removing that jumper disables the onboard converter

      posted in Duet Hardware and wiring
      GoremanX
      GoremanX
    • RE: Magnetic filament monitor availability?

      @cdthomas9 I was able to purchase the components, including the hobs, without the housing. That's still available from a few sellers, though you have to ask them directly about it because they don't list it that way. I bought mine from right here, was sent an invoice from Duet3D that I paid with PayPal, and I had the package within a week or so.

      posted in Filament Monitor
      GoremanX
      GoremanX
    • RE: Magnetic filament monitor availability?

      @alankilian Yeah thanks for that 😂 I ended up having to order a parts kit from the UK because Filastruder had JUST run out

      posted in Filament Monitor
      GoremanX
      GoremanX

    Latest posts made by GoremanX

    • RE: [DSF Extension] Exec On MCode (was: Shutdown SBC)

      @wilriker I don't think -execAsync is implemented in the 5.1 release. I just downloaded the source code for that release and there's no mention of execAsync anywhere. It's only implemented in the current (uncompiled) source code in the repository. Any chance you could push out a more recent release with the current code? It's the last bit I need to get my setup working.

      posted in DSF Development
      GoremanX
      GoremanX
    • RE: [DSF Extension] Exec On MCode (was: Shutdown SBC)

      Hah! Too late, I'm already neck-deep in implementing it

      @wilriker How do I make it execute the command and exit right away and return success without having to wait for the command to complete? I tried sending my command to background with & but that doesn't appear to work. I'm trying to get it to run a process which continues through the duration of the print, but executing the M code just causes it to hang until the process is complete. I thought it would be execAsync, but that gives me an error on the command line saying that's not a supported flag

      posted in DSF Development
      GoremanX
      GoremanX
    • RE: [DSF Extension] Exec On MCode (was: Shutdown SBC)

      Is this still the easiest way to issue commands on the pi in SBC mode? Or has a native way been implemented in RRF in recent releases? Just wanted to check before investing time and effort in something that's obsolete 😄

      posted in DSF Development
      GoremanX
      GoremanX
    • RE: Urgent: RRF 3.2 Messed Up Delta Auto-Calibration

      Incidentally, the fact that it completed auto-calibration but then skipped bed mesh probing seems to imply that it's just skipping gcodes or somehow executing them out of order. It doesn't appear to be specifically an auto-probing issue, that's just where I'm getting hit with most of the symptoms.

      posted in General Discussion
      GoremanX
      GoremanX
    • RE: Urgent: RRF 3.2 Messed Up Delta Auto-Calibration

      @chrishamm Yeah, I totally forgot that I need to flash the firmware file on the board before I downgrade the packages. I did that last time, but downgrading isn't something I do often so I forget obvious steps sometimes.

      I re-installed the 3.2 packages and can communicate with the board again. I tried to record a failed auto-calibration, but it completed successfully this time 🤣 Although it DID inexplicably skip the bed mesh probing. Since it successfully started the print (which I've been trying to get going for hours), I decided to let it complete it. Once it's done, I'll do further testing (trying standalone mode, etc).

      Here's the bed.g file I've been using for the last few months:

      M561 ; clear any bed transform
      G28  ; home all towers
      ; Probe the bed at 6 peripheral and 3 halfway points, and perform 6-factor auto compensation
      ; Before running this, you should have set up your Z-probe trigger height to suit your build, in the G31 command in config.g.
      G30 P0 X0 Y249.9 H0 Z-99999
      G30 P1 X216.42 Y124.95 H0 Z-99999
      G30 P2 X216.42 Y-124.95 H0 Z-99999
      G30 P3 X0 Y-249.9 H0 Z-99999
      G30 P4 X-216.42 Y-124.95 H0 Z-99999
      G30 P5 X-216.42 Y124.95 H0 Z-99999
      G30 P6 X0 Y124.9 H0 Z-99999
      G30 P7 X108.17 Y-62.45 H0 Z-99999
      G30 P8 X-108.17 Y-62.45 H0 Z-99999
      G30 P9 X0 Y0 H0 Z-99999 S6
      
      ;G29 S1   ; load current bed mesh compensation map
      
      posted in General Discussion
      GoremanX
      GoremanX
    • RE: Urgent: RRF 3.2 Messed Up Delta Auto-Calibration

      @jay_s_uk That doesn't appear to have flashed the firmware to the board. All the packages were successfully downgraded, but now the SBC can't communicate with the board anymore, I assume because the SPI protocol is different and the board firmware is still at 3.2. This is kinda what I was worried would happen. How do I downgrade the firmware on the board if I can't communicate with it anymore? Do I need to connect to it directly via USB?

      posted in General Discussion
      GoremanX
      GoremanX
    • Urgent: RRF 3.2 Messed Up Delta Auto-Calibration

      A few months ago, I tried RRF 3.2 beta 2 for testing. I found that it completely broke auto-calibration on my Delta printer. The auto-calibration would routinely skip probe points and fail for no apparent reason. I reported the issue here and was told that it would be fixed in a bug fix update before release. I switched back to RRF 3.1.1 and everything worked as expected.

      Fast forward to today, RRF 3.2 is officially released and I started running it. Lo and behold, the issue persists, though to a lesser extent. The auto-calibration routine will still occasionally skip random probing points, except now it always completes the routine, albeit with a ridiculous result at the end due to the missing point(s). When this happens, the printer will also entirely skip mesh bed probing (G29) and go straight to printing. Once in a while, the auto-calibration succeeds, and on those rare instances, the printer performs the mesh bed probing as instructed. When this happens, my prints proceed and complete properly, but it's very rare.

      Both G32 and G29 are in my slicer-generated gcode files, so I have no clue why the printer would skip the G29 when G32 skips probing points, since it seems to report that it completed successfully.

      In any case, with the release of RRF 3.2, my printer is now practically useless. This is infuriating. And reverting back to 3.1.1 seems non-trivial since the stable repo now contains RRF 3.2 as the most recent version.

      I'm running a Duet 3 6HC in SBC mode with a Pi 4 running the latest version of all packages (apt update && apt upgrade). Here's the result of M122:

      === Diagnostics ===
      RepRapFirmware for Duet 3 MB6HC version 3.2 running on Duet 3 MB6HC v1.01 or later (SBC mode)
      Board ID: 08DJM-956L2-G43S8-6J9D2-3SJ6P-1A0LG
      Used output buffers: 1 of 40 (11 max)
      === RTOS ===
      Static ram: 149788
      Dynamic ram: 63408 of which 64 recycled
      Never used RAM 145572, free system stack 128 words
      Tasks: Linux(ready,111) HEAT(blocked,296) CanReceiv(blocked,927) CanSender(blocked,350) CanClock(blocked,352) TMC(blocked,19) MAIN(running,265) IDLE(ready,19)
      Owned mutexes: HTTP(MAIN)
      === Platform ===
      Last reset 00:53:28 ago, cause: software
      Last software reset at 2021-01-05 14:18, reason: User, FilamentSensors spinning, available RAM 145572, slot 0
      Software reset code 0x000d HFSR 0x00000000 CFSR 0x00000000 ICSR 0x00400000 BFAR 0x00000000 SP 0x00000000 Task Linu Freestk 0 n/a
      Error status: 0x00
      Aux0 errors 0,0,0
      Aux1 errors 0,0,0
      MCU temperature: min 43.2, current 44.3, max 45.5
      Supply voltage: min 24.0, current 24.3, max 24.6, under voltage events: 0, over voltage events: 0, power good: yes
      12V rail voltage: min 11.9, current 12.0, max 12.0, under voltage events: 0
      Driver 0: position 173106, standstill, reads 47906, writes 24 timeouts 0, SG min/max 0/89
      Driver 1: position 173130, standstill, reads 47908, writes 23 timeouts 0, SG min/max 0/391
      Driver 2: position 173168, standstill, reads 47908, writes 23 timeouts 0, SG min/max 0/397
      Driver 3: position 0, standstill, reads 47908, writes 23 timeouts 0, SG min/max 0/415
      Driver 4: position 0, standstill, reads 47920, writes 11 timeouts 0, SG min/max 0/0
      Driver 5: position 0, standstill, reads 47920, writes 11 timeouts 0, SG min/max 0/0
      Date/time: 2021-01-05 15:12:22
      Slowest loop: 195.85ms; fastest: 0.04ms
      === Storage ===
      Free file entries: 10
      SD card 0 not detected, interface speed: 37.5MBytes/sec
      SD card longest read time 0.0ms, write time 0.0ms, max retries 0
      === Move ===
      DMs created 125, maxWait 2532605ms, bed compensation in use: none, comp offset 0.000
      === MainDDARing ===
      Scheduled moves 43, completed moves 43, hiccups 0, stepErrors 0, LaErrors 0, Underruns [0, 0, 0], CDDA state -1
      === AuxDDARing ===
      Scheduled moves 0, completed moves 0, hiccups 0, stepErrors 0, LaErrors 0, Underruns [0, 0, 0], CDDA state -1
      === Heat ===
      Bed heaters = 0 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1, chamberHeaters = 2 -1 -1 -1
      Heater 0 is on, I-accum = 0.0
      Heater 1 is on, I-accum = 0.6
      Heater 2 is on, I-accum = 0.0
      === GCodes ===
      Segments left: 0
      Movement lock held by null
      HTTP* is doing "M122" in state(s) 0
      Telnet is idle in state(s) 0
      File* is idle 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
      SBC is idle in state(s) 0
      Daemon is idle in state(s) 0
      Aux2 is idle in state(s) 0
      Autopause is idle in state(s) 0
      Code queue is empty.
      === Filament sensors ===
      Extruder 0: pos 218.32, errs: frame 0 parity 0 ovrun 0 pol 0 ovdue 0
      === CAN ===
      Messages queued 12831, send timeouts 28872, received 0, lost 0, longest wait 0ms for reply type 0, free buffers 48
      === SBC interface ===
      State: 4, failed transfers: 0
      Last transfer: 1ms ago
      RX/TX seq numbers: 48867/48867
      SPI underruns 0, overruns 0
      Number of disconnects: 0, IAP RAM available 0x2c8a8
      Buffer RX/TX: 0/0-0
      === Duet Control Server ===
      Duet Control Server v3.2.0
      Code buffer space: 4096
      Configured SPI speed: 8000000 Hz
      Full transfers per second: 35.68
      Maximum length of RX/TX data transfers: 2756/1364
      
      posted in General Discussion
      GoremanX
      GoremanX
    • RE: Frequent Heater Faults on High Temp Chamber (500c)

      @whosrdaddy No, no air blown directly over the print area. The air from the BOFA filter gets blown in through a 90 degree elbow so it gets circulated around the periphery of the enclosure below the heated bed, starting directly under one of the IR emitters.

      And no cold air to the heatsink. Ambient air temp rarely gets much higher than about 70c anyways when printing ABS, typically it's more like 40c. This is plenty adequate for cooling the heatsink of the Mosquito Magnum using the stock 25mm fan. I've considered switching to a water cooled Mosquito, but haven't seen a need to yet.

      I do however have an external air pump for part cooling, for when I need to do bridging and such. It blows through a tube into a Berd air ring

      IMG_20210105_112349.jpg .

      posted in General Discussion
      GoremanX
      GoremanX
    • RE: Frequent Heater Faults on High Temp Chamber (500c)

      @whosrdaddy The chamber doesn't get to 500c, just the heaters do. They're ceramic IR emitters with built in thermocouples. They heat whatever they're pointed at without doing much to heat the ambient air. Plus the enclosure is enormous and has a filter that recirculates the air from top to bottom, so things don't get THAT toasty in there. Basically, as long as the emitters are on and hot enough, then the object being printed can't dissipate its heat through the air, it can only do so through the build surface. So its internal temperature tends to stay the same as the bed's temperature. Meanwhile the electronics inside the enclosure aren't getting fried. It's been working great for nylon, ABS, PETG, etc with zero warpage, even with very large prints (the bed is 24" diameter).

      posted in General Discussion
      GoremanX
      GoremanX
    • Frequent Heater Faults on High Temp Chamber (500c)

      I have chamber heaters that can go up to 500c. I have them mapped as chamber heaters using the M141 command. According to the documentation, M141 must come before M143 (which is used to set the max temperature for a heater). However the default max temperature for a chamber heater is something significantly less than 500c. I assume it's 125c, same as for bed heaters.

      In any case, when my heaters are above that default (either because they're still cooling down from a print or the print is paused) and I restart the board, I get an instant heater fault on reboot because M141 sets the heater as a chamber heater before M143 sets its max temperature in config.g. This is becoming very frustrating.

      Has this order dependency been eliminated in a forthcoming version of RRF?

      posted in General Discussion
      GoremanX
      GoremanX