Topics created by Kulitorum

@kulitorum to compile under Windows you will need to do at least the following:

Set your Windows compiler to C++17 or later Deal with any #pragma directives and any gcc-specific attributes. Declaring __attribute(...)__ as a macro that expands to nothing may be a good start. Replace all the FreeRTOS and CoreN2G project files that are needed by RRF by suitable functions. Mostly they will be do-nothing stubs. RRFLibraries includes a couple of assembler functions that you will need to replace by suitable C code, but should otherwise compile.

HTH David

@dc42 Cool, it works now - dont know why it didnt before, but now it does. Thank you for the help.

@phaedrux I mailed it to DC42

That worked. Thanks.

Can you give us some more information?

https://forum.duet3d.com/topic/5909/guide-for-posting-requests-for-help

Does the fuse have continuity?

Have you seen this?

https://duet3d.dozuki.com/Wiki/Connecting_PT100_temperature_sensors

@dc42 what about a binary mode that uses a faster more native access to the hardware versus worrying about GCode at all? It could be variable or fixed length and would open a wide world of options.

It wouldn’t be standard GCode but who cares. This is for the computer to understand not humans.

Without the parser is could be crazy fast and even use less memory.

Yes new slicers would be needed (already covered for OP) but it could be optional or better still just transpile from GCode to this format in the duet or sbc.

Unfortunately the resolution of the image you uploaded is too poor for the characters to be clearly legible.

Which Duet was this, and which firmware and DuetWebControl version? If applicable, which WiFi firmware version?

In RRF 2.04 and later used with and DWC 2.0.4 and later, there is an option to perform CRC checking on uploaded files.

@Kulitorum said in Less then 1 step pr. mm?:

On the Duet3 I am trying to configure a 300x300mm printer to think it's 10x10 meter.

this got me interested. would you share with us what you are building?
a 10x10 meter printer sounds interesting.

Thank you, that worked.

Maybe add a warning message to the "!" in the top left corner?

Kulitorum

@dc42 said in Max actual speed at high path detail:

faster pause code

Thank you for that explanation, I almost figured the same out myself 🙂

Faster pause code would be super - the ability to pause in the middle of a long segment would make a large difference to me.

Kulitorum

I'm looking for M112 behavior that saves the print state so I can resume it.

If someone is getting squeezed in between the printhead and a wall (at 1.5 ton pressure) , 0.5sek is a long time, so using pause for emergency stops is really not a good option.

Using M112 stops instant, but freeze the board so I cannot save the print state.

What I hope for is a M112 version that

stops everything like current M112 Saves print state so the print can be resumed Freeze board

It's not a problem to have to re-home the printer when restarting.

Michael