Heated Bed Integration

[BlackholeBun]

My apologies for this not being an issue.

I wanted to get in touch with you guys about integrating support for Chase's Heated Bed. I'm the FW dev for the controller and I'd love to see integration with your octoprint extensions.

Chase mentioned that he had given my info to a couple of different people who were interested in adding support for the heated bed. I don't know if we were ever in contact or not.

If your willing let me know and we can collaborate to get that done. Should be pretty easy. It just uses a serial connection.

Thanks,

loswave

[donovan6000]

Yeah, Chase just messaged me yesterday about getting in contact with you. Adding support for the heat bed sounds good with me :)

So tell me everything I need to know. Did you stick to using the standard G-code heat bed commands, M140 and M190, or is it using a different kind of protocol. What's the USB VID and PID of the Arduino, or FTDI chip, being used? Does all the printer's calibration routines, G30 and G32, all work when the heat bed is in place, or are we stuck with manual calibration? Does it have the same dimensions as the bed that comes with the printer and how much higher up is it?

Thanks, donovan6000

[BlackholeBun]

Awesome!

At the moment I still have a lot of debug stuff running, so it's final configuration will change a bit. Right now it does not use gcode because we wanted to make it user friendly, but if it makes a big difference I'm sure I could implement that, or something like it.

Right now it reads out temp, adc value, and goal temp every couple of seconds. Temp commands are issued via "s <0 - 110>" so "s 60" for instance, or "s 0".

This is a serial connection at 115200 baud. As far as I know Chase is using arduinos all from the same source. So provided his are the same as what he sent me they are chinese arduino nanos running the CH340g. This is the chip that showed up shortly after FTDIGate happened if you are unfamiliar. You do need to dl a driver for windows but I have read that linux should already have what it needs. Either way, the official drivers are at: http://www.wch.cn/download/CH341SER_ZIP.html. Yea chinese site sketchy I know. They have drivers for windows linux and mac os there. I know the windows drivers work fine.

The built in printer calibration still work ok provided the bed has something on it. Either Buildtak or PEI. Otherwise you'd be ramming the nozzle into aluminum, which would be sub optimal at best. A note however, I just tried that last night and found that their calibration routines really have not improved since I was using them in April. It still fails to calibrate at the right height...

The dimensions don't change but the bed is a little higher up. I think Chase said that it should sit like 7mm to 10mm higher. Mines a bit higher than that because I need to print new mounts.

I'll check the PID and VIDs when I get home from work.

On another note I'm thinking I might add a mode to the firmware specifically for communicating with your plugin. I'm thinking that you could send a command on port open, or if you receive unexpected comms from the bed controller which would put it into this mode. So something like sending G to it to get it into that mode, then just send a t to get temp or a number to set temp or something like that. Let me know what works for you.

Let me know if you need anything else and I'll send it along when I get the PID and VIDs.

Thanks,

loswave

On Wed, Jan 27, 2016 at 4:20 AM, donovan6000 notifications@github.com wrote:

Yeah, Chase just messaged me yesterday about getting in contact with you. Adding support for the heat bed sounds good with me :)

So tell me everything I need to know. Did you stick to using the standard G-code heat bed commands, M140 and M190, or is it using a different kind of protocol. What's the USB VID and PID of the Arduino, or FTDI chip, being used? Does all the printer's calibration routines, G30 and G32, all work when the heat bed is in place, or are we stuck with manual calibration? Does it have the same dimensions as the bed that comes with the printer and how much higher up is it?

Thanks, donovan6000

— Reply to this email directly or view it on GitHub https://github.com/donovan6000/M3D-Fio/issues/56#issuecomment-175504655.

[BlackholeBun]

The VID is 1A86, PID 7523. I took a look at the code to see if there was a way I could make the interface a little easier to deal with and added another mode to facilitate this.

I would have had to rewrite quite a bit more than I would like to make it run gcode, but what I was able to do easily is build a mode that mimics the gcode functionality you would wand from a bed.

