I just found and ordered 4 lead screw of 1m long, is going to move so much faster, and this way i don´t have to change anything to the original setup for now....after uploading the firmware we will see if aditional features are needed when testing like some system to help the motor not to be super bowncy
Just a status update:
I've added code to https://github.com/JoergS5/RepRapFirmware/tree/v2-dev now, implementing FiveBarScaraKinematics.cpp and .h. The checked-in version is buildable. The necessary changes in the checked out files are described in step 7 of the documentation (I cannot check it in because of later github push reason).
I've changed some details in the documentation also. Next I will finish the prototype build and test the code. One thing I am not sure it is working is the homing procedure.
@falkia Yes! Exactly that, but more spread out arms.
@dc42 Sounds do-able then! Im a fair way off on this project, only really have sketches at this point so ill bear that in mind for when I get to actually building this thing!
Thanks, now it is building again!
My findings during the build process for the Duet Wifi were:
Getting the right branches (and matching versions):
additionally I needed (not mentioned in the howto):
For the DuetWifiSocketServer and the CoreESP8266 I needed the xtensa-lx106-elf-gcc cross-compiler. I found in a project file that you used one that came with an Arduino package. So I also installed the Arduino Package ESP8266 which provided the corresponding compiler and set the paths correspondingly.
I needed to manually add some paths when files could not be found.
Maybe this info is useful for someone trying to do the same.
Yeah unsynchronized is required because I just want it to keep spinning at a constant speed without slowing down when other axes are accelerating/decelerating.
Maybe I can just make two setups. One with a stepper for synchronized. One with a dc motor for unsynchronized.
Or maybe I can have one setup that has a stepper motor, an arduino, and a stepper driver, and a switch. The switch electrically disconnects the motor wires from the duet's motor driver. And it connects the motor to a different motor driver controlled by the arduino. badabing badaboom.
The Duet085, Alligator and RADDS configurations don't build. I haven't deleted them yet in case someone else wants to work on them. In particular, there are a few RADDS users interested in getting RRF 2.x running on it.
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.