I raised a bug and it turns out it was a config setting conflict. Z_PROBE_LOW_POINT wasn't low enough to allow probing to work. See issue on github for more details:by Mark Benson - Firmware - Marlin
That makes sense. Have increased the number of probe points and am back to probing in one spot again even when executing M502 ;factory reset, M500; save. I've tried G28 before G29 P1 just in case (even though G29 P1 homes before probing). Have reduced the number of points down to 3 again with mesh_inset @ 5 but no change. Will raise a bug.by Mark Benson - Firmware - Marlin
Which led me to this comment Ran M502 to save the new config values into EEPROM and then M500 to load them and its now moving. Now have to reset a few values and go from there...by Mark Benson - Firmware - Marlin
Enabled debug as per this comment And there are lots of 'Error: Probing Failed' messages... Probing mesh point 16/16. >>> probe_pt(133.33, 133.33, raise, 0, probe_relative) current_position=(103.33, 128.33, 8.70) : >>> do_blocking_move_to(103.33, 128.33, 8.70) <<< do_blocking_move_to current_position=(103.33, 128.33, 8.70) : set_probe_deployed deploy: 1 do_proby Mark Benson - Firmware - Marlin
The X_MIN_POS & Y_MIN_POS in the comments were as measured when homed. That is, the nozzle is off the bed when homed. I set them to zero to see if that was causing the issue with the head not moving. If I set the X_/Y_MAX_POS to keep the nozzle on the bed the probe is off the bed. If I constrain it so the probe in on the bed, I lose printable area. The second issue I was seeing was raised oby Mark Benson - Firmware - Marlin
Back to UBL and selecting 'Edit mesh' from the LCD allows me to select the probe points and moves the head to each point but its using the hotend location rather than the probe so the points on the right of the bed put the probe over the edge. If I add to the mesh inset the points on the left and front are too far from the edge... doesn't appear to factor in the probe offset... but I guess that'sby Mark Benson - Firmware - Marlin
Tried a bunch of different MESH_INSET and grid sizes. Moves once then probes the same spot repeatedly. Fetched new from github and re-created the config from the new files and its still probing in one spot... Tried 3 point leveling - homed then moved to the front left of the bed probed once (said 1/3) then stopped, saying printer ready?!? Linear & bilinear does the same. Mesh levelling aby Mark Benson - Firmware - Marlin
No change with MESH_INSET set to 11. With grid size set to 10, it did the homing then moved really quickly in +X about 10mm then probed that spot 100 times.by Mark Benson - Firmware - Marlin
/** * Points to probe for all 3-point Leveling procedures. * Override if the automatically selected points are inadequate. */ #if EITHER(AUTO_BED_LEVELING_3POINT, AUTO_BED_LEVELING_UBL) #define PROBE_PT_1_X 35 #define PROBE_PT_1_Y 180 #define PROBE_PT_2_X 35 #define PROBE_PT_2_Y 35 #define PROBE_PT_3_X 170 #define PROBE_PT_3_Y 35 #endif Thanks for the suggestion but it hasn't mby Mark Benson - Firmware - Marlin
I should have added that it homes x, y & z without issue when I select 'build cold mesh' from the UBL menu. It then shows 'Doing G29 1/9' probes (moves up and down in z exactly where it homed, doesn't move in x or y) and then does that 8 more times in the same spot.by Mark Benson - Firmware - Marlin
Hi all, Does anyone know why the head doesn't move in x or y when attempting to build a UBL cold mesh? FWIW I'm doing this from the LCD menu. This is on a Bigtreetech skr1.3 and the Marlin 2.0 bugfix branch but I've seen the same behaviour on a RAMPS and Marlin 1.x. I guess it must be something in my configuration given that I've seen it in both, but the 2.0 config was done from scratch and Iby Mark Benson - Firmware - Marlin
Have you added the non standard libs to the Arduino IDE? I have just complied it successfully in the 023 IDE with the libs linked to from the SphereBot github readme. It errors in the 1.0.3 IDE but I did compile it in the 1.0 IDE a while ago.by Mark Benson - General
Hi Edward, I would be interested in attending if I am able (have a holiday booked for that week - though I may not be going away). I have a RepRapPro Huxley and am giving serious though to building an i3 Prusa. I started printing parts for a MendleMax but funds are tight so the i3 may be a cheaper option. What printer(s) are you running? Markby Mark Benson - West of England RUG
I figured out what was going on. (And could kick myself for missing it these past few days) The feeder.py resets the Arduino Uno (rev2/rev3) boards when it creates a serial connection and starts sending data before the Arduino is ready. I've modified feeder.py to take this into account. I'll remove the files from the posts incase I change it again. Grab it from github.by Mark Benson - General
I've tidied up my take on feeder.py, taken out all the extranious print statements and put back the egg displacement stuff. I added the timeout as a variable as I was changing this a lot while testing. This works on my bare test Arduino, yet to be tested on the eggbot itself. File removed: Now on githubby Mark Benson - General
Seems to be working now. I should have said that the first line sent timesout. Not sure what the Arduino is doing with it. Will try and figure that out when I have the rest of it working. Getting jagged drawings now so gotta figure that out.by Mark Benson - General
This (file updated - see later posts) seems to work* and does look for the the ok response from the Arduino rather than assuming as \n means the data was read and was ok. *I say seems to work as I am testing on a bare Arduino. Will test on the full Eggbot tonight. Also it isn't based on the feeder.py with displacement. I will update the correct file later. #response = sphereBot.readline()by Mark Benson - General
However I do see things like this: "First read of serial port. Got back ok:G1 X-22.08 Y-0.14 FG1 X-24.74 Y-0.14 F200.00" Where there are two commands mashed together on one line and the rest of the commands are missed. This is what I meant when I said it gets out of sequence. Josh, I did try enabling autohoming but it didn't make much difference other than trying to home the axis but I don'tby Mark Benson - General
I think I might be right about the serial.readline() blocking in feeder.py... There is still something else going on but if I set the serial connection to timeout (sphereBot = serial.Serial(DEVICE, BAUDRATE, timeout=10)) then it seems to work after hanging on the first line for 10 seconds the rest seems ok. if options.wantToSend: #Default is true print "About to write ", liby Mark Benson - General
mydogjustice Wrote: ------------------------------------------------------- > Mark - I never got the python scripts working > either. Same conclusion that the Arduino wasnt > sending an ack after receiving a code line and > never moved forward with the gcode. Have you > changed the two lines I mentioned? Thats what it > took for me to get mine working with the ruby > scripby Mark Benson - General
I'm still not totally sure what is going on or where the problem lies, but I'm getting closer and I was able to get feeder.py to send a small gcode file and have the eggbot print some recognisable text. Its a long way off nice and smooth but that is another issue. I basically removed the check from feeder.py that looks for the 'k' sequence of chars sent by the arduino after receving a line of gcby Mark Benson - General
Hi All, I've assembled my printed eggbot and seem to be having very simmilar problems to Josh. I'm able to manually send Gcode commands one at a time via the Arduino serial monitor and the motors and servo respond as expected. However I don't get very far when sending an Inkscape generated gcode file (unicorn plugin) via feeder.py or feeder.rb Feeder.py hangs early on (sometimes the servo wilby Mark Benson - General