Looking forward to the update 
OctoPrint with OEM Hardware Tutorial (FlashNGo)
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.
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?
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.
@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.
@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:
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 
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
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.
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.
i don’t have much experience with firmware coding but i am a software dev, if you can put together a bit of a resource list or something to help me get started i’d love to start looking
otherwise i can just go dive in on my own haha just got my zims yesterday and printed a benchy, needs a lot more tuning though - http://imgur.com/a/a1kAS
First off, thanks for all of the great support. I’ve been having a lot of fun with this printer. I just bought 5 of them, brand new, just cause I think they are awesome.
I have been using both the USB and the internal board version of OctoPrint and I can confirm that the “hang” problem does not occur on the internal board.
One question: my internal version (the 1.8.4.4 release) is now telling me that it would like to update OctoPrint, but it fails. I think it’s somehow related to Python getting a secure connection?
any ideas?
@WenboDou & @Scherle hehehe, so you are the reason why the supplier is out of stock and some reddit users didn’t get one 
These are my first printers, I bought 2 of them but I am still trying to get a quality print.
@scherle. It is failing because the Cubieboard is set to RO filesystem by default
if you want to update octoprint, you should be able to just ssh to the box (use terminal in osx or putty in windows)
and with the root user, just type “rw” and it’ll set the drives to be read/write until reboot
then you should be able to run the octoprint update.
I havn’t tried it yet, but it should work.
@maxx - was there a reddit thread about these? They were $150 for a long while, and they only recently upped the price to $200.
yeah i first heard of them in this thread … went nuts and bought 6 
yes @waffles I was looking for a “cheap” and good quality printer in ebay like 2 months ago and then I decided to buy the Zim (the supplier had plenty of them, I think like 30 in total). I got to this forum and there wasn’t to many activity but there was the octoprint option so that was the sales point for me. Last two weeks, I was surprised with the amount of people reading and using your FlashNGo software so I look in reddit and last week several people were talking about it… and then, there were all gone so now it cost $200 usd and many people are waiting for the printer to drop the price to $150 to buy it.
@waffles I successfully printed a 3 hour Benchy with the pyserial change. I don’t think that is a good change to make, but it does seem to work (in my very minimal testing). I’m going to start working on improving the quality of the prints, so I will print a lot more and see what happens.
Is there an easy way to get the path to the arccontrol executable and upgraded.sh (I haven’t checked myself)? I would like to analyze the executable to check to see if its establishing any serial connections, which would be the source of our issue. Are there any other Zim processes besides the button one that I should look at?
i’ve avoided the button one, as i think its required, and ive turned off a buch of others.
if you want to see where the paths are, check /etc/init.d/arcontrold, and you’ll see it poitns to like /usr/bin/arccontrol or /usr/sbin/arccontrol
you can probably also just do “ps aux | grep arcon” and it might show the path of the executable there too…
Yea, the pyserial change kinda sucks, but from my looking upgrading the linux core fixes it, so that is an option.
for now, i’m a little burnt out on this, so i’ll take ‘working with hack’ over ‘still banging on this thing when i should be printing stuff’
Yep, I came to the same conclusion (as I stated several comments ago), but I couldn’t find an A10 kernel that had been updated past the version that supposedly fixed the bug. The kernel will not fix the issue, however, if some other process is trying to open a serial connection to the Zimboard, which I think is rather likely.
@waffles Do you have any ideas on what arcontrold does? I was looking through the hex and found the following:
.rodata: 00009040 74 00 00 00 2f 64 65 76 2f 74 74 79 41 43 4d 30 t . . . / d e v / t t y A C M 0
.rodata: 00009050 00 00 00 00 2f 64 65 76 2f 74 74 79 53 31 00 00 . . . . / d e v / t t y S 1 . .
.rodata: 00009060 63 6f 75 6c 64 6e 27 74 20 6f 70 65 6e 20 70 6f c o u l d n ’ t o p e n p o
.rodata: 00009070 72 74 r t
If you pay close attention to the far right, it contains an error message for /dev/ttyS1. This suggests that arcontrold accesses the serial port, which means letting it run while printing is likely causing our serial issues.