Duex5 hardwares interface with the Duet 2 hardware
-
A little bit ago as an exercise for learning the PCB workflow I augmented the Duet 2 Wifi and Duex5 just to see if I could do it. you know, for fun.... But I've run into a snag. From what I can tell after having had the new board fabricated and populated with the firmware installed, it would seem the Firmware is not recognizing the presence of the Duex5 hardware, Running M122 P101 generates "Expander status 0000" for the presence of the extension(which I've interpreted as not present/available). I have RRF 3.2.2 flashed with a config set up for 4 Z-motors on the Duex5 side of the board. I'm using someone else config as a starting point, but the controller doesn't seem to be detecting the Duex5 portion from what I can tell anyway so I don't think that's the issue. I was going to polish the config next once i was sure everything appeared functional.
This new Frankenstein Duet board is going into a Voron 2.4(a Voron2.2 setup is where the config originates but it is still for RRF 3 I think. I didn't make this config).
Tackling this detection issue led me to the DueXn.cpp File in RRF 3.2.2 files. This code file seemed to indicate that the SX1509B(U8 on the Duex5) is responsible for telling the firmware that 'it'(the Duex2 or Duex5) is present at startup, and without the SX1509B's appropriate response, the Duet 2 won't 'activate' the appropriate setup of the Duex2 or 5. so the questions pile up....-
What's the Duex5 doing so that the Duet2 recognizes the expansion boards presence? Is it for sure the SX1509Bs response to the Duet2, or is it something else passive that I might have missed during assembly? couldn't find a lot of information about this.
-
Would I need to flash the SX1509B's so that it responds to inquiry on startup? and if so, how?
-
Would it be easier to just create a modified firmware to bypass the inquiry phase and just hard code in the presence of a Duex5, I mean I literally fused them together so the board can't have any different expansions anyways. I imagine this then might also impact the SX1509Bs ability to be used for additional GPIO since a connection wouldn't be established during startup?
If I’m lucky someone will tell me there is a way to bypass the duets expansion inquiry with a Gcode command in the config file but my scouring of the documentation didn't turn up anything like that. In the documentation it says to check the wiring and restart the board which obviously I inadvertently tried many times before I found the page that said to do that. Beyond that I didn't find much information about the setting up the SX1509B besides this.
Another more hacky way I guess I might consider if it really is the best route is to just assign all the right pins to different stepper drivers directly in the config.g(I think you can do that right?), but id' prefer not to go down that path if I can avoid it. seems like that would get messy
Any information about best paths to follow or things I might have overlooked would be greatly appreciated. I'm still rather new to Duet and RRF so forgive me if I've made any extreme oversights or ridiculous assumptions about the hardware’s behavior
also here is the config if you are curious, and let me know if you'd like any other files or information.
config.g
Thank you. -
-
@iterare said in Duex5 hardwares interface with the Duet 2 hardware:
Tackling this detection issue led me to the DueXn.cpp File in RRF 3.2.2 files. This code file seemed to indicate that the SX1509B(U8 on the Duex5) is responsible for telling the firmware that 'it'(the Duex2 or Duex5) is present at startup, and without the SX1509B's appropriate response, the Duet 2 won't 'activate' the appropriate setup of the Duex2 or 5. so the questions pile up....
That's correct. The Duet checks for the presence of the SX1509B at the expected I2C address to determine if the DueX is present. If it is present, then it reads one of the input pins on the SX1509B toi determine whether it is a Duex2 or a DueX5.
Would I need to flash the SX1509B's so that it responds to inquiry on startup? and if so, how?
No, it just needs to respond at the correct I2C address. So check that the address pins are set correctly.
The SX1509B is a tricky chip to solder. So the problem may be that some of the pins of that chip are not making contact with the PCB.
