@dan_55 said in DWC Time sync:

@wilriker Thanks ! I will look into that.

@dc42 Yes, I know but DWC always overrides this value when connecting. It's not a big deal, but it creates a little mess in my code and I'd like to disable it.

You will need to patch DWC not to set the date/time in rr_connect, whether you use rr_connect or M905 to set the time and date yourself. I am fairly sure that you can just have DWC omit the date/time parameter when it sends the rr_connect request.

@oliof
I'm planning to port it to Duet Ethernet and Duet Maestro for now, actually I've already ordered a Maestro. I think that support for the wireless variant is possible would would need a bit more effort.

@dragonn thankyou

@bondus my first tests with ESP32-CAM were unsuccessful, I will need more research. If you have hints how I can improve the encoder, please tell me!

My current approach is:

make the printout as big as possible, the resolution is better then. 30 cm diameter means maximum resolution at 600 dpi: 22231 dots, one dot means 1/60 degree. The dots could be subsampled by the camera. I thought about using a neuronal network solution. buy ArduCam OV2640 and OV5647, where the objective can be removed to go with macro focus. For OV5647 I will need a Raspberry Pi Zero W each. There is a breakout version of OV2640.
If resolution is too low, I will wait for the new sensor OV48B ! (a joke, main problem will not be the resolution, but the focus)

@joergs5 said in Is the current v3-dev branch borked for anyone else?:

@dc42 could be this unfixed bug: https://bugs.eclipse.org/bugs/show_bug.cgi?id=235157 but it's very old. There is a possible workaround at the end.

Thanks, I'll try that workaround.

Whoop--I have fixed my own problem. These files were missing because the projects were not inside of the workspace folder created by Eclipse but instead located elsewhere, so they were compiling individually without issue but couldn't link.

The offset of 3A is from the start of prvIdleTask in tasks.s (conveniently, the listing for each function starts at 0), but otherwise that's all correct. However, the only other return address on the stack trace that you listed is 00449ed1 (once in the LR and once on the stack), so you won't be able to go back very far.

I would guess the reason there is no such thing is that there is no standardized peripheral that needs to be controlled by a telnet client, and if used on WiFi it would be subject to uncertainty. I would elaborate a little on the use case and see if you get any alternative solutions, maintaining a custom firmware mod across upgrades could be tedious.

FYI, the lcds mentioned at the marlin github link require another pin to drive the lcd, pin a0
for more info see my post last year https://forum.duet3d.com/topic/6467/viki2-lcd-panel-on-maestro
Unfortunately it was beyond my skill to make the changes needed to add these lcd displays.
I still would really like to see support added for these displays, hopefully you have the skill I lacked to add support for these displays.

@JoergS5
Thanks.

Sorry, there are no overview docs except the readme file. But for RRF3 on SAME70XPLD, if you are using the latest source code on the -v3-dev branch then you shouldn't need to change anything except the Pins.h file. Use the version of it for Duet3_V05 as a model. Everything else is configured using GCode in the config.g file on the SD card.

It helps if the STEP pins to the drivers are all on the same 32-bit MCU port. But you probably won't have that choice as you are using off-the-shelf boards. So you will need to change the 3 functions at the end of Pins.h. For guidance on how to do this, take a look at the same 3 functions at the ends of Platform.h in the dev branch of RRF, in particular how they were implemented for Radds/Due.

When I built the SAME70XPLD configuration a few days ago, it compiled with no errors, just a few warnings caused by the pin table being empty.

HTH David

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,