Braccoz
About
- Username
- Braccoz
- Joined
- Visits
- 16
- Last Active
- Roles
- Member
Comments
-
sounds like something is wrong with the hotend. is it properly cooled?
-
awesome
-
Repetier said: Since it worked before R8 it must be something that firmware changes. Host has the habit if in manual control and firmware returns positions in answer like ..... X:30 Y:20 to copy them. Is that now the case? That is why I ask…
-
ye my homing order is exacly that. anyway i'm implementing a new feature, (which i could swear there was already, but isn't O_o), that lifts Z on a tool change and moves it back down once it's done this way i wouldn't have to worry anymore about cli…
-
well, i need this to be on the safe side, cause i have clips on the bed holding the glass plate, which means that the extuders are not really that free to move around @ Z0.0 anyway, since it requires an explicit setting in the configuration.h i don'…
-
so in the end i think i'm gonna scrap this idea for 2 reasons, one being that i noticed the commands from the controller don't follow the same path as the gcode commands, thus requiring additional modifications to the code that are far from pretty, …
-
ok i *seem* to have everything sorted out. first, the bug with y offsets and lazy_dual_x was that when swapping extruders the lastCmdPos[Y_AXIS] had to be saved and restored in a similar fashion to the lastCmdPos[X_AXIS] then, i have the extension o…
-
yea so the sledParked changes were very easy except that's only half of the story, and the other half is about offsets. accidentally stumbled onto another bug about offsets with lazy_dual_x: if you have an Y offset for one extruder, home the machin…
-
Repetier said: 1. I use ZYX and it does it only once. Problem is lazy means x moves out first move after homing, so if Z comes after X it is out and that is not intended if using lazy, so we rehome x so it is in park position. 2. Again lazy =…
-
i did some digging and come to some conclusions the 2 "issues" are related to the sledParked logic. about the double X homing, it happens when X is not the last axis in the order, because there is this at line 2068 in printer.cpp if(!sledParked &…
-
fixed that too. it was something related to offsets AND homing when reselecting the currently selected extruder. i figured the cleanest, simplest and best solution would be to just skip executing any code if the next extruder is the same as current.…
-
ok found the bug. basically, without LAZY_DUAL_X_AXIS, everytime a toolchange is requested the X axis is moved to current position (already offsetted) + offset, so basically offset * 2. this also explains why LAZY_DUAL_X_AXIS works. gonna try and f…
-
submitted them. i did try printing with various combinations of settings and i must say that while when LAZY_DUAL_X_AXIS is enabled everything works, there are still major issues when its disabled so more fixes will be needed. of course i verified t…
-
another update: lazy dual x logic seems correct even with ext0 to the right, it just needs a move of ext1 (leftmost extruder in this case) before starting to work correctly so this may be another easy fix if i find the right spot in the code... nev…
-
update: i seem to have found the fix for the non-lazy dual x, it was just a missingPrinter::lastCmdPos[X_AXIS] = lastX;in the non-lazy codepath. the lazy dual x seems to work properly, except for when ext0 is on the right, now working on that
-
tested both with and without lazy dual x. bug is still there i'm looking at the code, i'm pretty sure the fix will just be something very simple like commenting out/adding a function call, but i have to make sense of entire parts of the firmware bef…
-
yes i know that, i just used those numbers for the sake of simplicity trust me it's bugged, i can make a video if you want. on the first move after the extruder select the offset of the previous extruder gets added to the move. note that when just s…
-
think i fixed it, it was really simple. gonna make a pull request tomorrow on github
-
forgot to mention it's a normal cartesian machine as i dig through the code i think these snippets of my configuration.h could be useful to pinpoint the issue: //// ENDSTOP SETTINGS:// Sets direction of endstops when homing; 1=MAX, -1=MIN#define X_H…
-
nvm, fixed it. redid the configuration from scratch, probably it was some parameter about z-probe or bed correction that slipped the first time i don't think that those should be enabled by default tho