OctoPrint with OEM Hardware Tutorial (FlashNGo)

#63

Great tutorial @waffles!

Here are my notes on following your steps:

Step 2, It might be helpful to include this picture:

IMG_4167.JPG1008×756 161 KB

Step 3, might also be nice for new users to see this:

IMG_4168.JPG1008×756 197 KB

I’m just setting up my second printer here and encountering the Wi-Fi setup issues as well. I seem to recall this was a bug with the original Wi-Fi setup on the Zim. I followed your instructions up to #10, then connected ethernet and went to zim.local. It showed me the list of Wi-Fi networks instead of your new menu (you might want to note that in the instructions if that’s normal). But then I read in your instructions that if I wanted to setup Wi-Fi that I should disconnect my cable and connect to the Soft AP presented by the Zim and go to 10.0.0.1. Well I did that but got the same Wi-Fi SSID list. I decided to try to connect to my network at that point, and it failed registration and subsequently was not allowing me back onto zim.local via ethernet and was not presenting the soft AP anymore. I power cycled the Zim and it took awhile before it would respond to ethernet again. It was running the soft AP again as well.

So long story short, I remembered that the Wi-Fi setup was extremely buggy via the soft AP connection, and that Zeepro recommended using the ethernet cable connection to setup Wi-Fi. So this time I went to zim.local and setup my network, and it completed fairly quickly.

At that point I got the new menu with OctoPrint and Setup WiFi in the list.

I clicked on OctoPrint and logged in as zim:zim successfully. Clicked Connect and was able to see video and control the gantry.

Despite doing all of the above, I found my Zim was not actually on my Wi-Fi network. So I had to connect via ethernet cable again and click Set WiFi and enter the same settings again (still saved in the form). Checking again, I can see the Zim on the network. At this point I powered it down and back up with the ethernet cable removed and was able to connect to zim.local:5000 and do all of the things again.

After taping off the glass, and leveling the bed… I grabbed an old cutoff piece of white PLA and started a print.

IMG_4169.JPG1008×756 249 KB

IMG_4170.JPG1008×756 271 KB

This is just temporary before I print up a second spool holder for the back of the zim.

I also removed this plastic piece as it restricts the cable:

IMG_4171.JPG1008×756 157 KB

Unfortunately I forgot that I haven’t modified the fan ducts yet, and when the fan kicked on at layer 3 it completely cooled off the nozzle and subsequently jammed the extrusion process. My son noticed it was ghost printing. You can see the temperature dropping here.

Screen Shot 2016-11-27 at 9.51.27 PM.png1284×842 137 KB

Since I really needed to get my kids to bed (they stayed up to watch the first print) I just reprinted the part again, and turned off the fan manually after it kicked on during the start of layer 3.

First print:

IMG_4174.JPG1008×756 195 KB

It’s a little melty… because the fan was off. That will improve greatly when the fan can run full speed and not cool down the nozzles. This basically involves taping over the left and right vents with kapton tape, and leave the front vent open. The left and right vents don’t stick down far enough through the shroud, and just end up blowing on the side of the heater blocks.

I’m also noticing from time to time that the Octoprint interface seems to have frozen. I think this may be due to something going on with the Wi-Fi interface on the Cubieboard. If you notice this, a refresh of the browser tab seems to fix it.

2 Likes
#65

I thought I was the only one running into the print pausing issue, I think I might get rid of the zimboard completely and install a ramps board and arduino 2560 and print via USB to see if that fixes the problem

1 Like
#66

@BDub - Thanks! I updated the instructions with your pics. They’re helpful.

Still trying to track down that pausing on M105 commands. It’s annoying. I’m not sure if its the firmware (don’t recall seeing anyone using rasp pi runing into it though), or the cubie board (seems powerful enough, and its always M105), the zim existing processes (pretty sure i’ve checked them all), or maybe my build of octoprint (maybe? I can try using the other one and see if it still occurs)

Anyway, I have some other changes to make things even easier for new folks in testing right now. Maybe in next few days there’ll be a new and improved release, but i really need to track down that M105 hang.

#67

I too am experiencing both the freezing and timeouts (“device reports readiness to read…”). I wonder if the issues are arising from the image being rather finicky. Once I installed OctoPrint, I immediately went to change the root user’s password, which threw errors, and once those errors were fixed and the password changed, I would no longer be able to log into OctoPrint with zim:zim. On top of that, when I reset the OctoPrint config to allow for a creation of a new user (to fix the zim:zim problem), everything works fine until I try to connect to OctoPrint after previously disconnecting. This again resulted in an inability to log in.

@waffles If there’s any way I can help out, let me know. I would like to see this printer revived, and OctoPrint is a huge step in that direction.

#68

Please note:
if you want to change files/config on the cubie you need to make the filesystem RW (theres an alias setup, just type ‘rw’ for readwrite and ‘ro’ when you’re done) this would need to be done for changing root pw for instance.

Changing the root password should have no effect on the zim user, they’re different.

Also, please note that octoprint takes awhile to load up, and you can get cached pages. this is just octoprint behavior. I’ve found the user login doesnt work until octoprint is fully loaded, so if it fails, just wait 60s.

But, maybe i’m missing some stuff still. I’m still mostly concerned about the hanging on M105 commands, as that affects the print. Setup issues suck, but once it’s setup, it doesn’t revert…

As for helping, I’d love some help. I have looked through octoprint logs for any sign of things when it pauses, and i’m just not sure where to look next for issues. I’m almost at the point of installing a rasppi just to see if the firmware has the same hangups, to at least narrow down the behavior. Any guesses would be appreciated at least for a fresh perspective.

#69

That’s indeed what I did, making sure to change it back to read only once the password was changed. That still seemed to break OctoPrint for some reason (not the zim system user, but the zim OctoPrint login).