So here's a quick break down of how that works. It takes about 2 to 3 seconds to boot up. Once it does it outputs it's standard information by default every 2 seconds. You will want to send it and "i" followed by a return. This will put it into that mode. Once there you have the following options: s followed by a number sets temp just like m140. w followed by a number is basically m190. It starts heating and outputs the temperature 2 times per second until the goal is reached. t will just make it give you the current temperature.

I was thinking that should be pretty easy/straight forward to translate. I working on setting up a pi for the micro as we speak. Once that is running I will be able to test for when we get to that point.

Let me know if you need more info.

Thanks,

Loswave

[donovan6000]

Seems simple enough. Just pushed some code to the devel branch to try to get it working with the heatbed. You can install it with:

pip uninstall OctoPrint-M3DFio
pip install https://github.com/donovan6000/M3D-Fio/archive/devel.zip

It uses a separate thread for monitoring and initializing the heatbed whenever it's connected. It converts all M140 and M190 commands to the s and w format and sends them to the heat bed.

Just to clarify a few things. Do I need to send "i\r" or "i\n" to put it into a mode where I can send it s, w, and t commands? And do I need to send carriage returns or newlines with the s and w commands, like "s 50\n" and "w 90\n"? Does it send any kind of a confirmation after it has finished completing a w command? The only times it outputs the temperature are when sent a t command and when processing a w command?

[BlackholeBun]

For whatever reason my email responses don't seem to have made it in here so I'll paste them below:

Cool, I'll check it out tonight.

Specifically it's looking for a \r to process a command. So yes, you will need to send that after the i as well as after each s, w, or t command. For example "s 50\r". It does not send any confirmation but I could add that no problem. I could have it send an "ok" or just a "k" after a command is received. As for the temperature, correct. Currently it will only out put following a t command or while it's heating up from a w command. I did it that way because that's how most printers work, but I could make it out put the temperature on any arbitrary time interval. So if you wanted it to output temp every 1 second, or 10 seconds or whatever I could add that.

Let me know on those and I'll make the changes.

Additionally I'm having a bit of trouble. If I try to install that dev package I get permissions issues. I'm also having a couple other issues that I assume are because I don't have the printer plugged in, I'll see if I can get that stuff straightened out when I get home.

Thanks,

loswave

[BlackholeBun]

I can't seem to get anything installed right. If I install the current release either manually or through the plugin manager. Either way once installed it loads the page then displays a message stating that I was disconnected from the server and the button below will reload the page. It just loops like that until I remove the plugin manually and restart the service.

My only guess is it doesn't like my raspi v1? This is a newly created octopi image so it's running octopi 0.12 with octoprint 1.2.8.

Seems like the message is a timeout. If you continue to wait for a couple more seconds after the timeout it will autologin in the background, but the message is over it so you can't do anything about it.

[BlackholeBun]

Ok, got the devel version installed and working. Had to sudo pip install. Connection to the micro works fine.

I plugged in the heated bed and got a green message stating that it had detected the heated bed and connected to it.

Shortly after that it disconnected from the printer. If I attempted to reconnect it would, and then diconnect immediately. I was unable to get it to connect again until I had disconnected the heated bed, then rebooted both the pi and the micro.

Let me know if there are any logs I can get for you or anything like that.

Tried again, and issued an m140 command in the terminal. Results below: Send: M140 s60 Recv: ok Recv: wait .. Send: M105 Recv: ok Unexpected error while reading serial port, please consult octoprint.log for details: TypeError: 'cannot concatenate 'str' and 'int' objects' @ comm.py:_readline:1373 Changing monitoring state from 'Operational' to 'Error: TypeError: 'cannot concatenate 'str' and 'int' objects' @ comm.py:_readline:1373' Connection closed, closing down monitor

[BlackholeBun]

