@fcwilt got it, thanks

@alankilian Well you got me thinking about the cable again so I removed it to test it better and there was a bad connection (on the end I did) that I missed. Doing a print now but I think I'm good. Thanks for making me double check!

@jay_s_uk Thank you! I don't know how I missed that. I don't even know when that got added, anyway that is it. I haven't finished my print but I will post back after confirming.

That took care of it, thanks again

@dc42 I'm just saying with where the distribution board is located now the cables would be around 18". Yes it could be moved but would I rather not. Thanks

@dc42 Thanks, there should be an overlap where, during switching, the power will be applied from both sides so it should not ever drop power. You say "very short", does ~18" qualify? So then leave tool distribution jumpers in place for the docked tools but for the pickup head jumper it at the head and leave the jumpers off on the distribution board for just that connector since it will have ~50" of wiring?

So no one? I can't find thisin the docs so where do I go to ask if not here?

I'm changing my printer over to a toolchanger and all of my tools will be controlled with toolboard 1LCs. I have a tool distribution board that will be the hub for the toolboards. I want the individual tools when sitting in their storage positions to be connected to one of the tool distribution board connectors along with one distribution board connector going to the pickup head.

Say I have 3 tools then I would use 3 of the 4 connectors on the tool distribution board for the 3 tools and the forth connector would be for the tool pickup head which would not have a tool connected unless a particular tool was selected during printing.

What I am thinking is that I would remove all of the jumpers on the tool distribution board and move the jumpers to the tool connectors for each tool. So without any tools loaded the tool distribution jumpers would be removed and jumpers enabled at each tool and the tool would be connected.

The pickup head would also have the jumpers installed at the pickup end thus extending the bus back to the distribution board and eventually to the terminator.

When the pickup head picks up a tool the tool would be disconnected from it's original tool distribution board connector and connected to the connection that goes to the pickup head. In this case the jumpers at the old connector would extend the bus while the tool was loaded.

Is my thinking here correct or am I missing something? Thanks

@chrishamm Thanks for that .....could I ask a stupid question, I am new to python and the Duet. I am trying to write a function that will return a queried result of the object model back to the caller. I am adding the function to my copy of DuetWbAPI.py. I would like to pass the function a string like 'sensors.probes' and have it return just that portion of the object model. for my machine, a duet 3 w/o SBC it uses the rr_model/key='sensors.probes' and that works fine. I want this to be one function for either type of client so they need to share the passed parameters. So far I have
def getModelQuery(self, key):

def getModelQuery(self, key):
        if (self.pt == 2):
            logger.info('in non sbc')
            if not self._rrf2:
                #RRF 3 on a Duet Ethernet/Wifi board, apply buffer checking
                sessionURL = (f'{self._base_url}'+'/rr_connect?password=reprap')
                r = self.requests.get(sessionURL,timeout=2)
                if not r.ok:
                    logger.warning('Error in isIdle: ' + str(r))
                buffer_size = 0
                while buffer_size < 150:
                    bufferURL = (f'{self._base_url}'+'/rr_gcode')
                    buffer_request = self.requests.get(bufferURL,timeout=2)
                    try:
                        buffer_response = buffer_request.json()
                        buffer_size = int(buffer_response['buff'])
                    except:
                        buffer_size = 149
                    replyURL = (f'{self._base_url}'+'/rr_reply')
                    reply = self.requests.get(replyURL,timeout=2)
                    if buffer_size < 150:
                        logger.debug('Buffer low - adding 0.6s delay before next call: ' + str(buffer_size))
                        time.sleep(0.6)
            URL=(f'{self._base_url}'+'/rr_model?key=' + str(key))
            try:
                r = self.requests.get(URL,timeout=2)
                j = self.json.loads(r.text)
            except Exception as c1:
                logger.info('bad JuJu' + ' ' + str(c1))
                return ('failed')
            if not self._rrf2:
                #RRF 3 on a Duet Ethernet/Wifi board, apply buffer checking
                endsessionURL = (f'{self._base_url}'+'/rr_disconnect')
                r2 = self.requests.get(endsessionURL,timeout=2)
            return (j)
        if (self.pt == 3):
            logger.info('in sbc')
            URL=(f'{self._base_url}'+'/machine/status')
            r = self.requests.get(URL,timeout=2)
            j = self.json.loads(r.text)
            if 'result' in j: j = j['result']
            thing = key.split(".") 
            ja=j[thing[0]][thing[1]]
            return (ja)

