Show all posts by user
Yep those changes got picked up from Sdavi I think they make a lot of sense. Good luck with the printer. I've noticed a couple of odd things mainly to do with the time estimation and the layer information, I don't think that DSF/DWC handle the latest Prusa Slicer (which I'm using very well). It prints fine, but the information displayed is wrong. I have some changes which fix some of the problems
by
gloomyandy
-
Firmware - experimental, borrowed, and future
Hmm I'm not sure what to suggest. I have literally just redone pretty much everything using the latest RRF3 RC4 (with sdavi's changes merged in) and the latest DSF (from the dev branch) and it all works fine (I now have it working on my actual pronter and used it just now to print a case for my pi 4). If you are using the latest version of my repo make sure that you have updated the board.txt fil
by
gloomyandy
-
Firmware - experimental, borrowed, and future
Both WiFi and SBC builds seem to be working for me now. I've merged the configurable UART code along with RC4 and the updated board.txt entries. I'm going to test things a little more and will then upload the binary files.
My SBC test rig with HDMI touch screen:
by
gloomyandy
-
Firmware - experimental, borrowed, and future
@DC42 that's brilliant thanks, makes things much easier. Quick follow up question. which DSF branch should be used with RC4, "dev" or "dc-rrf3.01-RC4"? Thanks again.
by
gloomyandy
-
Firmware - experimental, borrowed, and future
@dc42 @sdavi not sure if you are looking at this thread but... I'm in the process of updating to RC4 but have hit a couple of problems. There are a number of new items that have been added to the object model, but some of these are causing compilation errors when built with some of the options we use for some of the LPC builds. In particular the object model reference to "powerFailScript" fails i
by
gloomyandy
-
Firmware - experimental, borrowed, and future
So I've just rechecked the sort of connection I was getting with my MKS SBase. In my case it is 10Mbit/s half duplex (which is odd because this was to a 1GBit/s switch and the rest of my wired network runs at either 1GBit or 100Mbit), but even with that connection speed the DWC startup time is less than a minute.
by
gloomyandy
-
Firmware - experimental, borrowed, and future
@MKSA I also tested RRF 3.01 on an MKS SBASE using Ethernet yesterday, the load of the DWC took 30seconds to a minute for me (though it seemed like an age compared with WiFi or via the SBC). Not sure what is going on with your setup, I wonder if there is something odd going on with the SBase on your network/router (it only runs at 10MBits which is unusual these days).
by
gloomyandy
-
Firmware - experimental, borrowed, and future
You can tell that an LPC version is running because it works with an LPC board :-) I should probably change the version number or something, but I don't think we are really at that stage just yet, I'm still exploring what works.
My board.txt file looks like this...
/Config file to define Hardware Pins LPC Boards.
//Note: Each line should be less than 120 characters.
// : Unwanted options can
by
gloomyandy
-
Firmware - experimental, borrowed, and future
@jay_s if it helps this was the command I used to build the main server:
dotnet publish -r linux-arm -c Debug -o /opt/dsf/bin DuetControlServer.csproj
Oh and I did this on the rPi not using any sort of remote build setup. I haven't tried building the web server side of things.
I've created a fork with the changes I had to make to get things working, you can find it here:
by
gloomyandy
-
Firmware - experimental, borrowed, and future
I've modified BoardConfig.cpp to use ff.c directly when loading board.txt which makes it possible to fully initialize things when using the SBC. With this configuration my system has around 6Kb free (this includes the space needed for TMC22XX drivers). I only have this working on my test setup (so not a full printer), but I've been able to run motors, turn on fans and execute test gcode files all
by
gloomyandy
-
Firmware - experimental, borrowed, and future
Hi @sdavi I now have my rPi and SKR V1.4 board talking to each other (at the default 2MHz SPI speed). Which is pretty cool. Great work (again!). Hopefully tomorrow I can try a few more things out and perhaps even hook it up to my printer control board and test things there. I'm not sure that I have a very consistent rPi setup at the moment as I'm using the released rPi duet3 boot disk but DCS bui
by
gloomyandy
-
Firmware - experimental, borrowed, and future
@sdavi thanks for that, I'll take a look at the DSF source and make the same changes.
I noticed that you have been looking at possible problems with the software PWM code. I've also been seeing issues with it (leading to heaters being set to either full on or off for some time), this seemed to happen a lot when I attached a panel due to my printer. I eventually tracked it down to a sort of race
by
gloomyandy
-
Firmware - experimental, borrowed, and future
Ah thanks for that @jay_s I obviously did not look hard enough! Looking at the schematic it seems that they do indeed have resistors on the SPI lines 100 ohms on mosi/miso/cs and 470ohms on the clock and data ready.
by
gloomyandy
-
Firmware - experimental, borrowed, and future
Hi @sdavi, thanks for uploading the files. I'm hoping to make a start on trying this tomorrow at some point. But I'll need to get my pi running the Duet software and hook things up. Did you have to make any changes to the pi software side of things (for clock speed or buffer size etc?). Did you include any resistors in the connections between the pi and the LPC (like the ones that are present bet
by
gloomyandy
-
Firmware - experimental, borrowed, and future
So the Duet provides power to the pi? I wonder how good an idea that is? Is it normal in this setup just to turn the power off on the printer, which presumably turns off the power to the pi? In my experience of the pi (with older versions of the pi), this can easily result in the pi's SD card becoming corrupt. I wonder if this is still a problem with this setup?
by
gloomyandy
-
Firmware - experimental, borrowed, and future
That sounds pretty simple. I was a bit concerned because the Duet 3 seems to use a fairly substantial ribbon cable, so wasn't sure if it needed extra signals etc. What speed are you running the SPI connection at? I assume it is slower than the Dueat 3 uses? Are you seeing and SPI errors?
If you can make your changes available at some point, I'll merge them into my build and give them a try when
by
gloomyandy
-
Firmware - experimental, borrowed, and future
@sdavi That sounds pretty good! I'm looking forward to giving it a go with the Pi I have already got attached to my printer. How easy was it to create a cable to hook the two boards together? Is the connection similar to the WiFi board (SPI plus some handshake lines)? I've not really looked at how things get split between the two boards, so I'm not 100% sure what the advantages are of that system
by
gloomyandy
-
Firmware - experimental, borrowed, and future
The problem is that the SBC connection is probably established after the board.txt file has been read! In fact there is a good chance that the link may need data that is in the board.txt file to actually configure it (like what pins to use for the handshake etc.). We can probably hard code the link details but it kind of defeats the purpose of having the board.txt file in the first place.
by
gloomyandy
-
Firmware - experimental, borrowed, and future
Folks,
I've merged the latest V3.01-RC3 changes into my fork (along with a few fixes to allow building on Linux and to fix a typo from a previous merge), but I'm away at the moment so can only build things on Linux and can't test the build at all. If anyone is really keen to try RC3 I can supply my binary (or you can try building it), or if you don't mind waiting I'll test things and upload a "re
by
gloomyandy
-
Firmware - experimental, borrowed, and future
@sdavi, that's interesting, but a little worrying that we need to go so much lower on the buffer sizes, to get things to fit. I wonder if it will even run with buffers that are so much smaller? I had a quick look at the DSF code and changing the buffer size looked reasonably simple (as DC42 already changes it from the default 4K). In your build do you have code that actually handles the Linux SPI
by
gloomyandy
-
Firmware - experimental, borrowed, and future
@sdavi That's interesting I've not really paid much attention to the SBC/DSF side of RRF 3.0 (I assuming it was simply not possible with the LPC version). Having now had a quick glance at it I wonder if it may be possible. My understanding is that certain functions get migrated to the rPi from the RRF control board. Does this migration free up any RAM on the LPC I wonder (things like the network
by
gloomyandy
-
Firmware - experimental, borrowed, and future
@dc42 just published his future plans for RRF 3.X over on the Duet3d forum, may be of interest to some here:
No idea how some of the new features (variables?) will impact memory usage on the LPC devices, will be interesting to see!
by
gloomyandy
-
Firmware - experimental, borrowed, and future
Folks, sdavi has lots of stuff to do at the moment so myself and @jay_s are going to try and keep things ticking over until he gets back. As part of this I have updated the source in my fork to V3.01-RC2. In addition to the RC2 updates this binary includes code to support TMC22XX devices via UART, the ESP8266 WiFi module, pre-filtering for the ADC and the capability to attach a PanelDue display.
by
gloomyandy
-
Firmware - experimental, borrowed, and future
Quotesdavi
Yes this was done on purpose for those using the pre-compiled binary, to avoid someone making a typo etc leading to errors/weird behaviour on the steppers, UART and SPI (which could have a SDCard connected etc). If there is no display/sdcard connected then there is already a number of spare pins that are already usable.
But yes it is possible to use nearly any pin you want by compil
by
gloomyandy
-
Firmware - experimental, borrowed, and future
Hi @sdavi, I've just noticed that some of your RRF repos are currently marked as archived. I hope that doesn't mean you no longer plan to update them as that would be a great pity.
by
gloomyandy
-
Firmware - experimental, borrowed, and future
By default Marlin has the threshold disabled, RRF has a very low setting for it and so will switch to spreadcycle at a relatively low speed (which is safer as you are less likely to lose steps but produces more noise). But as I mentioned above you can easily tune that setting by using M569, why not try adjusting the value and see how things change?
Lower settings increase the speed at which the
by
gloomyandy
-
Firmware - experimental, borrowed, and future
@jay_s firstly things may have changed since I last tried this, but last time I looked none of the pins for the stepper drivers are in the pin table (because they are specified in a "special" array of pins), similarly I don't think the pins used for the external SPI or the UART pins are in pin map (because normally they will be referenced as a UART or SPI device implicitly), but if you want to us
by
gloomyandy
-
Firmware - experimental, borrowed, and future
What are you doing to set stealthchop and how are you determining what mode they are in? I have TMC2208s and they seem to be working fine in stealthchop mode. I'm pretty sure they are in stealthchop by default. They will switch to spreadcycle when your speed exceeds the threshold set with M569 V, you may want to check the value set for this as the default setting is a pretty slow speed and so the
by
gloomyandy
-
Firmware - experimental, borrowed, and future