Show all posts by user
@bcmob thanks for trying that and reporting your findings. You may want to give things a try with the build I posted above. This has code which should reduce the overall load on the system which may help with your setup.
by
gloomyandy
-
Firmware - experimental, borrowed, and future
Folks, we have had a number of reports of the firmware rebooting during prints and at other times. Some of these seemed to be caused by a watchdog timer reset when executing software PWM code. I also noticed that the LPC configuration was using a possibly invalid setting for the flash accelerator. I've created new builds that may help if you are seeing these resets so please try the following bui
by
gloomyandy
-
Firmware - experimental, borrowed, and future
Hi the thing with the screen may be power, but it is also constantly talking with the main board and this generates extra load for the firmware to process (the same with the WiFi interface), it could be that the extra load is overloading the processor in some situations. Please post the m122 output if you have any more resets.
by
gloomyandy
-
Firmware - experimental, borrowed, and future
Hi, I've looked at the map file and there is nothing that I can see that is obviously wrong. Basically the system was generating steps at the time that the watchdog fired. That typically only happens if the system gets itself into some sort of loop or is unable to complete things fast enough and should not normally happen. Something you may want to do is to try some shorter prints (perhaps ones w
by
gloomyandy
-
Firmware - experimental, borrowed, and future
Hmm interesting, I'll take a proper look at it later as I will need to regenerate a map file for that build (must change the build system to save the map files as well as the bins).
by
gloomyandy
-
Firmware - experimental, borrowed, and future
@Micktol One other difference is that the DWC interface is slightly more stable than when using WiFi, we don't really have enough memory on the LPC and so when running WiFi from time to time the DWC interface tries to use more connections than we have available (and you get a lost connection message), that does not happen with the SBC version, as most of the web interface is running from the rPi.
by
gloomyandy
-
Firmware - experimental, borrowed, and future
I think that make a little more sense, unfortunately it doesn't really tell me very much about what the problem was. If you have any more crashes please do a m122 after you reboot and post them here.
by
gloomyandy
-
Firmware - experimental, borrowed, and future
I've just seen your post about changing drivers etc. Are you using a build of the firmware with the TMC22XX support disabled? If not you may be getting a lot of errors/timeouts because of that (which will not be helping things). You may be able to disable the support by setting stepper.numSmartDrivers to zero in your board.txt file, but I've never tried running like that.
by
gloomyandy
-
Firmware - experimental, borrowed, and future
I've been trying to match up your stack trace to work out what was happening when you had the crash, did you have any sort of debug output enabled at the time? Are you using the standard build or have you built the firmware yourself?
by
gloomyandy
-
Firmware - experimental, borrowed, and future
This sounds like a very similar problem to one being discussed (and worked on) on the discord server. But the people there are mainly using the SBC module and SKR V1.4 Turbo. This is the first example of the problem (if it is the same) on the hardware you are using. This is a good thing because I've not been able to reproduce the problem seen by others and I have similar hardware to yours. Can yo
by
gloomyandy
-
Firmware - experimental, borrowed, and future
How are you powering things? That sounds like when the WiFi module powers up (and starts transmitting), it is drawing too much current and the system reboots. What happens if you remove the m552 s1 from your config.g? If your system boots like this, then try issuing the m552 from the USB console and see if that causes a reboot.
by
gloomyandy
-
Firmware - experimental, borrowed, and future
@ ChemaFuji, always worth having a look at the Duet3d forums if you hit a problem, there are many more people using RRF over there than here (though please remember that the Duet forums are primarily a support forum for Duet3d customers). Anyway it looks like this is a known problem with 3.1:
There is also a work around for it!
by
gloomyandy
-
Firmware - experimental, borrowed, and future
I've never used 2209s (I have a set waiting for me to get around to working on), but the 2208s work fine and the 2209 is supposed to be compatible with them. Pretty much all of the 2208 features are there so you can set current, and other settings with no issues.I'm fairly sure that others are using 2209s with RRF so perhaps they can comment. My intention is to add 2209 features as soon as I can
by
gloomyandy
-
Firmware - experimental, borrowed, and future
@DrDitto Although you could get the hardware for this combination to work (but you would need to build some sort of adaptor board), the LPC does not have enough RAM to support any of the networking options and the 12864 menu system at the same time. If you want a local display you would be better off using either a TFT type controller or a PanelDue. I have no experience of using a TFT board with
by
gloomyandy
-
Firmware - experimental, borrowed, and future
@PCR are you intending to provide any way to power the rPi from the LPC based board? You might want to consider the various power options. Most LPC boards do not have 5V regulator that can provide enough current for a rPi. On my adaptor board I use a buck converter to supply the rPi from the 12/24 main supply.
by
gloomyandy
-
Firmware - experimental, borrowed, and future
@DrDitto, it is not just a matter of remapping what spi device the software uses, most boards have spi1 connected directly to the internal SD card reader and do not make those pins available externally, which pretty much means that spi1 is not usable for any other purpose. On most boards spi0 is made available via the EXT1/EXT2 headers and is usually intended for use with an external SD card read
by
gloomyandy
-
Firmware - experimental, borrowed, and future
Yes that error is probably expected as one of the changes is to reduce the number of available sockets to match the LPC configuration. I'll hopefully build a Duet version later this evening.
by
gloomyandy
-
Firmware - experimental, borrowed, and future
Hi Jay,
I think I can probably do all of those things, but I need to decide which SDK to use (as they are different in a few places). Can you try this version:
It is the same as the one you have been trying, but built with the V3.XX SDK. I'd rather use that version if I can.
by
gloomyandy
-
Firmware - experimental, borrowed, and future
@jay_s new version that will try and connect to the access point that has the strongest signal strength (using the BSSID). New link (to the same filename!):
Should produce some debug of what it is doing so please post the details when you get chance to run it. Oh and I've also modified things so that when you are connected and do an M122 the Mac address displayed is BSSID of the access point, wh
by
gloomyandy
-
Firmware - experimental, borrowed, and future
@jay_s in the scan test you did above, had you added your network SSID as a network to connect to? If so I don't understand the "No network found" message, you should only get that if none of the scanned networks match any of the networks you added using M587 and it looks like the scan was finding your access points.
by
gloomyandy
-
Firmware - experimental, borrowed, and future
It will be picking out the one with the highest RSSI but it is just using the SSID from that, which in your case is the same for both. After that is just goes into the SDK and I'm guessing that just connects to the first match. I'll look into using both the SSID and the BSSID to do the connection as that may help. So was this the same as the 3.X build in terms of how well it worked? If so I'm not
by
gloomyandy
-
Firmware - experimental, borrowed, and future
Hmm so it looks like the firmware is working just that for some reason it is connecting to the wrong access point? I don't have anything like that to test and I've never used a google mesh network. Is there no way to specify by name or anything which access point to connect to? What is the signal strength reported by the 1.23 version?
The version that you have that seems to work best is the ori
by
gloomyandy
-
Firmware - experimental, borrowed, and future
Do you get any sort of error message? I assume you reset the SID and password? I'm a bit confused when you say you can get connected, what do you see? Normally if you are connected the light will be on solid. What do you get from M122 and M552 also does M587 list the networks you have configured? What sort of network do you have (is 2.4 or 5GHz)? You might want to try clearing all of the memory a
by
gloomyandy
-
Firmware - experimental, borrowed, and future
@PCR I'd still like to know what version of firmware you have on your WiFi board, it would be good for you to also try the version 3 build to see if it works for you.
by
gloomyandy
-
Firmware - experimental, borrowed, and future
@jay_s can you try the version 3 one again (I did fix a couple of problems, but I doubt if they would impact any connection issues). I'd really rather not have to have multiple builds out there if I can avoid it. The 3 version works for me with 3 different routers so far. If there is a problem I'd rather try and understand what is causing it.
by
gloomyandy
-
Firmware - experimental, borrowed, and future