I didn't know this was a limitation of the expansion boards. I ignorantly went out and got the 3HC, converted my RailCore to AWD and sensing works. My 3HC is CAN ID 1 and I see messages in the console that tell me driver 1.0 or 1.1 stalled.

The issue I do face, please don't discuss here, I'll start a post and not steal this thread, is that the steppers become increasingly unsynced after homing each axis.

@dc42 good point sorry. Versions are:

Duet 2 WiFI 3.5.0-rc.1
Duet WiFi Server 2.1beta4
Duet Web Control 3.5.0-rc.1

@mikeabuilder
Yes that is at least the starting goal.
The thought of removing material might have some merit if scanning and creating a volume from the gouges was too prohibitive but I don't think it should be too hard to do.

The one big issue is that once you hit the core a proper repair takes a bit more work and generally you want to keep the exposed core as minimal as possible. I suppose you could do a manual fill of the core shots and then an automated cut and fill of the top layer but then you are kind of doing some work the way it is currently done and could just fill the whole thing at that point.
The original base material is also harder, tougher, and slicker than the fill material so again ideal is to keep as much of the original material as possible. Having a slightly expanded fill area isn't a big deal but is definitely something to factor as much as possible.

@dc42 So, to be clear, your telling me that I can in fact configure them both in the config.g and enable them all the time via a S2 parameter, and it will only check it when the corresponding extruder is active? If I understand you correctly, that may be worth exploring.
I did take a look at the DWC object Model as you suggested. I obviously have something backwards. When I remove the filament, it tells me "ok." When I put it in, it tells me "no filament." I feel like this is a very simple solution that is eluding me. What do I do?

@SelfHatenMarine the guy you bought it from is almost right, you only need to setup the wifi and then you can use the duet web control.

On a Mac, I would use the Terminal.app and the built-in screen command for the serial connection.

I would suggest some quality time with the extensive documentation at https://docs.duet3d.com, especially the Getting Started page.

Also, make a backup of the SD card before changing anything.

@Chriss - I'm also one of those people that wants to know how things work in detail and ended up writing my own macros for tool changing on the printer we are building at our maker space. Our tool changer is a modification of the Jubilee tool changer, which was a modification of the ESD tool changer. Here are some concepts we learned along the way - meaning things I got wrong at least once before getting it right.

X and Y Tool offsets

We designated tool0 to have X and Y offsets of 0. Why not? it makes stuff easier when setting up the other tools. We designed a two-color part that we print to help us dial in the offsets. Its two concentric square, like two square donuts nested together. Here are the stl files. XY_nozzle alignment inner ring.stl XY_nozzle alignment outer ring.stl If the X offsets are perfect, the total with of the right and left sides of the "donut" should be equal if they aren't equal, the different is twice the amount the offset needs to be changed. Same with the Y direction. We eyeball the alignment the first time, then use calipers to get the final adjustment.

Z offsets

Each tool needs to have it's Zoffset set independently. We didn't designate roo0 to be the origin because we make Z offset changes often. We use baby steps to make final adjustments to the Z offset and we wrote a macro that will read the current baby steps and z-offset form the object model, and change the z-offset to "roll in" the baby steps if baby steps have been set. We run this macro whenever we park a tool (ie run tfreeN.g).

Moving outside soft limits

We set the X and Y soft limits of the machine so that prints can't drive the printhead into the tool docking area. This menas that when we dock or undock a tool, we need to allow moves outside the limits (M564 S0). When we move back inside the limits after we pick up a new tool, we need to disallow moves outside the limits (M564 S1). Be sure to put and M400 (wait for moves to finish) before the M564 S1 or RRF may discover you are outside limits. We crashed the tool several times while learning this one.

tpre vs tpost

This one confused us for a while until we understood that the "event" that the "pre" and "post" refer to is the changin of the tool number in RRF. This means that during a tool change RRF has no "awareness" the tool offsets, extruder settings, etc while it is running tpreN.g. If you have any gcode command in tpreN that has a parameter for "current tool", "current heater", "current extruder", "current filament", etc, they probably should be in the tpostN.g file.

simplifying the macros

All three of our tools have the same docking procedure, with only the X location of the dock different. We ended up writing a single macro for each of tfree, tpre and tpost, using an input parameter for the X location of the dock. We called these macros tfree_all.g, tpre_all.g, and tpost_all.g. In the actual tpostN.g file, we just use an M98 to call our macro. With this setup, we can tweak the parking macros in one place.

The slicer

We normally use PrusaSlicer and have one line of custom gcode for each tool. This line sets the standby temperature for the tool, based on the nozzle temperature set in the slicer. We did this to try to minimize the time a tool takes to re-heat after it's been picked up. We started with 25*C below active temperature, but this was giving us about 30sec of wait time per tool change and it felt like forever. When we kept the nozzle temperature at the active temperature we had some problems with the plastic melting beyond the cold-break when the tool was docked for a long time.

PanelDue

In PrusaSlicer, the extruder numbering is "1-based" - and RRF it's "0-based". this leads to confusion for users when they are using the slicer. We can change the labeling for the tools in DWC to align with the Slicer numbering. Our main user interface is the PanelDue and we have not found a way to change the tool numbering on it.

@dogboy If you really need high accuracy, you can add positional sensors on the motor shaft(s) and the joint(s).
Closed loop is still pretty new in RRF, but once tuned in seems to iron out all accuracy problems.
Homing the arm once in a while will have a similar effect.

@jay_s_uk Yup, that was it. Thanks! It's odd. I can't recall ever changing that but it is possible.

@Aurimas Do you have a daemon.g file in /sys?
I think the logging (M111) should show the Gcode sent if you turn it on, which might give a clue where it's coming from. Send M111 P3 S1 and connect a serial monitor (eg YAT) via USB.

Ian

@Arminas said in PT1000 thermistor configuration:

erature is stable all the time, expect at a

you probably have season changes and thus your PID tuning is out the window.
rerun the tune and you will probably find that it works fine now

@droftarts the parts arrived in due course and here is the made up adapter cable. I'm happy with it.

Note to all, this cable carries mains voltage and should be tucked out of the way and safely covered where you cannot touch it. This photo is with the cover removed for photo purposes.

power-connector-adapter.jpg

@Alva please can you confirm if you have tested this.

@SonnyD1 I said in my last message that I felt there was a difference between where the SZP and BLTouch think Z0 is (and it was only a little difference, like 0.1 to 0.2mm), and suggested what to do. The only difference in your latest config.g compared to the earlier one is you made a small change to the Z offset of the BLTouch, and you recalibrated the SZP and changed it's offset too. That appears to have corrected the difference between them, as I suggested. So no, I didn't abandon you, just waiting for any further information if that wasn't the issue. I'm glad you got there in the end.

Ian