Any possibility to implement keep out area on Duet 2?

o_lampe

@GeneRisi I was wondering, if the Duet dev team could change the way kinematic models are implemented?
Wouldn't it be nice to have a kinematics-folder on SD-card and load the required kinematic model at startup?

dc42

@GeneRisi I've already removed several of the kinematic modules from the Duet 2 build. I don't think I can remove any more without impacting on Duet 2 users that we know are using the remaining kinematics. I'll review the amount of free flash memory available on Duet2 when the new input shaping code is finished.

@o_lampe implementing dynamically-loadable modules is tricky, especially with modules that make calls to other parts of the main firmware. Loading them from the SD card at startup would require enough free RAM to hold them, which we don't have on Duet 2.

o_lampe

@dc42 I thought of flashing the required module to ROM during the first startup? ( like it does during an FW-update)
On later startups the FW would only check if the kinematic model has changed (which is rarely the case)

Another option might be a SPI flash ROM extension board connected to the PanelDue port?
But that would require extra work for the FW department and users could no longer use Panel Due.

oliof

@o_lampe SPI Flash sounds iffy enough to keep working and debug that it's probably worth upgrading to Duet3 at that point.

o_lampe

@oliof ESP32 and RP2040 modules have external (SPI?) flash. So I thought, it might not be too strange to mention.

oliof

@o_lampe yeah, but those are built for that. Adding this to a board that was released eight years ago is a different endeavor (and the SPI flash handling part will need it's own firmware space, development, debugging, maintenance, support ...).

I would rather the Duet team focusses on improving existing firmware and developing new features and hardware.

engikeneer

@GeneRisi said in Any possibility to implement keep out area on Duet 2?:

With my e3d toolchanger, i would love to have keep out area implemented. I can’t justify upgrading the Duet boards when they work so well!

Going back to your original question, the way I achieve this is that I change the machine limits in each of the toolchange macros, wipe macros etc. Takes a bit of setting up to make sure you set the limits up for all cases and switch between them properly, but seems to work okay. I have macros that I use to set the limits which I call from the toolchange macros etc so I can easily find and update the limits as necessary.

Its generally only suitable for defining a rectangular go-area, rather than specific no-go areas

dc42

@GeneRisi you could build the firmware yourself. In file src/Config/Pins_DuetNG.h you would enable SUPPORT_KEEPOUT_ZONES and disable one of the remaining kinematics classes to make space.

GeneRisi

@dc42 OK, that sounds interesting!

GeneRisi

@dc42 I am trying to build the libraries but when I click on the hammer, it immediately jumps to

Configuring in: /Users/gene/Dev/RepRapFirmware/v3.5.1/FreeRTOS/src/build/default
cmake -G Unix Makefiles -DCMAKE_EXPORT_COMPILE_COMMANDS=ON /Users/gene/Dev/RepRapFirmware/v3.5.1/FreeRTOS/src
CMake Warning (dev) in CMakeLists.txt:
  No project() command is present.  The top-level CMakeLists.txt file must
  contain a literal, direct call to the project() command.  Add a line of
  code such as

    project(ProjectName)

I am not familiar with Eclipse. How do I build the libraries? Building CANlib woud be a great example for me. Thanks!
Gene

dc42

@GeneRisi I don't know why it it using cmake unless you have configured it that way. Eclipse uses a normal make program, not cmake.

GeneRisi

@dc42 I found the right invocation to build the individual projects. I needed to add the include path for MessageFormats.h to the RepRapFirmware project and when I did it built without errors. (on a MBP, M3) until it got to the last step

I found that instructions on building should also include instructions to install .NET SDK 6.x (x64 version only)

With my newfound success, I have a couple of questions:

How can I tell whether or not the binary will fit the constraints of the Duet 2 system?
Could MQTT also possibly fit in a custom DUET 2 build with only the basic kinematics included?

Thanks for making this possible!

Gene

GeneRisi

@o_lampe I think that's an interesting idea and would be useful, in my opinion, if the freed up space could be used for other features. For example, I am interested in the KEEP_OUT area function and MQTT on my Duet 2. Since my printer only uses one kinematic type, the others provide no additional benefit and the code space is wasted.

Does FreeRTOS support dynamic loading without alot of overhead?

Another approach would be to host firmware builds on a remote machine along with a mechanism to pick and choose from a set of features and have an automated build create the binary.

Gene

GeneRisi

@dc42 A configuration with most of the kinematic types not included and support for the 12864 LCD not included give a .bin file size of 491,676 bytes. How do I know if there is enough SRAM available for the MQTT stack?

dc42

@GeneRisi said in Any possibility to implement keep out area on Duet 2?:

@dc42 A configuration with most of the kinematic types not included and support for the 12864 LCD not included give a .bin file size of 491,676 bytes. How do I know if there is enough SRAM available for the MQTT stack?

By enabling MQTT support and seeing how large the binary is. Also you will get an error from the linker if the flash memory size is exceeded.

You could free up more flash space by disabling the code for whichever of Ethernet and WiFi your board doesn't have.

However, both MQTT and keepout zone support require additional RAM as well as flash memory.

GeneRisi

@dc42 Will the linker tell me if I have exceeded the RAM memory available or is the allocation dynamic and I need to run the firmware to find out?

dc42

@GeneRisi some of the RAM is allocated dynamically depending on your configuration; so the linker can't tell you that.

When the machine has run for a while, M122 will tell you how much RAM is unused.