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.
Yes. Arccontrol is how the stock system sends commands to the zim ramps board.
It really should be disabled, if it ever makes a call it interrupts the octoprint connection
Sadly, removing it breaks autofirmware updates and the “about zim:” page or i woulda nuked it days ago. I can work around but its easy for me to just kill the process on startup.
Try killing it and see if your print hangs. If we can verify we can start proceas of removing reliance on it in initial setup
Making this work for easy install is a lot harder than making it work just for my own zim, so its been a process and i appreciate the help
Hi guys, I’m currently running 1.8.4.3 and will throw in 1.8.4.4 tonight when I get home for further testing. Let me know if there’s anything you want me to keep an eye out for, and I have no problem installing test builds as well.
(my only limits are retention of temp timeout and other temp related controls, as runaway thermal issues in the teflon-based hot end would be bad new for my birds)
@driph with 1.8.4.4
can you try the following
ssh root@zim.local user=root password=Longgang2014 (use linux/osx terminal or on windows use puTTY)
/etc/init.d/arcontrol stop
/etc/init.d/upgrade stop
before starting your print? There’s no risk to thermal runaway, we’re just trying to figure out what processes are messing with octoprint’s connection.
I’m running the same, but its nice to have confirmation. What you’re looking for is longer prints eventually getting a communcation error, and the print failing. We’re trying to track that one down right now. I have a feeling its one of those 2.
What are autofirmware updates? The ability to flash the device with the method you’re using, or is it something else? It would be easy enough to set up a cron job to shut it down shortly after boot if it needs to run for a short while for some reason.
I have undone my pyserial change and will experiment with disabling arcontrold. I’ll let you know if I experience any serial connection failures.
I’m just modifying the stock image for flashing. The current flash updates both the cubieboard and the ramps board. The firmware is the ramps/marlin firmware. It contains the changes for temp and some other fixes JPod put in. It can certainly be done by hand, but that increases complexity for those who just want to flash and be done.
But, folks seem pretty happy with the octoPi solution, and that requires manually flashing the marlin firmware (and building it!), so maybe I’m not giving folks enough credit.
I’m thinking of removing upgraded/arccontrol and make flashing the firmware a function of the bootloader installer rather than something that always runs on the board, since these are packaged as ‘all or nothin’ packages. might be easier.
EDIT - killing both upgraded/arcontrol before print (without pyserial hack) seems to be working. This is very preliminiary results, as its a fairly random problem… but its a 2 hr print doing just fine. If i get a few other confirmations, I’ll pack up a 1.8.4.5, along with new build of octoprint, a new f/w version to add back in temp readings, and other minor stuffs.
@waffles, that would be great. I will wait for 1.8.4.5 build and let you know the results. Thanks so much for your hard work waffles.
Quick question for anyone that can help. The metal rods that hold the carriage are out of their holes. Do I put these back and leave them loose as they spin freely. Do i glue them there? Or is there some sort of screw on the bottom of that black piece that I have to tighten onto the rods? I attached some pics. Any help is appreciated.
Thanks
What did you do to fix the temp readings?
@ALi - yea, mine were half out, and it cause it to hit the rods before zeroing. I just pushed them back flush, and they’ve been ok. I dont know if they were originally glued, as the glue zim used was garbage (see magnets :D) but yea, just push them flush, and check em once a week or something.
@agg23 - I shortened the string. It makes it outa spec, but octoprint happily parses it. For this version, with fw-upgrade off, i’m a little concerned that the install instructions will get a bit more complex, but whatever.
It’s almost done but I need to patch up the UI, as it now throws errors since it expects arcontrol to be running. Ugh, if its not one thing its another.
@waffles: .4 installed, processes killed, so far so good.
Been printing for the last two hours, no issues.
After ~2 hour point and a completed print, it looks like the server went offline while idlng, and is no longer reachable.
1.8.5 released!
@driph - thanks for giving it a shot, and confirming my suspicions.
Glad it worked! Hmm, not sure what’s going on with the idling server offline? I’ve not seen that before. If you havn’t rebooted, try again in a min or two? No clue on that one though. I’m going to print a large print tonight, just to verify everything with 1.8.5, but wanted to get it out for folks to test out.
Just started a 100g print, should take 8 hours or so. Going to bed, will update in the morning. Glad I made this thing almost silent! This’ll be a nice test of my lower cooling abilities as well.
EDIT - 9 hours, completed.
