XBuddy board GPIO?  

RE: XBuddy board GPIO?

It won't let me edit, so I'll post here. It *LOOKS* like the xBuddy board has an I2C port, which *SHOULD* allow me to connect this, if I can get firmware access to control it:

https://www.adafruit.com/product/4808

It's an I2C 4-pin PC fan controller, with temperature sensor. Any reason it wouldn't work?

RE: XBuddy board GPIO?

I haven’t dug into the schematics, but I know the board at the hotend uses I2C to communicate with the main board.

I2C is an addressable serial interface. All devices you want to talk to are on the same bus. This means that even if the buddy board does not have a spare I2C connector, you can still use I2C devices by tapping into the I2C line going to the hotend.

However, that’s just the physical connection. Everything communicated to by I2C needs to have code in the firmware for it. I’ve been using a number of those Adafruit boards with the STEMMA QT connectors myself, for my remote weather/air sensor project. But, I don’t write any of the code for the I2C bit. I just use pre-made libraries that handle that.

None of this is on my printer though. The firmware for the MK4 is open source, so you could add it, if you know what you’re doing. I wouldn’t, as there (probably) wouldn’t be any libraries for that device that would work on the MK4. Adafruit makes Arduino and usually Python libraries for most of the products they sell, but those are limited to Arduino-compatible boards in general. Not Prusa Buddy Boards.

But it is certainly possible, since everything is open source. Just a question of how much work you want to do and what your skill set is.

Unless that all sounds fun and up your skill set, then what would be far easier is to buy that fan control board from Adafruit, along with an Arduino-compatible microcontroller board (approximately $20), a temp sensor (couple bucks), and a display of some sort, and write a simple program to control the fan based on temp, with some buttons to let you select the material (or temp) manually.

If you’re interested in the latter idea, let me know and I can provide you with some assistance in getting something set up, especially as I’ve been thinking of doing something along these lines for my upcoming MK4 & enclosure combo.

RE: XBuddy board GPIO?

I do believe you may be able to get arduino library to work as prusa3d.com board take somewhat the same code unless it's different code to the mk3

RE: XBuddy board GPIO?

I was thinking this would not work, as the MK4 uses a 32-bit micro, and the MK3 uses an 8-bit micro. But I did a quick search and part of the Buddy firmware is a Sparkfun driver for an accelerometer. Looks like the MK4 may use an ESP32 micro, so code written for the ESP32 should work. This may or may not include various Arduino libraries.

However, this is not the same as writing code for an Arduino, using the Arduino IDE. You must get all the original code, modify (however slightly or much) any necessary libraries to work with the MK4 code, compile the entire project, and then upload this custom firmware to your printer (which requires another step).

Posted by: @hello

I do believe you may be able to get arduino library to work as prusa3d.com board take somewhat the same code unless it's different code to the mk3

RE: XBuddy board GPIO?

Yeah I know it would be a lot im just saying it's possible and yes especially 32 code should work if you re define some things 

RE: XBuddy board GPIO?

That's really interesting. So it wouldn't be too difficult to make a y-harness for the accelerometer port, to add additional I2C devices.

That said, compiling firmware is a little much for me. I've programmed ATtiny microcontrollers from scratch, but doing a full firmware, and making sure that none of my code borked something critical is a bit more than I trust myself with. I'll probably just do a discrete microcontroller, and dial in the chamber temperature manually.

kinda sad, because having it controlled by the mainboard would let it use the bed heater to warm the chamber up to a set point, and start the print once build chamber reached your set point.

Related: Prusa chat support said that, after moving the PSU outside the chamber, the Mk4 should be limited to 42° C (107° F), in accordance with the "prusa enclosure" manual. Previous discussion, on the Mk3, had said up to 45° C (113° F) Not a deal breaker, but something to note.

RE: XBuddy board GPIO?

if i build a lack enclosure how do i make sure it doesn't get above that threshold in temp?

Posted by: @fil4ment

That's really interesting. So it wouldn't be too difficult to make a y-harness for the accelerometer port, to add additional I2C devices.

That said, compiling firmware is a little much for me. I've programmed ATtiny microcontrollers from scratch, but doing a full firmware, and making sure that none of my code borked something critical is a bit more than I trust myself with. I'll probably just do a discrete microcontroller, and dial in the chamber temperature manually.

kinda sad, because having it controlled by the mainboard would let it use the bed heater to warm the chamber up to a set point, and start the print once build chamber reached your set point.

Related: Prusa chat support said that, after moving the PSU outside the chamber, the Mk4 should be limited to 42° C (107° F), in accordance with the "prusa enclosure" manual. Previous discussion, on the Mk3, had said up to 45° C (113° F) Not a deal breaker, but something to note.

RE: XBuddy board GPIO?

simple, but time consuming way:
Put a thermometer in the chamber, and open the doors if it gets too hot