After that I disconnected the heated bed and tried to connect to the micro got errors. I pulled power from the micro, unpluged usb, repowered the micro, plugged back in. Hit connect again. Below is the terminal output from that: Send: M140 s60 Recv: ok Recv: wait .. Send: M105 Recv: ok Unexpected error while reading serial port, please consult octoprint.log for details: TypeError: 'cannot concatenate 'str' and 'int' objects' @ comm.py:_readline:1373 Changing monitoring state from 'Operational' to 'Error: TypeError: 'cannot concatenate 'str' and 'int' objects' @ comm.py:_readline:1373' Connection closed, closing down monitor Changing monitoring state from 'Offline' to 'Detecting serial port' Connecting to: /dev/ttyACM0 Changing monitoring state from 'Detecting serial port' to 'Opening serial port' Connected to: Serial(port='/dev/ttyACM0', baudrate=115200, bytesize=8, parity='N', stopbits=1, timeout=None, xonxoff=False, rtscts=False, dsrdtr=False), starting monitor Starting baud rate detection Changing monitoring state from 'Opening serial port' to 'Detecting baudrate' Trying baudrate: 250000 Changing monitoring state from 'Detecting baudrate' to 'Closed' Connection closed, closing down monitor Connecting to: /dev/ttyACM1 Changing monitoring state from 'Offline' to 'Opening serial port' Connected to: Serial(port='/dev/ttyACM1', baudrate=115200, bytesize=8, parity='N', stopbits=1, timeout=None, xonxoff=False, rtscts=False, dsrdtr=False), starting monitor Changing monitoring state from 'Opening serial port' to 'Connecting' Send: M110 Unexpected error while reading serial port, please consult octoprint.log for details: SerialException: 'device reports readiness to read but returned no data (device disconnected or multiple access on port?)' @ comm.py:_readline:1373 Unexpected error while reading serial port, please consult octoprint.log for details: SerialException: 'device reports readiness to read but returned no data (device disconnected or multiple access on port?)' @ comm.py:_readline:1373 Changing monitoring state from 'Connecting' to 'Error: SerialException: 'device reports readiness to read but returned no data (device disconnected or multiple access on port?)' @ comm.py:_readline:1373' Connection closed, closing down monitor Connecting to: /dev/ttyACM0 Changing monitoring state from 'Offline' to 'Opening serial port' Connected to: Serial(port='/dev/ttyACM0', baudrate=115200, bytesize=8, parity='N', stopbits=1, timeout=None, xonxoff=False, rtscts=False, dsrdtr=False), starting monitor Changing monitoring state from 'Opening serial port' to 'Connecting' Send: M110 Recv: e1 Recv: ok REPETIER_PROTOCOL:2 FIRMWARE_NAME:Micro3D FIRMWARE_VERSION:2016012501 MACHINE_TYPE:The_Micro X-SERIAL_NUMBER:GR15061901050047 Changing monitoring state from 'Connecting' to 'Operational' Send: M105 Recv: ok Unexpected error while reading serial port, please consult octoprint.log for details: TypeError: 'cannot concatenate 'str' and 'int' objects' @ comm.py:_readline:1373 Send: M21 Changing monitoring state from 'Operational' to 'Error: TypeError: 'cannot concatenate 'str' and 'int' objects' @ comm.py:_readline:1373' Closing down send loop Connection closed, closing down monitor Changing monitoring state from 'Offline' to 'Detecting serial port' Connecting to: /dev/ttyACM0 Changing monitoring state from 'Detecting serial port' to 'Opening serial port' Connected to: Serial(port='/dev/ttyACM0', baudrate=115200, bytesize=8, parity='N', stopbits=1, timeout=None, xonxoff=False, rtscts=False, dsrdtr=False), starting monitor Starting baud rate detection Changing monitoring state from 'Opening serial port' to 'Detecting baudrate' Trying baudrate: 250000 Send: M110 Changing monitoring state from 'Detecting baudrate' to 'Closed' Connecting to: /dev/ttyACM0 Changing monitoring state from 'Offline' to 'Opening serial port' Connected to: Serial(port='/dev/ttyACM0', baudrate=115200, bytesize=8, parity='N', stopbits=1, timeout=None, xonxoff=False, rtscts=False, dsrdtr=False), starting monitor Changing monitoring state from 'Opening serial port' to 'Connecting' Send: M110 Unexpected error while reading serial port, please consult octoprint.log for details: SerialException: 'device reports readiness to read but returned no data (device disconnected or multiple access on port?)' @ comm.py:_readline:1373 Unexpected error while reading serial port, please consult octoprint.log for details: SerialException: 'device reports readiness to read but returned no data (device disconnected or multiple access on port?)' @ comm.py:_readline:1373 Changing monitoring state from 'Connecting' to 'Error: SerialException: 'device reports readiness to read but returned no data (device disconnected or multiple access on port?)' @ comm.py:_readline:1373' Connection closed, closing down monitor Connecting to: /dev/ttyACM1 Changing monitoring state from 'Offline' to 'Opening serial port' Connected to: Serial(port='/dev/ttyACM1', baudrate=115200, bytesize=8, parity='N', stopbits=1, timeout=None, xonxoff=False, rtscts=False, dsrdtr=False), starting monitor Changing monitoring state from 'Opening serial port' to 'Connecting' Send: M110 Recv: e1 Recv: ok REPETIER_PROTOCOL:2 FIRMWARE_NAME:Micro3D FIRMWARE_VERSION:2016012501 MACHINE_TYPE:The_Micro X-SERIAL_NUMBER:GR15061901050047 Changing monitoring state from 'Connecting' to 'Operational' Recv: wait Send: M105 Recv: ok Unexpected error while reading serial port, please consult octoprint.log for details: TypeError: 'cannot concatenate 'str' and 'int' objects' @ comm.py:_readline:1373 Send: M21 Changing monitoring state from 'Operational' to 'Error: TypeError: 'cannot concatenate 'str' and 'int' objects' @ comm.py:_readline:1373' Closing down send loop Connection closed, closing down monitor Recv: ?

