Show all posts by user
Hi,
I've just released a new version of firmware that contains the updates to support the TMC2209 and other fixes covered in this thread:
The released files can be found here:
by
gloomyandy
-
Firmware - experimental, borrowed, and future
I've just release version 3.1.1-12 which contains all of the updates contained in the various test builds from this thread:
Thanks for the help testing these builds.
by
gloomyandy
-
Firmware - experimental, borrowed, and future
The current settings for both Marlin and RRF are in mA so should just go across. To see the gcode commands used with RRF firmware see the following:
To set current settings you use M906 :
The stall detection thresholds are different, On Marlin I think they run from 0 to 255 with 255 being the most sensitive value. RRF (for the LPC) uses values which have the range -127 to +127 with -127 being t
by
gloomyandy
-
Firmware - experimental, borrowed, and future
I've just updated the test builds to 3.1.1-11 these builds contain a couple of potential bug fixes that I'd like people to try...
* Fix a division by zero the the PWM frequency is set to zero. This can happen at the end of playing a beep on the LCD display and potentially in other places and results in the firmware resetting.
* Gather more information and attempt to fix the occasional problem of
by
gloomyandy
-
Firmware - experimental, borrowed, and future
Folks,
I've updated the test build to 3.1.1-10, this has some extra debug to help track down an occasional heater problem. If you see your heater readings producing crazy values (like 2000+ degrees), please do the following...
1. Run m122 and copy the output so you can post it here.
2. Run m122 p201 and see if the temperature readings change at all
Thanks
by
gloomyandy
-
Firmware - experimental, borrowed, and future
@SDavi, due to the UK lockdown (which is still sort of ongoing), I'm away from home so I don't have access to scope, logic probes or my usual desktop PCs etc. In particular I only have a couple of laptops here and neither of those have an ethernet interface (only WiFi), I don't think there is anyway I can run Wireshark to check for errors on the SBase board as I won't see the SBase packets via th
by
gloomyandy
-
Firmware - experimental, borrowed, and future
@SDavi as an extra data point, I have an SBase (as I think does Jay_S) and have not been able to reproduce the slow download of DWC (and I've tried it on a couple of different routers and over powerline adaptors), in all of those cases DWC downloads in about a minute for me. I have however seen the problem (that I think you have a fix for) of the connection sometimes connecting at 10Mbit rather t
by
gloomyandy
-
Firmware - experimental, borrowed, and future
Just get homex.g working first, I'm pretty sure that things work as at least 2 other people now have this working, so there is something about what you are doing that is different. What H value are you using on your stall detection settings. What sort of stepper motors do you have are they 0.9 or 1.8 degrees, what voltage are you running them at, what sort of printer do you have? What TMC2209 mod
by
gloomyandy
-
Firmware - experimental, borrowed, and future
@MKSA what is it you are concerned about? All of my developments will be merged back into my main branch once it looks like there are no major problems with the recent changes I've made. All of the "new" developments are compatible with older configurations (so although I've added TMC2209 support, TMC2208s still work fine), same with the WiFi updates, these are just new features. I'm sure at some
by
gloomyandy
-
Firmware - experimental, borrowed, and future
There are two sets of test builds available at the moment:
3.1.1-7:
3.1.1-9:
You should probably try 3.1.1-9 but if you hit problems please report them (along with M122 output when the firmware reboots) and try the 3.1.1-7 version.
by
gloomyandy
-
Firmware - experimental, borrowed, and future
The link I provided above to the firmware downloads includes a set of sample homing files. You will almost certainly need to change them to get sensorless homing working. In particular make sure that when you define your stepper drivers with M569 you specify the use of stealthchop (D3) and that you use a value for V that keeps the motors in stealthchop mode during homing operations (try V40). You
by
gloomyandy
-
Firmware - experimental, borrowed, and future
If you are going to use a mixture of drivers I would recommend that you group the 4 tmc2209 drivers as drivers 0 to 4 and place the other driver in slot 5. You should then modify the board.txt file to set the number of smart drivers to be 4. If you don't do that then RRF will be expecting all of the drivers to be TMC devices and you will be getting timeouts and possibly other problems.
by
gloomyandy
-
Firmware - experimental, borrowed, and future
I doubt if that TMC51xx support will work without a reasonable amount of work. The Duet 51xx support expects to use hardware SPI and it is all for a different set of processors (various SAMExx versions) which have a different hardware SPI unit to the LPC17xx used by this port. It certainly won't be just a case of setting the compiler option. What aspects of the 5160 do you need? Have you consider
by
gloomyandy
-
Firmware - experimental, borrowed, and future
Folks,
I've now pretty much completed adding TMC2209 support to the LPC port of RRF. This code is based upon the Duet expansion board implementation (thanks again @DC42) but has a lot of modifications to allow it to be used on the LPC. The two main features now supported are stall detection and sensorless homing you can see these in actions here:
In addition this release includes the capability
by
gloomyandy
-
Firmware - experimental, borrowed, and future
A really easy fix (that I used on the Marlin DMA CDC implementation) is to just make the max packet size 63 bytes rather than 64, that way you never send a full packet and never need a zlp. I think some of the processors used on the Duets may have hardware support to automatically send the zlp when needed.
by
gloomyandy
-
Firmware - experimental, borrowed, and future
@SDavi, one problem that I've seen a couple of times with the LPC and USBCDC is that of sending zero length packets. The CDC spec requires that if you send data that ends with a full packet then you must send an additional zero length packet to terminate the transmission. If you don't do that then some systems (Windows for sure) will not pass on the data until either you send another partial pack
by
gloomyandy
-
Firmware - experimental, borrowed, and future
@SDavi My USB changes are fairly minor, more cleaning things up and a slightly more efficient way of using the buffers. I did consider switching to using DMA, but I wasn't convinced that how I would do it would really save that much time and would need more memory (for DMA buffers) or delay things more. I came to a similar conclusion on the UART side of things, but it seems like you may have foun
by
gloomyandy
-
Firmware - experimental, borrowed, and future
Hi SDavi,
that looks like some interesting improvements. I've also made some updates in similar areas and you may want to take a look at my changes, they are on a separate branch to the main 3.1.1 version of my repo. I'll be pushing some more changes later today (mainly USB updates), so watch this space!
by
gloomyandy
-
Firmware - experimental, borrowed, and future
That depends how you wish to use the WiFi module, as an access point or to connect to your local network. To connect to your WiFi network follow the instructions for the Duet WiFi here:
by
gloomyandy
-
Firmware - experimental, borrowed, and future
It looks to me like you are connecting to at least one of P0_15, P0_16, P0_17 via the pins in EXP1, don't do this, use the pins on J7 (you are already doing this for two of the pins, but I can't tell from the photos which ones), you basically want all three of those connections to go to J7.
If you are still having problems please take some more pictures that show the connections to J7 and EXP1
by
gloomyandy
-
Firmware - experimental, borrowed, and future
Something strange going off here. It has picked up some of the board.txt settings (look at the SSP0.Pins values for instance), but it does not seem to have picked up the board type correctly. @kasper I would check very carefully that there are no odd characters around the line that contains "lpc.board = mkssbase_v1.3", I'd be tempted to delete that line and re-enter it.
by
gloomyandy
-
Firmware - experimental, borrowed, and future
@kasper that error means that rrf is unable to talk to the esp8266 module. There are many possible reasons for this....
1. Wrong sort of WiFi module, or firmware not installed.
2. Wiring problems between the boards
3. Poor power supply to the module
4. Problems with the modification to the Sbase board
5. Probably a few others as well
It would probably help if you posted pictures of your WiFi modu
by
gloomyandy
-
Firmware - experimental, borrowed, and future
I don't think there is any limitations on the pins the can be used for stepper drivers. However the current builds of RRF only support up 5 drivers, so if you want to use more you will need to modify the firmware and rebuild it
by
gloomyandy
-
Firmware - experimental, borrowed, and future
@Micktol The builds I've uploaded should have a fix for the problem we saw with the height map. Can you try that and report back. I'm not sure if it was the same issue as the one that you previously reported or not.
by
gloomyandy
-
Firmware - experimental, borrowed, and future
Hmm nothing is ever simple, works fine on the SBC version. Oh well, I've reduced the output a little and it works fine on my test WiFi setup now. I've uploaded new versions of the files (to the same place), new version is 3.1.1-7.
by
gloomyandy
-
Firmware - experimental, borrowed, and future
Folks, I've updated my test firmware builds to include a couple of fixes, plus the capability to capture more information if the firmware crashes/resets. So if you are running into problems please use this version to test with:
I think the filenames make it obvious what the builds are, you will need to rename the files to firmware.bin when copying the to the SD card or uploading them via DWC.
by
gloomyandy
-
Firmware - experimental, borrowed, and future
@Micktol Unfortunately I can't tell very much about the exact problem from that output, other than it looks like you were executing gcode at the time. Can you provide more details of what was happening? Can you reproduce the problem?
by
gloomyandy
-
Firmware - experimental, borrowed, and future