You need to send M408 commands to retrieve the responses from commands such as M552.

Thanks, I'll close it then.

@mwinterm would you be able to provide a link for the xtensa-lx106-elf-gcc cross-compiler? This is the only remaining issue I cannot seem to solve and I have tried downloading from several sources but they do not seem to work. It would really appreciate if you could provide some information on this.

That's good. I'm aware of Eclipse and actually use it for some things in all kinds of strange versions. It's a fine tool for development, but not for builds or integration.

I've also seen so many compilers and tools get buried in licenses and obsoletion of platforms that it always lights up alarms to see some massive IDE been mentioned when something is supposed to get built.

I must have done it wrong. You can see the code here

https://github.com/MichaelM4/PanelDueFirmware

@dc42 said in Delay response for Macro called during printing:

When the command is inside a macro file, how long is the delay?

Only one line command in Macro. Sometimes it needs 1~2 seconds, sometimes it needs around 5 seconds. It makes me confused and I doubt that if I have run Macro or not.😅 The important point is it just happens while machine is printing.
0_1558123997792_0269640f-31b6-4441-9eac-e552bd284128-image.png

@giostark said in [solved] BL-Touch deploy only one time with 2.03RC1:

I read somewhere in the "whats-new " that during the probe some deploy and retraction now are automated. Is correct?

That's correct. For some types of probe, when running bed.g you want to deploy and retract the probe just once in the entire sequence, which you can do using M401 near the start of bed.g and M402 near the end. But that's not the case for BLTouch, which needs to be deployed separately before every probe point. So leave the firmware to deploy/retract it automatically.

@dc42 said in temperature sensor pin number change:

not the one you thought it was.

There were two firmwares on the SD card. One for before 1.20 one for 2.0+. Having these both on the SD card causes problems. Now it has resolved.
Thanks,

@dc42 Are you sure it built all of them? For me it builds the active one (which I didn't even notice) plus the one that's linked.

For instance, I went through the CoreNG, RRFLibraries and FreeRTOS projects and made SAM3X* the active config but linked all the SAM4E* configs. When I build RepRapFirmware, it builds the SAM3X* configs plus the SAM4E* configs but that's it. Since those libs are tiny, there's no real downside to building the extra SAM3X* configs and RRF links to the correct SAM4E* versions. Well, "correct" for me since I build Duet2_RTOS.

The Duet_NG folder that is greyed out is the important one. I sometimes find that Eclipse greys out the wrong folder. Changing the configuration to a different one and then back again usually fixes it. However, when the wrong folder is greyed out, the build still works.

The version of Eclipse that I currently use is 2019-03.

I'm sorry to hear that you list your SD card contents.

You can back up the contents of the system folder to a downloaded zip file in DWC.

Hello Everyone,

Thank you so much for the help! This sounds like exactly what I needed. Will definitely update with the results as I move forward.

Mike

Thanks, I'll look into that. It seems I could infer the initial heating phase by detecting the transition from Idle to Printing (heating begins) and then wait for all axis' to be homed (heating complete). It's just for lighting, not critical path.

@dc42
ok thank you... will keep this in mind for sure.

Trying to make a walk through with all the hurdles in a small doc to help noobs like me around.

btw it's also possible to print in mirror mode. The procedure is:

Adjust your M208 and other settings so that X0 Y0 is bed centre (this works better for duplicate mode too, because all your prints can be centred at (0,0) when you slice them, regardless of how you intend to print them).

Use the M579 command to apply a scaling factor of -1 to the U axis during the print.

@dc42 thank jeebus. I didn't change a thing, I don't know why it stopped and then just started working.
Whew!

Thanks for pointing this out, I have corrected it. The latest commits also use the dev branch of CoreNG.