[donovan6000]

Ok, try out the latest devel build to see if it fixed that error.

And don't worry too much about changing how the heat bed's controller works. I don't want to slow down development by imposing any last minute changes. I think Chase original wanted to start sending out the heatbeds around December, so people are probably getting anxious.

[BlackholeBun]

No dice on the latest devel. If I try to install it I get the following. sudo pip install https://github.com/donovan6000/M3D-Fio/archive/devel.zip Downloading/unpacking https://github.com/donovan6000/M3D-Fio/archive/devel.zip Downloading devel.zip (unknown size): 4.9Mb downloaded Running setup.py egg_info for package from https://github.com/donovan6000/M3D-Fio/archive/devel.zip Traceback (most recent call last): File "", line 14, in File "/tmp/pip-hysBhk-build/setup.py", line 92, in setuptools.setup(**params()) File "/tmp/pip-hysBhk-build/setup.py", line 80, in params if platform.uname()[0].startswith("Linux") and ((platform.uname()[4].startswith("armv6l") and getCpuHardware() == "BCM2708") or (platform.uname()[4].startswith("armv7l") and getCpuHardware() == "BCM2709")) : File "/tmp/pip-hysBhk-build/setup.py", line 39, in getCpuHardware if os.path.isfile("/proc/cpuinfo") : NameError: global name 'os' is not defined Complete output from command python setup.py egg_info: Traceback (most recent call last):

File "", line 14, in

File "/tmp/pip-hysBhk-build/setup.py", line 92, in

setuptools.setup(**params())

File "/tmp/pip-hysBhk-build/setup.py", line 80, in params

if platform.uname()[0].startswith("Linux") and ((platform.uname()[4].startswith("armv6l") and getCpuHardware() == "BCM2708") or (platform.uname()[4].startswith("armv7l") and getCpuHardware() == "BCM2709")) :

File "/tmp/pip-hysBhk-build/setup.py", line 39, in getCpuHardware

if os.path.isfile("/proc/cpuinfo") :

NameError: global name 'os' is not defined

---

Command python setup.py egg_info failed with error code 1 in /tmp/pip-hysBhk-build Storing complete log in /root/.pip/pip.log

I can add the "ok" response and/or auto temp outpu in a few minutes. At this point the code is ready enough for Chase to start shipping boards. I know he's got a little more work to do, but I can't speak to his schedule. Just that the firmware is just about ready to go.

[donovan6000]

Try installing the devel branch again. Everything should be working, except the w command might have issues since I'm not sure if OctoPrint will try to send more commands while waiting for it to heat up.

