I was Running 2.02 and then 2.03.
The problem is very intermittent, if there is anything more I can do for you diagnostically to enable a better trace of the problem then let me know and I will try to reproduce it and maybe give you more information what I discover?
Not sure if you find the same thing I am finding.
But I would compile the paneldue and I received no error's.
but when I would look in the release folder form inside eclipse
it would not show any .bin files I thought it didn't compile but when I used the file explorer
and searched the directory they were there...
@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.
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.
@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.
Thank you for the valid points to be considered. I will start at some high level methods, which are not near the hardware. The hardware must be encapsulated into mock objects then.
If the unit tests are successful and useful, you may decide whether it's worth using at a broader level.
Maybe someone has a hint what I should use as framework. From reading the descriptions, I will try RapidCheck. It creates the test cases automatically.
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.
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.
@sungod3k said in Flying extruder with 4th axis:
I found the section about "additional towers to carry flying extruders" in the wiki, when I define the 4th like this does that in include the behavior that the 4axis moves up and down depending on where the x/y position of the effector is? or does this need to be added as an extra command?
That's automatic, you just need to define the XY position of the extruder outlet and the distance you want to maintain between the extruder output and the hot end input.