hey @gtj0 thanks for your reply, i did some work on the compiling of the duet as well, but i guess it is highly dependent upon @dc42 as the main developer of RRF.

Currently, I see the following challenges for the duet3d and RRF

with the rising number of duet derivates, it is getting more and more complex and complicated to test every one for each release and even the compiling is getting fiddly the code coverage of test cases is, at least for me, not available through the design of the project in different modules it is getting more and more complex for everyone else except dc42 to compile the firmware, as it is not clear which tag/branch/version is compatible to each other or which one is broken and probably why.

I see the following benefits in using an automated compiling and later testing process:

the community could support dc42 in creating testcase for parts of the software the community could actively participate in the development without setting up an development environment the compiling and testing for every derivate of the duet could be automated, like some boards are getting automaticly flashed with the last firmware from github and can perform some basic tests and return the results back

dunno if there is more.

Tim

@chrishamm Son of a bitch that did it. Thanks man.

It is currently working again. I'm not sure what happened. I thought the problem might have been that my homeall.g called my homez.g with an M98 with no quotes around the filename. I modified my homeall to not call the homez (and a few other tweaks) and everything suddenly started working. But, when I put the bad M98 back in (with no quotes, just to see if it would fail), I couldn't reproduce the problem.

@dc42 Can confirm that.

@dc42 said in RRFLibraries commit "Added StringBuffer class..." broke builds:

@gtj0 said in RRFLibraries commit "Added StringBuffer class..." broke builds:

Only my bed heater shows now. No extruder... Not being passed to DSF either.

Should be fixed in latest 3.1 commit.

Thanks!

💡 you sir are a saint and a genius!

I thought I had removed the old stuff from building PanelDue, but I clearly know far too little about eclipse and cross compiling in general.

RRF(libraries) built without issues!

For Duet 3 git clone https://github.com/dc42/CANlib.git was also needed but not part of the BuildInstructions page.

Thanks for the xtensa legwork as well! 👍

that makes more sense, as it seems to be added to gcc7 😄

Under Windows, I currently use Eclipse 2019-09 and GNU Tools ARM Embedded 8-2019-q3-update.

The reason is that each GCode input channel can only process one command at a time. Ordinary movement commands are placed in a queue for later execution, so unless the queue is full, processing them happens immediately. But when a homing move is executed, the system has to wait until it completes so that the axis positions can be reset. So processing it doesn't finish until the move does.

The same applies to all input channels. So if you initiate a homing move from DWC, you can execute M408 and other non-motion commands concurrently from serial; and vice versa.

HTH David

@droftarts
Ah, how did I miss that? Lol
Time to upgrade again soon.

@dc42 Thank you for your help.

OK, I have fixxed it. Download wrong branch of the RRFLibrary. Thanks so much.

Perfect, i solved. Thank you very much. I mistakenly used powershell.

Thanks, confirmed what I was thinking 😁

@zapta said in Fine Grained Heater Control:

@gtj0 said in Fine Grained Heater Control:

@zapta Can you describe in more detail what behavior would you like to see for single-tool single-heater printers?

Basically similar UI model most single head printers have. Something along this lines

Nozzle: current temp, target temp.

Bed: current temp, target temp.

Target temp of 0 indicates off. Turning heaters on/off is done by controlling the target temp. No concept of 'tool selection' as there is only one tool. No concept of standby.

Everything above is about the UI aspects that are exposed to the operator, not the internal model or gcodes.

OK, well that can be solved in the UIs however this discussion winds up.

Waiting for conditional statements patiently, It's going to be a really nice added feature.

Found it Thank you

@Hutch118 Hi, sorry to dig this up but did you ever publish your code or push it back?

Thanks

Steven

The kinematics selected is code modded from the hangprinterkinematics. The code is now includes some changed functionality for a 4 wire machine and other things I am experimenting with. For testing purposes, I added the new kinematics to position M669 K13.
I will ask for instructions in how to add the kinematics to the repo when I get the code ready and tested 🙂 The machine seems to be moving as it should(not taking homing into account) and steps/mm is set to 100 at the moment. Homing mode is homeIndividualMotors.

And cool thanks, I'll check the DDA endPoint array, I am trying to get the machine to automatically calculate its dimensions by using the stallguard functionality.