i followed this tut (http://richmondsystems.net/2017/06/18/using-arduino-library-in-eclipse/ )
step by step but at the and i'am getting a bunch of errors:
as you can see, i used here the ESP8266RestClient- library, because i can't found the ESP8266HTTPClient - lib under Eclipse -> Preferences -> Arduino -> Libraries.
@wilriker said in Warning on suboptimal Z-hop:
@deckingman M207 Znnn is the configuration option for Z-hop of (the otherwise parameter-less) G10/G11 firmware retract ..............
So it is.
My bad - sorry. More caffeine needed
@jml said in XYZ movement within the firmware:
@wilriker For G92, it looks like it sets only the machine position, not the position of the tool - so it will offset all the tools and not just the tool whose offset I want to adjust.
I saw your other post meanwhile and yes for this specific case it would not work with G92 - unless you have G10 already set but that is a chicken-egg-problem.
I was shifting 1 position, wasn't enough, and then I ended up changing the bitmap type to uint64_t -- and shift all the way 32 bits -- that way there is no way to create a clash -- I assumed that's what was happening -- I was just trying to find a way out of having to hunt down everywhere the bitmap is used -- but it wasn't that hard. This works fine now. 14 drivers -- all setup
@gtj0 Thanks for the advice, I'm able to use the bmp2c program and the other instructions for adding my own logo to the compiled bin program. Its a nice feature! Would be nice if it could load faster, and I would customize the firmware to display it for a shorter amount of time, but these are minor issues.
Store the actual Z-axis limit or an offset by pressing a button on the PanelDue.
Do you mean store it on the SD card so that the Z=0 position will be the same after a power cycle? If so then the only way I can think of to do this now is:
To find the new Z=0 level, after placing the nozzle 5mm above bed centre, send G30 with the Z probe type set to 0 (P0 in your M558 command).
Then send G1 S3 Zxxx Fyyy (with appropriate xxx and yyy values) to send the head or bed ot the Z-max endstop. When the endstop is triggered, it will adjust the M208 Z limit. Then send M500 to save the new value in config-override.g.
The M586 command followed by M500 almost does what you want, however there is currently no facility to use M586 to probe manually instead of using a switch.
I worked out the maths of the Inverse Transform function by solving the simultaneous equations, having at the time failed to find a solution on the Internet. That was before I found that the magic search term was "trilateration". There are lots of ways of doing it, and I expect man of them are more resistant to rounding error than the method I devised.
@dc42 thank you for the information. I think I will checkout the version matching release 2.01 (d0505c8) as you suggest, then merge recent updates once the code has stabilised.
EDIT: I can confirm d0505... compiles. Thank you for your help.
@dc42 said in ZProbe Mode 4 enhancement:
I/O mapping strategy of RRF is being reviewed because the next generation Duet needs something more flexib
Sounds great! I got some more pins I'd like to remap, I'll wait and see what you guys churn out.
@resam said in LaserWeb4 Support:
Did you see M452? It provides a laser mode. There are a few forum posts here describing how to use it, and also some problems with it.
I'm using LaserWeb together with M452 and M3/M5 command to do laser cutting (no engraving or rastering).
Yes, I'm aware of this, and using it currently.
Just saw the last comment from @dc42 on that thread though:
Support for using the S parameter to control laser power on G1 moves will be added in firmware 2.02.
So this thread just became redundant
Hi everyone, I solved this buying a silicon cover for the heat block (as Phaedrux mentioned) you can get some pretty cheap on Ebay, I also realised that you don't need to have a E3D hotend, they are not available for every hotend, but you can found for the most common. With this the temperature only goes down 5 degrees and in a few seconds it's in the desired temperature again.
This is addressed in https://github.com/dc42/RepRapFirmware/pull/179 but in firmware as @tjb1 suggested. Then it will be only a matter of adding the respective M106 ... commands to your config.g - though I am not sure how DWC will react to setting a fan slider to 100% but the output being limited to e.g. 50%. But since there already is a lower limit I guess it will just handle this out-of-the-box as well.
@dc42 said in Guidance regarding Source Code:
The "main program" file is in project CoreNG because it does initialisation first. It calls UrgentInit and later AppMain in the RepRapFirmware project.
Make sure you use the v2-dev branches of RepRapFirmware and CoreNG because that's where development takes place at present.
I can only see 'UrgentInit' being called from '/src/Platform.cpp', but that's under the main tree, not v2-dev branch.
Can't see 'AppMain' being called anywhere.
I know it's a pain to create, but I think a wiki with some overview and guidance to help understand the software structure and flow process would come a long way in helping developers contribute to the duet project.
Looks like your connection to Duet3D was lost, please wait while we try to reconnect.