Finished the initial build (basic kit + power pack + heated bed + TMC2208's) and have had good results from initial prints.
After build / config and installing the Octoprint there is odd behaviour.
When you start a print (from Octoprint or from the control screen on the printer) if Octoprint is powered on then both X & Y axis try to move beyond their maximum limits, the Z axis goes too low and if printing does start it's at least twice the size of what was expected. This is only fixed by turning Octoprint off before starting to print.
Also, I think it has been noted on the forum before, the supplied power adapter for the Raspberry Pi does not supply sufficient current for a Pi model 3B+ to operate. I have had to connect to a separate power supply (this makes it easier to switch it off!)
Any help would be appreciated - I'd also suggest turning off the Octoprint module if you are having issues on first prints / homing etc. until you have the printer working well without it.
Simon.
Update: I've found the 'odd behaviour' happens when I turn the Octoprint (Pi) on before the printer and let it load.
Example: If the printer is turned on and I select 'Auto Home' on the printer controller then:
1) Z axis raises about 10mm
2) the X & Y home (top right next to the Z axis) (clicking the stop switches)
3) X & Y move to the centre and the z-axis slowly lowers down - up - down
If Octoprint is already running when the printer is powered on. Then auto home from the printer control panel does this:
1) z axis raises about 20mm
2) 2) the X & Y home (top right next to the Z axis) (clicking the stop switches)
3) X & Y try to move beyond their max movement (bottom left) and jam there.
Just to confirm - no control actions sent via Octoprint (Pi) in the above test and the settings in Octoprint are as per the install instructions (300 x 200 x 200)
It seems to work OK if Octoprint is powered on after the printer (Marlin) has loaded so that's my work around.
Simon.
I just picked up a "buck converter" off of Amazon. It's basically a DC-DC converter with a pot on it. You turn the pot back and forth and you can control the voltage of the output. My plan is to install it on the DC in to the mosfet for the heated bed. That way I can leave the bed always plugged in and have the Pi on. I've been toying with two different ways of controlling the printer. On my other printer I have OctoPrint control a smart power switch to turn off a light and the printer when not in use. Since this printer has two power inputs, one for the bed and the other for the printer I thought about putting a relay between the socket and power in on the mainboard. Then I can use the "Enclosure" plugin to turn the relay on/off via a GPIO. I probably won't get to this for a bit. I want to work through all the basic printing issues before I try setting this thing up in my workshop. I need to hurry up, though. My wife is starting to drop hints about the pile of benchy's and guide prototypes that are piling up on the desk!
I also had frequently hang ups and reboots of the Raspi which were gone when I supplied the Raspi by an external power supply.
Then the setup works stable with Octopi.
Only the uploading to the SD card seems to be not very reliable. If I load the files up to the Raspi it works.
Just want to verify that you've defined the printer bed volume and origin location in Octopi.
And yes, the included USB adaptor is junk. I even tried to block off the 5v pin on the USB cord to see if maybe the main board was drawing too much power from the Pi, but that didn't help either.
Would you mind posting some pics of the prints you're getting and possibly help post some hints? I'm still struggling to get an acceptable print.
As for OctoPrint, click the wrench icon and select "Printer Profiles". There should be a profile you created during setup for the AXIS printer. Click the pencil icon on the row to edit it. Make sure you have each of the values set correctly.
These limits should come into play when you're using the jog controls from the UI. If it's still a problem you can set a custom bounding box to bring in the limit some. If this is how you're causing it remember you can jump over to the console screen to see the command that OctoPrint is sending. Just remember to hide the temperature notifications before you do this otherwise it will get lost in the noise.
Now that said, if it is doing this during a print that would be weird. OctoPrint should just be sending the gcode to the printer without modifying it. I think there may be a slicer you can set in OctoPrint as a a plugin so you can upload a STL and it will slice and print all from the server. However, if you're uploading the gcode from Cura then it should execute it as is.