M557 number of probe points
-
My idea was in the slicer. Because the heightmap.csv is only a table with Points.
What i do not know is if you can load a heightmap with more points. @dc42 could know the answer to that!
-
@OBum_2020 said in M557 number of probe points:
You suggest that I use G29 S1 P"filename" to load the CAD-File, is that correct?
No, that's not going to work. The bed mesh needs to be csv (comma separated values) file, with a maximum of 441 points. As has been said, more than 441 points is a memory issue on the Duet controller.
However, I've just asked @dc42 if the points have to be uniformly distributed. His response was "it interpolates and extrapolates as necessary." So you could create a bed mesh from the CAD file of the bed, it could have fewer points in flat areas, and more in areas where the bed height changes. If your bed is smooth curves, this is going to be difficult, though. Maybe a picture of the bed would help?
Ian
-
This one of my first results. The lower strukture was generated on the printer and then rotaded 90° in the longitudinal axis. I scanned the surface with the mesh probe as mentioned above and then printed a plane x-y-surface.
-
so it worked
-
I actually was thinking about this for SBC users - mesh is loaded on the pi side not the duet side, right?
If so, there's no arbitrary limit anymore. I'd really love detailed meshes for prints on my whole bed - 622*622mm its alot to cover!
-
@Luke-sLaboratory the Duet 3 Mainboard (or mini 5+ in the future) still needs to use the mesh to modify the gcode being printed to follow the mesh. this happens on the Duet not on the SBC.
What is certainly possible is to design a plugin that constructs a more detailed mesh mapping from the Pi (using G30 S-1 lots of times). once that is done the plugin needs to intercept all the incoming gcode, break it into segments and apply the mesh transformations, then send on to the Duet for processing. At some point a limit will be hit, either the rate of processing of the Pi, or the rate that all those smaller moves can be sent to the Duet.
-
@OBum_2020, how many points do you need? Each point needs 4 bytes of RAM, so on a Duet 2 you may not have enough free RAM for the number of points you want. You can look at the "Never used RAM" reported by M122 to see how much you have spare. Duet 3 has a lot more RAM.
Duet WiFi hardware designer and firmware engineer
Please do not ask me for Duet support via PM or email, use the forum
http://www.escher3d.com, https://miscsolutions.wordpress.com -
Lame!
Alright - I'll go on a tangent here
Is there any roadmap (rrf4?) to swap to a direct-stepping style ala klipper or stepd?
Where the Pi or PC would do all the brain work for motion planning and the board would just be responsible for chopping signals to the drivers and interpreting signals?
TBVH I'd love to see more use of the PI to do some heavy lifting as I'm very pleased with the step rates and quality-of-motion I get out of my klipper machines.
Right now the pi seems under-appreciated. I have quite a few ideas that I'll need time to develop for it, but I think it could bring huge improvements to the underlying motion system as well.
-
@dc42, I will check the "Never used RAM" soon. For my current application I will probably need about 20.000 points.
-
The firmware could be tweaked by removing unused drives, if one doesn't need them, e.g. DM is implemented for XYZ+5Diamond. Reducing to XYZ+1Extruder could free about 10 KB, meaning 2500 additional points. But this would mean a custom built firmware.
-
@JoergS5 said in M557 number of probe points:
The firmware could be tweaked by removing unused drives, if one doesn't need them, e.g. DM is implemented for XYZ+5Diamond. Reducing to XYZ+1Extruder could free about 10 KB, meaning 2500 additional points. But this would mean a custom built firmware.
so @Luke-sLaboratory could start compiling is own RRF easily! Thhe Build Instructions were updated last month or so!
-
@PCR it must be tested, but in general, yes.
In the firmware are already some parameters which are different for Maestro/Duet2/Duet3 and they are configured in firmware by IFs, e.g. how many maximum segments can be used or timing of the steppers, so a balancing between points and drives used and optimizing the RAM usage could be handled by such IFs also.
The disadvantage is of course that the custom firmware is more difficult to analyze in case of problems. But if you don't need support for the firmware, you can of course do what you want.
The file RepRapFirmware/src/Memory usage.ods gives an overview of the used memory. Shortening FileWriteBuffer or the DDA are other options.
-
One more idea: 20 000 data points could mean a lot of redundancy. So converting it to 8 or 16 bit integers each (rounding, measuring isn't exact anyway) and then compressing should result in data volume less than 20 KB (rough estimation), starting from raw data 80 KB.
-
Here is the result for M122:
M122
=== Diagnostics ===
RepRapFirmware for Duet 2 WiFi/Ethernet version 2.0(RTOS) running on Duet Ethernet 1.02 or later
Board ID: 08DGM-9T6BU-FG3S0-7JTDD-3SD6Q-1V5MF
Used output buffers: 1 of 20 (6 max)
=== RTOS ===
Static ram: 28380
Dynamic ram: 95724 of which 0 recycled
Exception stack ram used: 284
Never used ram: 6684
Task NETWORK ready, free stack 396
Task HEAT blocked, free stack 1256
Task MAIN running, free stack 3568 -
@OBum_2020 said in M557 number of probe points:
RepRapFirmware for Duet 2 WiFi/Ethernet version 2.0(RTOS) running on Duet Ethernet 1.02 or later
That's quite old firmware. You may wish to update to firmware 2.05.1 and DWC 2.0.7.
The easiest way is to simply upload this zip file as is (don't extract it) to the /sys folder via DWC.
https://github.com/Duet3D/RepRapFirmware/releases/download/2.05.1/Duet2Firmware-2.05.1.zip
https://github.com/Duet3D/RepRapFirmware/blob/dev/WHATS_NEW.md
See the release notes for all that has changed in between, you may need to make a few changes to the config files. This would put you on good footing for the eventual upgrade to RRF3.