This works but does not allow me to expand the number of indices so it isn't very flexible. Is there an easy way to take the input string and use it to query the whole object down to what I want and allow for flexibility in the number of indices? Or is there a completely different way of doing this that I am ignorant of? Thanks.

Forgive my ignorance...I've found multiple discussions pointing to the documentation for web interface ie. //rr_connect / rr_model etc. https://github.com/Duet3D/RepRapFirmware/wiki/HTTP-requests

Where can I find documentation for the /machine/status interfaces? I have a duet 3 but it is running in standalone mode so I can't try anything as it uses the rr_model type http interface.

Well I did find something that works
{ip address of printer}/rr_model?key=sensors.probes

I have a remote python script running on my PC that aligns my tools on my TC. It first aligns the x an y and then aligns the Z in order for all tools. It may be run in a situation where the Z alignment is not supported (if no K1 sensor) so I need a way to determine in python whether the printer has the second K1 Z probe or not. My printer responds as if it were a Duet 2 running RRF3 so I need to use /rr_status?type=2 but that only returns info on one probe???? K0 but not K1 for some reason. I can't seem to get a G31 K1 to work....anyone have a python snippet to execute a G31 K1 through the DuetWebApi? I've been trying to get this code to work to no avail. Or if there is some other way to determine if the probe exists or not....

    def getTriggerHeight(self):
        _errCode = 0
        _errMsg = ''
        triggerHeight = 0
        if (self.pt == 2):
            if not self._rrf2:
                #RRF 3 on a Duet Ethernet/Wifi board, apply buffer checking
                sessionURL = (f'{self._base_url}'+'/rr_connect?password=reprap')
                r = self.requests.get(sessionURL,timeout=2)
                buffer_size = 0
                while buffer_size < 150:
                    bufferURL = (f'{self._base_url}'+'/rr_gcode')
                    buffer_request = self.requests.get(bufferURL,timeout=2)
                    try:
                        buffer_response = buffer_request.json()
                        buffer_size = int(buffer_response['buff'])
                    except:
                        buffer_size = 149
                    if buffer_size < 150:
                        logger.debug('Buffer low - adding 0.6s delay before next call: ' + str(buffer_size))
                        time.sleep(0.6)
            URL=(f'{self._base_url}'+'/rr_gcode?gcode=G31')
            r = self.requests.get(URL,timeout=2)
            replyURL = (f'{self._base_url}'+'/rr_reply')
            reply = self.requests.get(replyURL,timeout=2)
            # Reply is of the format:
            # "Z probe 0: current reading 0, threshold 500, trigger height 0.000, offsets X0.0 Y0.0 U0.0"
            start = reply.find('trigger height')
            triggerHeight = reply[start+15:]
            triggerHeight = float(triggerHeight[:triggerHeight.find(',')])
            if not self._rrf2:
                #RRF 3 on a Duet Ethernet/Wifi board, apply buffer checking
                endsessionURL = (f'{self._base_url}'+'/rr_disconnect')
                r2 = self.requests.get(endsessionURL,timeout=2)

Thanks, I'm running 3.2.2 now so what files do I need to download? I'm used to just getting the zip every time but there is no zip. No SBC
Duet3Firmware_MB6HC.bin
DuetWebControl-SD-3.3b2.zip
Duet3Firmware_TOOL1LC.bin
Duet3_SDiap32_MB6HC.bin

Is that it?

So I know PID tuning on the toolboard isn't supported yet. So everything says just hook it up to the main board, Duet 3 in my case, to do the PID tuning. Well my main board is 24V but the toolboard is only 12V so the heater is 12V.

So without even thinking about that I went ahead and hooked the heater up to the Duet 3 OUT1 and did the PID tune.....then I realized that I did that with a 12V heater.

So now my question, am I really supposed to hook up a 12V power supply, all mine are 24V, to my printer just to get the heater tuned?

Is there any workaround? Is the PID I just ran any good?

I had moved my PID parameters over from when it was on the duet 2 and prior to RRF3 but I was starting to see heater faults, which would shut off power to the heater, when printing with PLA. So now I'm not sure what to do next.

Thanks for any help.