@chrishamm Thanks for the quick bugfix 🤠 .
Currently its not a big issue as we are using ethernet hardline, The Wi-fi will be used later as we will be taking the machine for demos where a Wi-Fi connection would probably be the easiest to set up.

@Tinchus I flashed the 32-bit variant on some Pis and I haven't had issues with it. See the other thread for info about your touchscreen.

@Tryptamine in that case I suspect the SD card is faulty and is pulling the 3.3V rail down. Once you have used the Erase jumper, the presence of the SD card should not affect the availability of the Bossa port.

@gloomyandy That was it. Didn't see that stop.g now runs at the end of all prints since 3.5b1 regardless of M0 being present and stop.g was set with an M999 (I assume when it was set up on printers 2 and 3 it was thought that it was for an emergency stop situation not the end of a print). Thank you for your help!

@jay_s_uk I moved all the settings that were defined in config.g of MB6HC to MB6XD.
By checking the operation of out9, I confirmed that the ports of 6HC can be controlled.

I also resolved the issue with the input port error for the origin sensor, which was something I wanted to ask about on this topic.

Thank you!

@Aurimas no. You need that file on the SD card and the only way to get it there is to pull the SD card and do it manually

@chrishamm
Thanks, that solved my problem!

@vbtalent2

I was able to calibrate the extrusion and all seems to be working fine.

Glad to hear that. Good luck, and don't hesitate to return to the forum in case of trouble.

@Iker your z probe is setup incorrectly in config.g
I suggest you read here https://docs.duet3d.com/en/User_manual/Connecting_hardware/Z_probe_BLTouch#configuration

Update to this post

I replaced the SD card with a new 16GB card, Formatted and reinstalled all the setup files.

It did give me an error message of mismatched firmware versions although I could not find evidence of anything mismatched. I did reflash the entire package of 3.5.2 and everything now is working as it should.

I can now edit and save changes to the config.g file, As an extra did modify some of the macro files as well as they no longer dissapear.

I would mark this one as resolved.
Just as an additional information I checked the previous SD card in a windows PC, Checked it for errors and no errors were picked up. Still a weird problem but I am chaulking it upto a problem with the origional SD card.

@o_lampe it wasn’t, as it happens. I redid the firmware from scratch using the RRF configuration tool which gave a slightly different setup to the one I was working on when I asked the spindle question.
Ironically having fixed the issues I’m back to essentially my original spindle config.
What I’ve ended up doing to solve that original issue is break out heater3 (and 4 for the laser) and use those to PWM drive an external MOS chip that level shifts the PWM to a breakout from the fan 5V… which is then the right level and “side” of the spindle controller to control it properly!

It seemed to work when I tried it at 9:00 last night but that’s my cutoff time for trusting my brain not to do something stupid so I’ll be doing more tests and checks this afternoon.

@jay_s_uk thanks for the info...👍

@Jords27 the binary files generated by Duet3Expansion projects are written to sit in flash memory above the bootloader, except for some of the debug variants and the no-bootloader variant. If you intend to program the firmware directly into the MCU without a bootloader then you will need to change the linker script file to target them to the bottom of flash memory instead. The linker scripts for SAME5x-based boards are in folder src/Hardware/SAME5x_C21/SAME5x.

@jay_s_uk

Awesome - case closed 🙂

@omar Can you send M122 again? The one you posted still reports SPI errors. Though it looks like the firmware updated correctly.

When you were running the old firmware, did it work with this router? If you changed your router, I think it, and probably your phone, are only offering 5GHz WiFi network, so the Duet can't find it, as it only works on 2.4GHz. I'm glad it's working correctly with your computer, though.

Ian

Thanks @droftarts and @Phaedrux for helping me resolve the issue with my board. I was able to get a warranty exchange for my faulty board. I reconnected to the new board and it is working fine now.

@tinker It might be possible that the slight delay you need to enter a password is sufficient for the resources on the Duet to free up. That's the only explanation I can think of. NS_ERROR_CONNECTION_REFUSED would be a sign that the Duet is still overloaded (because of too few free sockets) when DWC attempts to load the object model.

If you need FTP and/or Telnet access from time to time, perhaps consider creating macros to turn that on and off on demand, but start with FTP/Telnet disabled. That should make the initial load of DWC on a Duet 2 Ethernet or Duet Maestro more stable.

@Jered It should be written straight to the terminal, not sure why it didn't output anything for you.

@Jords27 to build RRF 3.5 you now need branch 'main' of project WiFiSocketServer RTOS in your workspace, instead of project DuetWiFiSocketServer.