A buddy of mine mentioned to me the other day that to update the config on his Smoothieboard, he has to take out the SD card, walk it over to his PC, make the updates, and walk it back. Personally, I just ssh into the Pi running OctoPrint and sudo mount /dev/sda1 /mnt && sudo vi /mnt/config && sudo umount /mnt, but I understand that a lot of folks aren't nearly as much of a CLI junky as I am, so I got to thinking about leveraging OctoPrint to make it easier.
Initially, I thought maybe one of the file manager plugins could mount the Smoothie's SD card, expose the filesystem to allow editing the config file, and unmount again on demand. Unfortunately I didn't find much. After that, I poked around GitHub a bit and came across a couple interesting projects:
I also came across @foosel's comments around accessing the Smoothie's storage here:
Having read about all the peril around accessing the SD card as a USB block device, I thought it might be fun to play with Smoothie's console config commands. As of now, I have a very basic loading (via cat /sd/config) and updating (via config-set) working.
There's currently no way to comment out / remove an existing setting or to uncomment / add a new setting. Adding new settings with config-set should be easy enough, but to my knowledge there's no way to tell config-set where in the file a new setting should go or that your new setting replaces an old commented out one, so things will get messy quickly if we go down that path.
At any rate, I just wanted to share some progress and see what people think. Is this a path worth going further down?
(Ignore the Block Device setting -- it's currently unused. It'll come in handy if I do wind up going down one of the block device access paths.)
config-get is problematic as can easily crash smoothie (ram over-usage), config-set can be problematic if you have "clean" config without trailing spaces it can fail / write incomplete data into file as it can only write over existing bytes in file, cannot insert new bytes before new line.
I personally do keep a copy of the config locally on opi that I edit and then a mount/copy/sync/umount copy the config to the printer.. same with updating firmware..
I'd personally prefer a large text box of my config rather than individual text boxes.
As for config/firmware:
I keep a local git repo of my smoothie config, firmware, and gcode scripts and then do the same as @arhi, mount/scp the files over whenever doing changes.
You could use smoothies cat to read files and M28/M29 to write files but the problem you will run into is writing the firmware as M28/M29 does not support binary. Based on that I would think mounting the SD is the best option but you would be limited to *nix only as I don't think there is a way to handle it on Windows.
You could make determining the partition easy by going through a detection wizard.
Ask user to physically disconnect the usb cable to the smootheware controller.
Note partitions in /dev/disk/by-uuid
Ask user to connect the usb cable
Note partitions in /dev/disk/by-uuid and pinpoint the correct one.
Mounting would require modifications to /etc/sudoers but shouldn't be too bad if you provide a helper script that would need to be run manually.
I definitely agree that config-get and config-set have their issues. One thing I'm trying to feel out as I'm working through this is if my energies would be better spent working around Smoothie's limitations on the OctoPrint side or beefing up Smoothie's functionality on that side.
Optimally, I'd like to come down to a pair of user experiences that folks can choose between with a toggle. One would be one giant text box as you mention, so users can just edit the config file directly. The other would be the logical extension of what I have today -- a control panel with folding sections, toggle / spinner / selector widgets for the various items, etc.
I went with individual text boxes for the MVP here because it makes it easy to use Knockout subscriptions to update the proper configuration item without having to do any sort of manual change detection. Now, if we can come up with a reliable way to write out the entire file, that becomes a non-issue.
M28/M29 could be interesting. I'll poke around with Smoothie's upload handling and see if I can figure anything out. For future reference:
My end goal of all of this (because I'm a glutton for punishment as much as anything else) is for the user to be able to install the plugin and it Just Works from there. It's probably my OCD talking, but anything shy of that feels to me like we may as well stick with SSH->Mount->Fiddle->Unmount.
m28/29 are soooooo slow for some reason with smoothieware, not sure what's the deal there. Now, don't forget that with network enabled you can sFTP files there.
in any way nothing is faster then mount/cp/sync/umount .. and then you can shoot a "reset" trough serial and wait for it to reboot
the only problem I see is permission to mount/umount everything else could be automated
fiddling with smoothieware itself is rather easy (code is beautiful and easy to navigate) but it's hitting the limits of that rather limited arm they are using (and v2 board is .... )
Sorry for the necroposting, but I'm just getting started with Smoothie and Octoprint, and I was wondering what you were using to configure the board nowadays? Have you found better solutions? Are there plugins in Octoprint to download/upload files from the printer SD card, or shall I do everything through SSH?
I set a few people up with this plugin and it "mostly works", but it doesn't work well enough to replace knowing how to talk to the Smoothieboard via its native channels. If you're new, I recommend getting comfortable with Smoothie's native interactions then down the road if you find yourself making repeated small configuration changes, a convenience plugin like this one could save you some time.
)