[BlackholeBun]

I was able to get that installed. I have come to the conclusion that the raspi v1 I have is not adequate for this. A lot of the time when I load the page especially in the main branch it will sit there loading for a bit, and it will never say port 5000 in that drop down. Then I get a message about being disconnected and having to reload. The devel version seems better about that. So question, is that the issue? It's just timing out cause my pi is slow? I plan on replacing it with a pi v2 but I'm out of town for a while so it will probably be a bit before I can swap it out.

On another note I feel like an idiot. I never mentioned that the baud rate is 115200. From what I can see it should work with the baud rate changed. I did some bus sniffing and spotted incoming commands at 9600 baud.

For the w command, do you want me to send an ok when it's done heating? Ideally we shouldn't be sending code to the printer if we are waiting for the bed to heat up from an M190 command.

Let me know about that or adding confirmation of received commands. Like I said, we are talking about 2 minutes to implement and if it makes your life easier I'm more than happy to do it.

In any event with matching baud rates I'm thinking it should work at this point from what I saw on the oscope.

[donovan6000]

I don't own a Raspberry Pi, so I'm not sure if the problems related to that. You could always install it on something other than a Raspberry Pi to see if that's the issue. There's installers for Windows, OS X, and Linux that install OctoPrint, the master branch of M3D Fio, all their dependencies, and any device drivers for the printer. They all add OctoPrint as a startup program and create a shortcut on the desktop for accessing OctoPrint's web interface.

M3D Fio already connects to the heatbed at 115200 baud, so I'm not sure why it's using 9600 baud. Might be an issue with pySerial for the Rapsberry Pi. I don't think this should matter too much though. The microcontroller used in the printer is supposed to use 115200 baud, but it's worked with a much larger range of speeds.

It wont really make a difference if the heatbed sends an ok when it's done. The code is already in place in M3D Fio to not expect confirmations or auto temperature outputs, so it'd just be more work for me now if it was changed.

Can you send me the Arduino sketch? It'll probably speed up integrating it into M3D Fio if I'm also running it.

[BlackholeBun]

Fair enough. My access to hardware is a little limited for the next month so I'll have to figure something out.

Yea it's odd. I can see that it is reading out some of what the arduino sends it when it checks temps. But it is not going into interface mode. I presume this is because the command is coming through at 9600 baud for whatever reason.

In any case I've been meaning to upload the sketch anyways so I've just done that. It still needs some work, but I've uploaded it to: https://github.com/Loswave/M3D-HBP-Controller

It's still a WIP, but approaching complete.

[BlackholeBun]

I just rebooted the pi with everything plugged in and it appears to be communicating back and forth ok.

The only issue I'm seeing now is that the arduino is not getting put into interface mode. So the "i" command didn't take. I have a thought on this that could make it easier. The messages I send to the console in the default mode before any actual information have a header of ESC"" ESC"" Those are breakout commands to clear the console window. The ASCII for the ESC is 0x1B. I'm thinking that rather than waiting a specified amount of time and then sending the i command upon connection of the heated bed you could look for that escape character and if you see it respond by sending "i\r". This would insure that it makes it into interface mode appropriately. It also covers the scenario that the arduino gets reset for whatever reason.

From what I can see if that's doable we should be golden.

[BlackholeBun]

Last update for now. It looks like if the controller is plugged in at boot the baud issue is not there. But for some reason if you plug it in when it's already running, or unplug and plug back in the baud rate ends up being wrong. If it's plugged in at boot it never seems to get the "i\r" command. I'm thinking though that sending the "i\r" command in response to the ESC char as above will fix the latter of the two. I'm at a loss for why it would connect at the wrong baud rate. You're code is explicit that it should connect at the proper baud. Very strange.

[BlackholeBun]

Ok, last update x2. I changed a few bits of code and have it working. I made it process the "i" command when it gets a "t" as well so that if it is queried for temp it will switch to interface mode if it wasn't already there. That ensures that it is in interface mode when it should be. I would still recommend changing it so instead of waiting 4 seconds and then sending "i" you just send it when you get the ESC char. That method will be quite a bit more fault tolerant. When you send the i command I would also flush that serial buffer because you will have extraneous data there you don't want.