better way:
use a cheap ebay temperature controller to turn a vent fan off/on at a set point.

best way:
use a microcontroller to control the vent fan or a vent aperture in the top, with some form of progressive or PID control, to more closely control the temperature.

RE: XBuddy board GPIO?

kinda sad, because having it controlled by the mainboard would let it use the bed heater to warm the chamber up to a set point, and start the print once build chamber reached your set point.

Could you have the microcontroller send a pause signal to the printer automatically, after you tell it to print, and then send it a resume command once the chamber reaches proper printing temp? I know you can send commands via serial, but I'm unsure if you can send a pause command via serial if you didn't start the print via serial.

But if you can, this would allow you to use a microcontroller to do exactly what you wanted to do with the buddy board.

I will actually try this myself now, because it would be great to be able to do an ASA print and tell it to print, but have the micro keep the printer from printing until it's at temp. Obviously you could just tell the printer to pre-heat and then come back later to start the print, but that's not as clean.

RE:

That's a damn fine approach! Please let me know how your test turns out! Also, are you on a Mk3 or a Mk4? I currently have a Mk3, but Mk4 is on the way (eventually)

If you have to send the "start" command, I'm not above picking the print, starting it, pausing it, and then activating the microcontroller, so that it sends the start command only.

You also have the heater timeout issue, which can be "bypassed" with a consecutive "start" and "pause" command, resetting the heater timeout?

RE: XBuddy board GPIO?

Will do.

I'm on neither right now. I have a MINI+ I got in February, and my MK4 kit just shipped today, so I expect to have that up and running by early next week.

RE: XBuddy board GPIO?

kickass. Can you point me at any kind of serial documentation that might already exist for the mk3/mk4 (or mini, if that's all you can find)?

RE:

I don't have any serial documentation persay. Prusa has an article on using Pronterface, which is included by default with PrusaSlicer on Windows. On Linux, it's not, and I couldn't get it to run on Linux Mint, but I did get the console version (Pronsole) running and talking to my MINI+. I used it initially when my MINI had some issues with bed leveling that appeared to end up being a bad firmware flash. I was commanding bed level and viewing the raw height values back for troubleshooting.

The printer showed up as a USB serial device. And I know that Octoprint runs over the USB-serial as well, so documentation for that project may be useful. As I understand, Octoprint works by streaming the gcode to the printer live, via the serial-USB connection, rather than the printer reading the gcode off the USB drive (or SD card for MK3). So I'm not sure what commands, if any, are allowed via serial while the printer is printing from a gcode file on the USB drive.

Also, anything that works with the MINI will probably work with the MK4. The firmware is largely shared between the MINI/MK4/XL, as all use the same 32-bit microcontroller in a buddy board. The layout of the buddy board changes slightly between models, as does some of the firmware items. But there's only a single GitHub project for all three printers. As opposed to the MK3, which used a 8-bit microcontroller and has completely different firmware from the three newest models.

RE: XBuddy board GPIO?

I'm pretty sure gcode through usb overrides usb or sd

RE: XBuddy board GPIO?

Definitely would want to use the pronterface (now "printrun") code base, and not the octoprint. I don't want to run all of the code through serial, just pause/print command. Honestly, I could write custom pre-print code to crank up the bed temp, drop the extruder temp, and then pause, waiting for a serial command, and then reset the temperatures to normal temps after the command is received, if I can get the serial control to work with arduino.

That would allow a single command from the microcontroller, once the chamber is up to temperature, and if the microcontroller gets confused, it won't mess up the print, because it's not sending a pause.

RE:

I realized I was thinking serial, which is easy to do with a microcontroller, except that the MK4 has a usb-serial converter. Talking to that with a micro may not be possible (with a Pi running Linux you could of course). Unless they have pins on the xBuddy board that break out the serial that could be used.

My MK4 is supposed to arrive Tuesday. I also could not find a schematic for the xBuddy, I don’t think Prusa has released it yet.

But on your comment, could you just do custom gcode that heats up and pauses for a time that is determined to be enough to heat the chamber, then start printing? Skipping the micro to printer interface entirely. Then the micro just controls the fan to keep the chamber from overheating. Seems like this would work unless you’re talking doing this for prints you sell and time is very critical. 

RE: XBuddy board GPIO?

I think I may have found another viable option, if I can figure out which "pins" are available, on the board.

https://reprap.org/wiki/G-code#M226:_Wait_for_pin_state

with this, I would just have to have the arduino drive a pin high when temperature was reached.

RE: XBuddy board GPIO?

Nice! That looks like the cleanest option!

RE:

But that, again, wraps back to my question of GPIO. Which pins are usable, and how do I connect to them? I'm interested in Mk3 as well as Mk4, since I have one, and the other is on the way. I know the Mk4 schematic isn't available, yet, so I'm not holding my breath on that one.