Solved Out-of-box Robo C2 microSD image

Looks like people wanted an out-of-box image and fortunately I made one before firing up my printer initially. So if you want to burn another 4GB microSD (or larger card) for your Robo C2 printer, this could be an option for you.

Unfortunately, github wasn't happy with the file size 1.5GB of the zipped image file. And the forum here has a 512MB limit as well so I'll need to find somewhere to host it. (Stay tuned.)

---------------

For this, you'd need a computer with an SD slot or a USB-to-SD or USB-to-microSD kind of adapter. Since the 4GB card I just purchased came with an SD adapter and my MacBook has an SD slot on its side, this is pretty easy for me. Lots of places sell either type of adapter and they're usually less than $10 or so.

You'll need some way of burning the image to your microSD. I use ApplePi-Baker which appears to be much faster than the native `dd` command versions I've attempted.

If you're on Windows, you'll need to unzip the incoming file.

On OS X, you'd need `ssh` and on Windows, you might need to download Putty to remote into your Raspberry Pi 3 on-board computer inside the Robo C2.

One of the final steps is to rename your newly-imaged Raspberry Pi's hostname. This download image's hostname is "robo-c2" but you'd want to rename it to your own printer's serial number as seen on its rear label.

If it gives you any trouble, let me know.

P.S. I intend to upgrade my Robo C2 with a newly-purchased 8MP Pi NoIR camera so I could probably benefit from having a larger microSD card. So I'll likely be expanding my own to a 16GB card and this imaging activity is a good way of backing up what you have now, then upgrading your hardware in such a way that you can always revert back to an earlier setup.

Also, if you generally distrust the software upgrade path as delivered by either Robo or OctoPrint, using these methods is probably a good practice then, too. Backup your printer's card, duplicate it and then upgrade on the cloned card. If the upgrade breaks things then just revert back to your last save microSD card.

 

Apologies... the upload to Google Drive is taking over nine hours. <_<

 

Finally, here is the Google Drive share link [link removed - please contact help@robo3d.com if you need a replacement image] for the microSD out-of-box image for the Robo C2. The hostname has been genericized to "robo-c2". Let me know if that doesn't work for you.

I had to rename README.md to README.md.txt in order to upload it here. After downloading, rename it back to README.md and open it with your favorite reader for that. It's the instructions.

It only took 29 minutes to download here at work and nine hours to upload at home. Cox cable has some 'splaining to do.

Windows users: Once you unzip the file, note that the filename for the ISO is just a hyphen. So it may be necessary to manually rename that to "robo-c2-oob-4gb.iso".

 

Thanks for this! Mine just got scrambled on the 1.7.1 update... but the image supplied in this thread worked great. However, in the README.md file it lists the default name as robo-c2.local but it actually is roboc2-printer.local so others who use this version should take note of that difference.

 

Interesting... I tested all this in a Mac OS X network situation (via the Bonjour resource broadcasting that's built-in). Were you using a Windows-based workstation, @Eric Albert ?

 

Yes - Windows 10 on a Dell workstation... when I first tried the robo-c2.local connection it failed. So I checked my router's client list and found it and saw the different name... everything went fine after that. I'm thinking of creating an image of the current release to upload. We are quite a number of updates past this one and maybe having something more current would be helpful?

 

It's up to you, Eric. I bought several 4GB and 8GB microSD cards so that I could make images along the way. And yet, my latest now would have both the Pi NoIR camera and sound upgrades so mine's less "vanilla" now than would be appropriate for everyday use.

I asked the Windows question because the underlying OctoPrint appears to have two different mechanisms for broadcasting the hostname. Bonjour appears to use the actual /etc/hostname value and Samba in the Windows world on that doesn't appear to be broadcasting the NETBIOS name correctly by default. Glad you got in, though.

 

OK - so far I've kept mine plain vanilla... and was also scratching my head on why the broadcast name was different. I also plan on cloning the vanilla image now as the upgrade took a long time to complete. And some day (time permitting) I'll get the camera add in going!

 

Just keep in mind that if you clone/publish your image you may now want to reverse the process and 1) temporarily rename your printer to "my-c2" or similar, 2) clone, 3) rename it back.

The camera is way fun. See the other tutorial on that same github, btw.

 

I'm a new C2 owner and have been doing some tweaking of my printer. I've added the Pi Camera and it has been working with the SD it was shipped with but I would like to use a bigger card. I burned your image to a 32GB class 10 micro SD using etcher and it boots fine but after a few minutes i get an error on the printer's screen saying 'main board not detected, please reconnect'. I can press reconnect and it does, however I get the same thing a few minutes later. If i re-insert the stock SD card it boots and operates as normal. Has anyone else experienced this issue and hopefully found a fix?

 

With belated thanks to WheresWaldo and Tomlinson (in another related thread). I did as follows for a minimum of effort (not having to lift a finger wrt the raspberry pi configuration!!)

1. bought a new sd card (16GB)
2. asked Robo support to help -- within a couple of days I had a link to a custom-made image (the name corresponds with the "serial number" on the back of the printer) -- happy with customer service
3. I put SD card in Windows machine and in my Linux VM running on said machine: I unzipped RoboOS download to get the 4GB image file. Now, after triple-checking that the /dev/sdc location is indeed the SD card I did:

sudo dd status=progress bs=4M conv=fsync if=blah/roboOS_1.8.1-c2.0.SERIAL-NUMBER.img of=/dev/sdc
umount /dev/sdc
​

After I stuck the SD card into the Raspberry Pi inside the C2, it booted up very happily. The filesystem on /dev/root is recognized correctly I think, I appended the df output after my first ssh into the P. So at least for Robo OS 1.8.1 and by using dd, I think the new FAQ issue that Mark was kind to put up may be unnecessary. (I didn't use the Windows program etcher for imaging the SD card -- don't trust Windows software downloads). Also, I didn't have any issues like mheath82 reported.


df -h
Filesystem Size Used Avail Use% Mounted on
/dev/root 15G 2.1G 12G 15% /
devtmpfs 427M 0 427M 0% /dev
tmpfs 432M 0 432M 0% /dev/shm
tmpfs 432M 5.9M 426M 2% /run
tmpfs 5.0M 4.0K 5.0M 1% /run/lock
tmpfs 432M 0 432M 0% /sys/fs/cgroup
/dev/mmcblk0p1 63M 21M 43M 34% /boot

 

Interesting. I think I would go through the process of putting the image again to the microSD card with Etcher. Given that your microSD is 32GB instead of the 16GB card of this image, it may then be necessary to bring up an SSH session to your printer, use raspi-config and expand the partition to use all of the card's space.

Regardless, this doesn't sound like it would have anything to do with fixing a connection error.

Perhaps a better approach would be to follow the Pi NoIR Upgrade step-by-step instructions which show you how to clone your original microSD card then expand it as I'm hinting above.

 

Thank you for the insight. I actually ended up using robodobo's approach and contacted Robo support for an image. Oddly enough with their image the filament run out sensor no longer works so I had to disable it in octoprint. I'll have to do some further troubleshooting for that but for now I'm printing again.

 

It's entirely possible that your run-out sensor from before was commented out... followed by Robo's new image in which it wasn't. This, combined with the assertion that your run-out sensor has a blade switch and that it's unreliable.

(My own printer arrived like this; the run-out switch wasn't happy and someone had somehow cheated the filament runout plugin.)