Fill out above information andin all cases attach yourklippy.logfile (use zip to compress it, if too big). Pasting yourprinter.cfgis not needed Be sure to check our “Knowledge Base” Category first. Most relevant items, e.g. error messages, are covered there
Describe your issue:
Recently I was trying to perform a few tests and wanted to send multiple move commands to the printer via copy-paste. I could send as many Z commands as I wanted but when I added X commands there was an error. After the first X move, I received an out of bounds error and it didn’t matter what locations I told it to go to. The only workaround I found was to send a G28 X before the next X move each time.
I don’t have the block I pasted but it was basically this and variations of it.
What I ended up doing was adding ‘G28 X’ before each Z move. It’s like it forgot its position between moves. I say that because at one point I told it X50 then X20 and it moved an additional 20 over 50.
Move out of range: 115.000 115.000 -10.000 [0.000] # Z too low
Move out of range: 225.000 115.000 525.013 [0.000] # Z too lhigh
Move out of range: 225.000 115.000 425.013 [0.000] # Z too high
Move out of range: 335.000 115.000 180.057 [0.000] # X too high
Move out of range: 263.000 -9.000 180.012 [0.000] # X too high
Move out of range: 413.000 -9.000 180.012 [0.000] # X too high
Move out of range: 237.000 -9.000 179.950 [0.000] # X too high
Do you mean at any point during the life of my setup? Or did I issue the command manually? In startup GCode its possible.
The odd part is that I just tested again, check the log I attached, and I ran the Z up and down, then to the top and back, and it’s taking the command as absolute, as I assume it should. I’m not sure why it thinks I wanted to move Z to 425 and 525, that isn’t how the command read and it would only happen after an X move, as you can see in the new log. The issue didn’t occur when only moving Z.
I had another look on the log and the basic modules.
3rd party macros are in responsibility of the authors.
I can’t tell if there is something wrong.
But I found a G91 in [gcode_macro _TOOLHEAD_PARK_PAUSE_CANCEL]
I noticed that the homing is way too fast. This is a precision act and should be done slow.
You may stay with the default (5 and 2.5, maybe 10 and 5), but 100 and 20 is too fast.
Also, in [stepper_y] you have a pull-up resistor configured for the endstop_pin, in [stepper_x] not.
I’m not sure on the pullups, I used the config in the example for the Kobra Go and this is an Anycubic board we’re talking about… They do some weird crap to save a $, actually pennies. i.e. UART Mux to the knock off 2208’s to save 3 pins.
Hmm now that you say that I wonder if that’s the “default” of the 4 drivers, because I was thinking one of them could be used on the UART line without selecting it. Anyway, different topic all together relating to the board, driver, firmware and reverse engineering.
Circling back to the first thing you said though, I don’t believe I have any 3rd party Macros. Could that of been from S3D slicer? When I was troubleshooting some issues I changed between profiles, and some had GCode from Marlin in them that I didn’t notice at first.
The homing speeds are reduced substantially after the bump. The quick speed is just to get there then it slows to a crawl (2 on the Z) to do the actual probe and 20 on the X Y to re-hit the switches. My default speeds are a little slower than what’s currently set. I was testing a few things out and it was easier with a little quicker speeds.
Edit: On my end I can move on, but this might warrant some further investigation if its a manifestation of an underlying issue that may affect others in a similar fashion.
Thank You for taking the time to look over my configs and troubleshoot through this with me, I sincerely appreciate your time.