I’ll look into this over the next few days and let you know if I come up with anything.

1 Like
#70

Just as an update with the printing freezing occasionally on M105 commands…

To narrow it down, I installed a rasp pi, and the problem does not occur there. So, I think I can rule out my octoprint config (its the same), and the firmware (also the same)

I’ve tried 2 separate builds of octoprint, so i can rule out my build process.

So, I think I’m down to maybe something on the stock wheezy distro mucking with it, some out of date lib, or just outright problem with the hardware on the cubie. None of these seem too plausible, as i dont think the original stock zim stuff suffered this stuttering.

I may just see if i can get armbian or some distro running easily, and try that next.

2 Likes
#71

I’ve come to basically the same conclusion. The “device reports readiness to read” error (which I assume is related to the M105 issue) started appearing with a particular kernel version in Ubuntu (3.13.0-65-generic to be specific) when connecting to a serial device. Although this is not the same kernel running on the Cubieboard, it seems rather likely that the issue lies either in the kernel or the version of pySerial. I assume the version of pySerial is the same one included in OctoPi, so the kernel would be my next target.

#72

I searched and found nothing, but is the cubieboard in the zim compatible with smoothieware?

#73

Ok, good news bad news.

good news: I found out what causes the cubie board to fail and cause pausing in the prints!
The M105 updates by jpod, I’m guessing are too long of messages for the cubie/linux versions serial to handle gracefully at times.

So if you go back to old Marlin 1.1.0.15, you should no longer have troubles

The bad news is … you lose out on temps for both extruders. I don’t do much dual extruder printing, but I’m pretty sure this just means the temp graph doesn’t work nice n pretty for both, which is annoying.

Yes, this does not occur for the rasp pi, as apparently the USB/serial board handles longer messages just fine. I don’t know exact root cause, but I
first went back to original firmware, printed, noted no issues
Added back in just the temp fix, and saw that it hangs again.

I was hoping it was some of the buffering changes, or something.
This might still be remedied by a new linux version, or by some other change, but anyway

For the time being, I’ll package up a 1.8.4.4 release so as to not leave folks hanging, I think you’d prefer working printing, but broken temp graph over vice versa.

I’d have to see how octoprint parses the temp message. maybe we can find a middle ground that shaves off some characters enough to fit whatever magical limit applies. Not sure what best course of action is after getting folks unstuck. Also made some changes to network config to hopefully smooth that out.

I want to get back to hardware mods anyway, and tuning it for nicer prints.

1 Like
#74

Looking forward to the update :smiley:

#75

1.8.4.4 released
See first post for notes and instructions and whatnot. As always, let me know if you have any issues. Sorry I couldn’t figure out how to get temp working and it not freezing.

If you’re using an earlier version, this is one you probably want to update to.

To verify it went right, after updating, go to ‘about my zim’ and you should see firmware say 1.1.0.21, if it still says 20, try rebooting again, else i probably messed something up.

#76

Thats strange, because when I used Octoprint on my Raspi with Firmware 1.1.0.19 to have both temperatures correctly displayed, there where no issues at all with pauses or anything.
Are you sure about having found the correct cause?

#77

Like i said, the pi/usb connector handles it fine. Theres just something on cubie, its linux libs or its serial connection that doesnt like that temp code. I did 2-3 hours of printing without hiccup, which isnt most scientific test in the world.

Its possible i just got lucky, so looking for others confirmation the pausing goes away.

#78

@waffles I was reading about pausing with Marlin software (on other sites for different printers), and most people seemed to say it was due to noise on the serial communications. It’s possible that we will still see that without the M105 commands, but maybe we see it more frequently with the M105 commands because there are so many of them? The serial cable that runs between the Cubieboard and the Zimboard is not shielded at all, and may run parallel to some stepper cables which would be bad. That is another difference between the two setups, with the RasPi, the USB cable typically exits the back of the machine via the Ethernet cutout and is also shielded. Might be worth experimenting with that and the M105 commands added back if you can reproduce the issue reliably.

#79

@waffles here’s where we started talking about the temperature issues with Octoprint, it might be helpful to understand how to modify things going forward:

#80

Thanks bdub. Theres actually only a very small num of m105s compared to the 100k+ g1 move commands, so i feel pretty confident theres some suckage with that call specifically. Others may also hang, but ive never seen it. Could just be my 2 boards tho? Would be astonomical coincidence.

If its just a length problem, theres lots of superfluous info that could be removed. Id just need to see the regex oprint uses and find a smaller compatible pattern (and prob round numbers) itd make our printer out of spec, but, what can ya do, right.
I do want confirmation from other folks this fixes up issues for all before spending more time though. Lets make sure we got the problem identified and im not making a mistake :slight_smile:

#81

i asked this question on reddit, it sounds like the cubieboard only controls the internet stuff and not the printer, so the answer is no

i’m getting my shipment of these printers today so this is only secondhand knowledge, hopefully i can get mine up and running soon to contribute

#83

It does indeed look like the M105 fix is working. I printed a Benchy for around 2 hours before it was halted with the “device reports readiness to read” error. I think I’m going to try commenting that line out in pySerial and see what happens.

#84

Yea. I get that now too. I think the M105 is good, but now its just exposing the next issue. It’s like playing wackamole.

When doing testing i often turn off upgraded.sh and arccontrol. Its possible now that the M105 issues is gone, these are rearing their ugly heads at the wrong time.

@agg23 - please try the pyserial fix, but also try killing those 2 processes before starting a print if pyserial alone doesn’t cut it. Maybe arccontrol has some timery bit. I did do the pyserial fix on my local zim, and still got M105, then fixed M105… then all seemed clear. But i figured the pyserial wasn’t the fix, but it may be needed too.