Braccoz
About
- Username
- Braccoz
- Joined
- Visits
- 16
- Last Active
- Roles
- Member
Comments
-
i've just finished the print that failed yesterday, again from sdcard with host connected. note that i homed from host before starting the print. the print finished and then the host basically caught up the x y z position (i saw the correct coordin…
-
but i usually print through host and usb, and the bug happens sometimes. also, it would be really nice to have the host read the printer echo back gcode so the host can visualize the progress and know where the nozzle is...
-
it's this one https://www.youtube.com/watch?v=4c2KrfQ5QMk& i made it to explain the difference in my implementation before it got merged
-
that's something that you usually do in the custom g-code settings of the slicer. anyway iirc you can store some g-code commands in eeprom that will get exectued by the firmware at toolchange. look at repetier.ino to find the g-code to store the co…
-
great news, looking forward to it
-
i got it from him. no problems. but i agree it doesn't look professional at all
-
you can get the ruramps4d here http://ruramps4d.ru/en/main/
-
sam3x8e based boards specifically: Arduino Due with RADDS Arduino Due with RAMPS-FD Arduino Due with RAMPS-FD V2Felix Printers for armDAM&DICE DUESmart RAMPS for DueSmart RAMPS for Due with EEPROMUltratronics BoardDUE3DOMDUE3DOM MINISTACKER 3D…
-
there is no guide but i suggest you use the new dual x mode. there is a brief explanation in the sample configuration.h 1. dunno, but i guess you have to switch to extruder 2 and then just move X 2. you connect it to x_max pin. assuming radds has x…
-
nevermind all this, found the culprit in ui.h. will make fix and PR
-
ok so adding #define SDSUPPORT 1#define SDCARDDETECT 51 to displaylist.h in the proper section makes it work. so there must be something somewhere that undefines the values from both configuration.h and pins.h. clues?
-
have you double checked the configuration.h ? most likely something slipped. anyway, keep in mind that with dev version DUAL_X_AXIS_MODE 1 will actually have effect and it will NOT behave like it did with master version. you may want to reset your …
-
are you using master branch or development branch? because if you are using master, disregard what i said, because that branch does not have new dual x mode implemented. i strongly suggest you switch to development branch so you can make full use …
-
when everything is setup correctly both heads won't be able to crash into eachoter, so if they do, something is wrong. if you're using DUAL_X_AXIS_MODE 1 you will not be able to use LAZY_DUAL_X_AXIS. (it's not needed really) X_MIN_POS should be th…
-
ok thank you
-
hmm. should i be worried about the communication errors?
-
no problem, thank you for the awesome work.
-
finding the right words is difficult here, as anything is kind of ambiguous. but basically it's completely different from old system. you have to play around with 3 values to align extruders and not make them crash: XMin, XLength and right extruder …
-
yep, tested both issues right now and everything works. my guess is that you have some setting wrong. also, keep in mind that extruder 1 does not mean left or right. it depends on the X_HOME_DIR. so, if you have X_HOME_DIR = -1 then Ext0 is left, …
-
uh. both shouldn't be possible. if configured properly heads won't crash ever. if they crash it's because the lenght of x axis is < than bed size + left and right carriage. in that situation you have just to increase XMin (or rather decrease, as …
-
pr done. i added some explanation in the config as it was a little obscure for first time users
-
precisely. anyway, no need to remove anything now imho, code looks tidy enough to me. gotta test some more and then i'll make the pr for v2 i suggest this mode only. then users can get the old behaviour if they really want by just playing with offs…
-
here's the video. i hope it's sufficient to show the working of the various modes. will make more if needed
-
removing LAZY_DUAL from v1 does not make much sense, some user may actually use it (highly doubt tho, more on that later) so better leave it. just don't bother implementing it in v2. i'll make a video showing you the various modes and it'll be clear
-
that was the old behavior, kind of. except that with old system you are forced to put xoffset to both extruders so that they don't crash into eachoter, effectively making any extra X space outside bed area unavailable, so that condition could never …
-
maybe i didn't explain it correctly. you can think of this mode as something inbetween standard dual_x and lazy_dual_x. basically, the carriage will be parked/unparked normally, except for when the current carriage is already in parked position. th…
-
i'm at the point where the code is working, i just need to test and clean stuff up, i ended up doing as you said and did not introduce new parameters, however since it's a completely different feature than LAZY_DUAL_X it would be misleading and prob…
-
on the subject of V2 i took a peek into the dev2 branch, i can answer myself to the second question: it is 100% different from v1. the good news is that your implementation in V2 seems to basically implement already what i am talking about here, as…
-
great, thanks
-
afaik marlin used to have only 1 step value for all extruders last year, but looking at the current release it seems you can specify e steps for each extruder. dunno if that can be set in the eeprom tho