Adding a new sensor type to RRF
-
@Omer1015 I'd suggest that rather than posting snippets of your code you post a link to something like a git hub repository so that we can check all of your code.
-
@gloomyandy thank you for the suggestion I have added a github repository with my edited reprapfirmware:
https://github.com/Omer1015/Omer1015-RepRapFirmware/tree/main
-
@Omer1015 It would have been better if you had forked the RRF github repo and then committed your changes to a new branch so that it is easy to see what changes you have made.
Also are you sure that you have successfully installed your version of the firmware? You may want to change the version number in version.h so that you can identify your version and check that the new version of the code is actually running.
-
@gloomyandy the reprapfirmware is on version 3.5 to be exact and it runs perfectly fine, I'm almost positive that it could just be something in the code that I'm missing.
-
@Omer1015 I'm not sure you understood my previous post or not. I was suggesting that you change the version number reported by your build so that you could check that what is running is actually your build and not the original firmware (Having a different version would also ensure that the Duet3 folks can easily spot that the official firmware is not being used). So I would suggest that you change the string:
# define MAIN_VERSION "3.5.2"in the file version.h to be something like:
# define MAIN_VERSION "3.5.2-Omer"You should then be able to check that your version of the firmware is indeed running by entering M115 and checking that the version string matches your version string.
-
@gloomyandy I have done that and it does not match the version string I added in my code.
-
@Omer1015 I think you need to tell us a little more, how are you building your version of RRF and what are you doing to install your new version?
-
@gloomyandy I followed the guide on github about building a reprapfirmware, I do this by downloading a copy of reprapfirmware 3.5 from the github, make the changes I need in the source code, build the firmware in eclipse with build configurations for MB6XD and then once the build is finished there's a file called "Duet3Firmware_MB6XD.bin" that gets made in a folder called MB6XD in the reprapfirmware folder. which I place into the sd card of the MB6XD board replacing the bin file of the same name that is in the firmware folder of the sd card.
-
@Omer1015 You need to then install the firmware into the flash storage of the 6XD, you do that by running the M997 command: https://docs.duet3d.com/User_manual/Reference/Gcodes#m997-perform-in-application-firmware-update
-
@gloomyandy so after we build a new firmware file, how do we select it to be uploaded to the 6XD'S flash storage.using the m997 command
-
@Omer1015 See the link I posted above. But if you upload the file using DWC (upload system file) to the board then DWC should ask you if you want to install it.
-
@Omer1015 just
M997should do it.
Or just upload it to the system tab in DWC and you should be asked if you want to update the firmware -
@Omer1015 If the firmware filename isn't "Duet3Firmware_MB6XD.bin" you can change it to that and send M997, or send M997 P"your_filename.bin".
Ian
TronXY X5S with Duet 3 MB6HC and Roto toolboard : Cartesian bed-slinger with Duet 3 Mini 5+ WiFi and 1LC : RRP Fisher Delta v1 with Duet 2 Maestro : Polargraph with Duet 2 WiFi
-
@droftarts are there any alternative ways to flash the firmware to the duet aside from M997 or Bossa? Using M997 on the DWC usually corrupts the firmware and then we have to flash the original firmware using Bossa, I tried using Bossa to flash the edited firmware to the 6XD but the same issue of not being able to connect to it persists.
-
@Omer1015 it's also possible to flash the firmware using an Atmel ICE or other compatible SWD programmer. However, M997 and Bossa are the normal ways. Two notes:
- On the 6HC and 6XD using M997 very occasionally fails to flash the firmware, and it is then necessary to use Bossa (or SWD);
- When in Bossa mode the USB port is put in high speed mode (we have no control over this, it's a decision made by Atmel/Microchip). This makes the USB cable and the port and any hubs it is connected through much more critical. So if the Bossa port fails to appear, try a different USB port, or a different hub, or a different USB cable. In particular, USB extender cables won't work.
-
@Omer1015 What makes you think the firmware is being corrupted? It sounds more like your newly built firmware is not working for some reason. I suggest that you try just building the standard firmware using your build environment and test that (as well as comparing the size of your build with the official build). I know of several folks that have successfully built the firmware, so I don't think there is a major problem with doing that. Are you certain you are using the correct version of the gnu C compiler and tools, that is what folks often get wrong.