Made a couple other minor changes so it integrates better. I am now however able to control the hbp and view it's temp via octoprint. So, we are almost there.

[donovan6000]

At least were making progress! Give the newest devel branch a try again. It now initializes the serial port without waiting. It then attempts to read characters from the port until 0x1B is received, at which point it flushes all the buffers and sends the i\r response.

[BlackholeBun]

Will do. I have however run into a snag. I don't have access to my micro again till March. I have the pi and my heated bed controller with me still. Tomorrow I should get the chance to update the pi and I'll have a look and see how the comms go between it and the hb controller. I did a lot more testing Sunday and by forcing the hbp into interface mode with a little code tweak everything was running smoothly. So given it initializes right we should be good to go. I can check that just fine sans micro.

If there is a way that I can continue to send commands to the heated bed controller without the micro present I can test that stuff too, Having said that with the tweaks I made Sunday I was able to see that the m140 commands and m105 commands were working fine.

The only odd thing I saw was that it would change the set point in the temperature tab to the current temperature every so often. It's purely cosmetic because it didn't actually send a m140 to go with it. So for instance as it was heating up instead of just saying it was set to 70 it kept updating the set point along with the actual temp figure. Not every update but it happened quite often.

In any event short of that the main thing was the initialization, which I will test and report back tomorrow.

[BlackholeBun]

I made a couple changes to the heated bed controller firmware. It now will blink the LED when the controller is running, and go solid when it's in interface mode. With that I was able to verify that it is being put into interface mode properly now, so it looks like that's working.

It still acts weird if I replug it while the pi is running, but that might be something odd with the pi, so I'm not going to worry about that. I'll set something else up when I get the micro back and then I'll finish testing. It looks like I'll have that back in the beginning of March.

I can still test without it, but am limited in what I can do without a printer connected to octoprint. I know there is a virtual printer, but I haven't had the chance to look into it yet. I'm also not sure it's an ok stand in in this case.

[donovan6000]

Got a hold of an Arduino today and flashed the heatbed firmware on it. Manages to fix all the issues, and everything should be working now after the pull request.

[BlackholeBun]

Pull request merged. Excellent! If I get a chance I was thinking about making a simulator version of the firmware to allow for testing without heated bed attached to the arduino.

At this point things sound good. I won't be able to do a final test as it were until I get my micro back in a few weeks, but I think the sim firmware could probably verify everything for us anyways.

[donovan6000]

A simulator version would really help a lot with verifying everything. I didn't have anything connected to the pin that's supposed to be connected to the heatbed thermistor, so it was just outputting an arbitrary value that I was using to test everything.

M3D Fio adds additional controls and adjusts its boundary checking algorithm to account for the height of the heatbed whenever the heatbed is connected, and all the installers now install the drivers for the CH340g. So everything about the heatbed integration is done :)

[BlackholeBun]

That's fantastic! It looks great.

I made a sim version. It's located in the sim branch here. The temps go up and down a little quicker than reality, but for sim purposes it does pretty well. It should get the job done.

Is there a way to define how tall the bed is? I know Chase said that it might very depending on the installation.

Anyways it really does look great and I'm looking for ward to getting my micro back and giving this a go!

[donovan6000]

Just ran a some tests with the sim branch and everything runs great! I checked out the heatbed kickstarter, and it looks like Chase has a couple more weeks before all the enclosures are made and assembled. I'll probably merge M3D Fio's devel branch into the master branch and do a new release within that time, so everything should be good to go by the time people start getting their heatbeds :)

And changing the heatbed's height is a good idea, so it's configurable now.

[BlackholeBun]

Awesome! Looks good to me!

[ra100]

Sorry, for commenting here, I've got question on @Loswave , do you have some guide, or can you tell where to look, if I want to add heatbed to my M3D? I've bought 12x12 heatbed, but I'll need help with connecting it to Raspberry pi and using with Octoprint+M3D. Thanks

[BlackholeBun]

