[CLOSED] Help! Going nuts with Marlin and my special 3 Z screws.
Z moves go too far if and only if they are combined with X and Y movements. They are perfectly OK with separate G0/G1 Z commands though. I do print without such issues when I rewrite the gcode moves.
In my setup, I “sniff” the Z step/dir directly from the original RAMPS Z pololu socket into interrupts of a GRBL shield. After calibration is done, the slave dispatches the step/dir signals to its own set of 3 pololus drivers.
Now, for some reason it seems that Marlin sends more steps than needed in Z when I combine Z movement with X and/or Y. All this is independent of speed and direction, it goes further than expected.
I could understand it if it traveled less than expected (e.g. b/c of missed pulses). But I really do not get it that I can get more than expected. And even more, why it occurs only when combined with X/Y moves only.
Any clue someone? I cannot understand why route planning could give such a weird behavior.
Are the wires for X, Y, and Z close together? I hear interference can occur, and I could see that causing extra moves. Keeping them separate or twisting them together should cure it. Disclaimer: haven’t tried this myself.
@Lars_Clausen ha, that’s a good hint why it may occur only with X/Y moves. But the already twisted X/Y wires are going to the opposite of the Z step/dir link between master and slave. Then, the 3 secondary Z are also twisted (but the 4 wires as a whole, as my steppers came already wired – so I am unsure it helps here).
Food for thoughts anyway, thanks, but not yet there
Also I can reproduce the symptom, it seems consistent. I would naively think parasitic problems would give different results (statistically, I may be wrong)
+Peter van der Walt no, you are still right anyway.
After I made the GRBL shield slave fully functional, I realized I could get rid of it, and it makes the whole simpler and cheaper: I added two lines from the master to the slave, to select which Z screw to move (0,1,2 for individual axis, and… 3 for grouped/usual Z move!). This way I will be able to control the 3 Z screws completely from the master during calibration… if/when I decide I need no individual FSR status (not sure I want this).
I also have a tiny MCU to filter the FSR analog inputs, as I want them to act as safe, stable binary end stops as seen from the slave (from which they are OR’ed and propagated to the master).
(BTW it is not even GRBL as I eventually rewrote my own stepper-based controlling sw – just b/c I could, and because it made my synchronous calibration simpler. But it is not used when the slave is set to “transparent” mode, when doing the actual printing).
@foosel huh oh thanks. Was pulling my hair. May be I would better stick with Z move on their own line and forget it. I could also ditch the whole RAMPS/Marlin when I am home (I have a smoothie and a replicape in stock). But I cannot leave a bug left in a project. I just really still need to understand
I just ordered some fsrs recently and am awaiting their arrival to set up auto bed leveling. I went with this kit: http://www.ultibots.com/fsr-kit/
It sounds like I will be playing around with some code too. I still haven’t figured out how I’m going to mount then either. I have a bunch of links I saved, but haven’t gone over it all yet. However, one I recall was about moving the probe from checking three points to 9+. See any reason to increase your check points?
I still suspect electrical noise. I can send you a little coaxial cable to shield step and direction individually. I also like Peter’s cmos buffer idea. A lot less to go wrong. For bed leveling, print knobs for the top of the ACME screws and disable steppers from the LCD. You could try this with standard Marlin to isolate the problem.
@Jarrid_Kerns FSR are all made by interlink AFAIK, but this looks like a good kit I. I coded my own median filtering for a better response, and it may be as easy to fiddle with the provided kit (ICSP ). I also have 3 outputs instead of one (more reliability, may be overkill). Multipoint not needed for me, but good if when your bed is not perfectly flat (e.g. bent alu bed).
@Daniel_Kruger thanks for the proposal! I shall try by myself and tell here. Now about leveling: all my hack was motivated by achieving a fully automatic bed leveling & tool height adjustment. And it works, so I would not back to manual mode In addition, I need it anyway to switch and work on an adaptive tool changer…
And yes, I already designed a circuit with two basic logic gates (it only requires 3 OR gates and a 4-line selector). But there are more to code in Marlin when I have no slave, and the filtering may not be very reactive in Marlin. Eventually, I would like to stay as independent as possible from Marlin or any firmware, unless my changes are pulled in the main branches
if using Marlin make sure all axes are disabled: #define DISABLE_X false #define DISABLE_Y false #define DISABLE_Z false
I found my Z was off when DISABLE_Z was set to true because the Z motor isn’t locked during the print, the weight of the carriage can cause the gear to turn.
@Ted_Huntington : heh, a good reminder. I originally drove the grouped 3Z indirectly from the slave (before switching to the “transparent” sniffed mode). So I may be I left the “master” Z release enabled indeed… Now, the current setup keeps the 3Z powered all time at the slave level. So unless it provokes weird behaviors also at the logic level in the master it should have no impact. Will double check for sure, thanks
If it only happens when moving with the X & Y axes, could it be that power is lacking? Also, could it be that your heavily modified Marlin/grbl code is “forgetting” to send all of the Z steps? (read: software bug?)
@Ted_Huntington nope, all my steppers are enabled, so the bug is not here
@SirGeekALot good guess, but I think I would experience more trouble when I enable heating while printing (no hot end, no heated bed when testing here, it should give a comfortable power margin).
@NathanielStenzel it is even weirder… Swapping X with Y is equivalent. Only diagonal Z moves are wrong, just as if my steps/Z were badly configured. But… when I only move vertically it is perfectly fine.
E.g. starting at 0.2mm over the bed at X100 and Y100, if I issue
G0 Z20 / G0 Y120 Z0
then the nozzle hits the bed slightly (no steps skipped). The longer the X/Y move the harder it hits the bed (Z length seems to have a smaller impact).
from there, I just realized that if I move exactly backwards with G0 Y100 Z20 / G0 Z0 I “restore” the initial correct position (I was wrong then: moves are shorter when going diagonal upwards).
Back to X100 Y100 and properly re-calibrated. I send G0 Y120 Z20 / G0 Z0 then it is perfectly OK. Diagonal upwards is fine here (or vertical down correct it). Huh. I’m lost.
Problems in diagonal space makes me wonder if you should look closer at that software code path, and perhaps the math where it gets converted into steps.
@Jeremie_Francois I was hoping to hear more clearly if A, B, C or neither is worse than the others. I was figuring that it is possible that moving all 5 motors at the same time could give you insufficient current to move them all okay. Having the hotend on or off would then probably also be a problem.
There is one other thing that I am curious about. What is “G0 Z20 / G0 Y120 Z0”? I am not used to seeing two Z commands on one line with a “/” between them.
Are you sure your bed is still level after the combination of Z movements with X and/or Y movements?
@SirGeekALot well, the planner & pulse generator is exactly where I do not want to step into in Marlin (and I assume they’re perfectly debugged now, the problem is probably on my side)… I would better switch to smoothieware or redeem instead
In addition, I need it anyway to switch and work on an adaptive tool changer…
