@nuroo

Don't know if related, but before this plugin was available, when I first got my accelerometer, I wrote some gcode to collect accelerometer data for a number of moves along x, y axes and diagonals (8 M956 measurements per run of my macro).

After running the macro successfully several times, RRF (a 3.4 beta at the time) crashed (during one of the M956 commands, I think) and I had to hard reset the board. I think I even had to cut 5V power (i.e. unplug the USB between my RPi and my Duet 2).

Like in your case, this only happened after many measurements. Also, like you, my accelerometer is connected to the Duex (spi.cs8+spi.cs7 in my case). But my wiring was a cat5 cable with an IDC connector on the duet end and 5 pin + 2 pin JST XH connectors on the accelerometer end (Adafruit LIS3DH).

On that day, I could repro the problem a couple times. But by the time I was going to report the problem and collect some debug logs, it stopped reproducing for me. I haven't tried the new plugin yet.

I updated my e3d toolchanger to 3.4rc1 and yesterday I successfully installed a lis3dh.

I was wondering why the recommended wiring in the documentation uses SPI.CS4 and SPI.CS3 and then clumsily explains what to change in case you're already using temp. daughterboards (I mean, it's not too bad, even I got the cable right on first try. I just messed up the initial config because I connected it to the Duex5 and forgot to change the config to SPI.CS8/SPI.CS7).

It feels like wiring the connection for SPI.CS4/SPI.CS3 is needlessly fighting the pin rearrangement that the temp daughterboards use. If the accelerometer was wired for SPI.CS2/SPI.CS1, wouldn't that cable work both with and without temp. daughterboards, with only a difference in the configuration gcode? Is the SPI.CS4/SPI.CS3 wiring better from an interference point of view?

The SAME70 configuration include paths for FreeRTOS include src/portable/GCC/ARM_CM0. Changing that to src/portable/GCC/ARM_CM7/r0p1 helps. I haven't tried using the resulting firmware binary.

Slice's published numbers for Magnum+ printing ABS were 91mm³/s, printing at 300°C, 60 degrees above the manufacturer-recommended print temperature (53mm³/s if printed at the recommended temperature of 240°C).
CHT nozzle supposedly gives 30%+ higher volumetric flow rate (probably more for a 1.0mm nozzle).

Super Volcano claims a max volumetric flow rate of 110mm³/s.

@nuroo

Don't know if related, but before this plugin was available, when I first got my accelerometer, I wrote some gcode to collect accelerometer data for a number of moves along x, y axes and diagonals (8 M956 measurements per run of my macro).

After running the macro successfully several times, RRF (a 3.4 beta at the time) crashed (during one of the M956 commands, I think) and I had to hard reset the board. I think I even had to cut 5V power (i.e. unplug the USB between my RPi and my Duet 2).

Like in your case, this only happened after many measurements. Also, like you, my accelerometer is connected to the Duex (spi.cs8+spi.cs7 in my case). But my wiring was a cat5 cable with an IDC connector on the duet end and 5 pin + 2 pin JST XH connectors on the accelerometer end (Adafruit LIS3DH).

On that day, I could repro the problem a couple times. But by the time I was going to report the problem and collect some debug logs, it stopped reproducing for me. I haven't tried the new plugin yet.

I updated my e3d toolchanger to 3.4rc1 and yesterday I successfully installed a lis3dh.

I was wondering why the recommended wiring in the documentation uses SPI.CS4 and SPI.CS3 and then clumsily explains what to change in case you're already using temp. daughterboards (I mean, it's not too bad, even I got the cable right on first try. I just messed up the initial config because I connected it to the Duex5 and forgot to change the config to SPI.CS8/SPI.CS7).

It feels like wiring the connection for SPI.CS4/SPI.CS3 is needlessly fighting the pin rearrangement that the temp daughterboards use. If the accelerometer was wired for SPI.CS2/SPI.CS1, wouldn't that cable work both with and without temp. daughterboards, with only a difference in the configuration gcode? Is the SPI.CS4/SPI.CS3 wiring better from an interference point of view?

@pertti said in E3d Toolchanger to a Leapfrog frame:

Now I received Duet Wifi and Duex5. Some things I have to ask :

• Should the C7 axis (toolchanger connecor shaft) have some kind of physical endstop? Mine is runnig free...
  I found a screw in the middle of the shaft, is it doing the thing? I have not the original x-carriage but my own.

There is no endstop for the C axis. It uses stall detection for homing.

(Note that there is a mod on thingiverse that lets you use physical endstops for X and Y on the E3D toolchanger. But C always uses stall detection.)

Have you read through this yet? https://e3d-online.zendesk.com/hc/en-us/article_attachments/4402646531729/08_-_ToolChanger_Toolhead_Installation.pdf to better understand which part goes where?

• Can´t find the configuration file and the command where you can adjust the positioning of the tool docks. My bed is 300 x 300. Dimensions are certainly different than in the original TC.

If you follow the github link above, compare tpre0.g/tfree0.g to tpre1.g/tfree1.g. The numbers that differ between those files are the coordinates for docking tool 0/tool 1.

Be aware that in the linked config files, the bed center is at x=0/y=0. In E3D's default config, the center of the bed is at x=150/y=100 (just in case you run into someone else's config files).

• so far so good, looking forward to see all working !

Thanks

I'm assembling my e3d toolchanger and opted for PT100 sensors. Given that almost everything is connected to the Duet2 using Molex KK-style connectors, I was wondering if I could (ab)use the jumper pins on the PT100 board instead of the screw terminals for a 4-wire connection using the Molex connector.

So on the board side, I'd have a 4 pin KK connector, and on the tool head, I'd crimp a wire pair to each pin of a Microfit connector to mate with the one on the E3D sensor.

The SAME70 configuration include paths for FreeRTOS include src/portable/GCC/ARM_CM0. Changing that to src/portable/GCC/ARM_CM7/r0p1 helps. I haven't tried using the resulting firmware binary.

Thanks, that's what gave me the idea.

What I was still wondering was whether that would affect the output levels and whether the Duet would work with those.

Hi,
is it possible to use the Mini IR height sensor (in analog mode) with Duet 2 (v1.04) or Duet 3 at 5V (to save the extra 3.3V connection to the hotend carriage and share +5V with part fan/hotend fan)?

@wilriker Great, thanks for confirming!