The firmware in question was written for the heated bed from here http://wichertdesign.com/product/heated-bed-with-power-supply/. I'm not sure if he's shipping yet. His kit comes with the bed, the controller, and the power supply ready to go.

Having said that you are welcome to use/modify the firmware we are using as this octoprint add-on is already set up to communicate with it. You can get to the source here https://github.com/Loswave/M3D-HBP-Controller.

As for getting the heated bed connected up, driving it, and the thermistor and all that there are a lot of variables there. I would advise you to try and get more information about the bed itself.And see how other people who have it are using it. Seeing as how what I have is quite different there isn't a whole lot I can tell you beyond the above.

If you can figure out how you want to drive it and what the thermistor profile is It would not be too complex to modify my firmware linked above to work with it.

On Tue, Apr 19, 2016 at 8:43 AM, Rastislav Švarba notifications@github.com wrote:

Sorry, for commenting here, I've got question on @Loswave https://github.com/Loswave , do you have some guide, or can you tell where to look, if I want to add heatbed to my M3D? I've bought 12x12 heatbed, but I'll need help with connecting it to Raspberry pi and using with Octoprint+M3D. Thanks

— You are receiving this because you were mentioned. Reply to this email directly or view it on GitHub https://github.com/donovan6000/M3D-Fio/issues/56#issuecomment-211905308

[donovan6000]

@ra100 M3D Fio spawns a thread that monitors heatbed, and it's designed to work with the CH340g usb to serial chip that Arduino in Chase's heatbed uses (VID:PID=1A86:7523) . That chip sets up the heatbed to act as a USB CDC device, so pySerial is used to communicate with it.

If you want to have the Pi directly control the heatbed without any additional circuitry then you'll need to change this line that sends the equivalent of an M140 command to the heatbed, this line that sends the equivalent of an M190 command to the heatbed, and this line that sends the equivalent of an M105 command to the heatbed.

[ra100]

Thank for suggestions, I've bought this heatbed http://www.ebay.com/itm/141772405391 and for now found no more information about that, so it seems I'll have to experiment a bit (lot). My plan is to use Arduino Nano as controller so I could use M3D-HBP-Controller with as little modifications as possible.

[Dekkee]

Hello. Sorry for commenting here. @donovan6000 link in your post (https://github.com/donovan6000/M3D-Fio/blob/devel/octoprint_m3dfio/__init__.py#L628-L745) is broken, if its actual, can you send new one? Or maybe another thread about m3d heated bed. Also. @Loswave or @donovan6000 Can you explain what kind of output on arduino you have? Currently I modify your M3D Fio plugin and M3D-HTB-Controller for use with Arduino UNO and relay-output. It is working fine, thank you so much. Here is my printing graph: But as I can see, you use Servo as output device and it seems like my table temperature graph will be more linear.

Thank you.

[BlackholeBun]

I used servo output because the heated build platform my firmware was built to run used a hobby ESC to control current into the bed. ESCs take standard servo pulse.

The advantage is you have a variable output for a more stable temperature. In my own testing I was able to maintain a perfectly stable bed temp this way. Also, an ESC for this purpose is quite inexpensive. We used a turnigy 20a brushed controller. Make sure it's brushed, brushless will not work.

This is the specific one I have.

[Dekkee]

Thank you! I will try this one.

[donovan6000]

@Dekkee Here's the lines of the monitoring heatbed function.

[Dekkee]

Thanks!

[IonicEV]

The firmware in question was written for the heated bed from here

http://wichertdesign.com/product/heated-bed-with-power-supply/. I'm not sure if he's shipping yet. His kit comes with the bed, the controller, and the power supply ready to go.

Is there any way to order this heated bed? It looks like "http://wichertdesign.com/product/heated-bed-with-power-supply/" was repossessed by pirates. The pre-order link on the project page (https://www.kickstarter.com/projects/1668748285/the-micro-m3d-compatible-heated-print-bed) is hijacked as well. Any ideas where is it? Also, anyone has printer profile for M3D with iMe firmware for the Simplify3D? Or what official S3D printer profile should be used as base to adopt it for M3D micro with iMe firmware?