ok so i open the settings do nothing other than click save, and then the 3 profiles appear when i reopen settings…but the curaengine still seems to be missing? I mean it fails the test anyway
So i had octoprint ‘connecting’ last night but this morning it wouldn’t ‘connect’…only said ‘auto’ and something about a serial connection…which is strange since i was connecting via ‘wifi’ and if im connecting to octoprint surely i have a ‘connection’…
anyways yet another flash…apon boot, i do the update part of the wiki, but avoided the ‘manual update’ at the bottom of the wiki this time thinking maybe that broke it last night doing it.
so after the update i get into octoprint, in settings curaengine ‘test’ still fails no big surprize, i see 3 printer profiles cool…go to redeem, its empty, no profiles. i restart redeem, save, reopen, cure is empty this time, and redeem has profiles…seriously this is some shit.
so then i connect, it works, i play with my motion control for the first time, realize i need to slave a motor to another, i edit the local.cfg via octoprint and the little ‘edit’ button, save, didn’t work. so then i save it to my hard drive, edited it, and try to ‘import’ it. i select the file, try to click the button and nothing happens…so i can’t import files…i change the name try again, still nothing.
So then i think, ok maybe i just need to reboot, so i do that, log into octoprint, click connect…now it won’t connect again, usb too…jesus fkin christ…ive had nothing but trouble with this thing all its doing is wasting my time…
Ok, that is troubling. May I suggest you try to flash the latest Kamikaze 2.1.0 RC4 image? There’s one minor annoyance with octoprint trying to update on every boot but it should be fixed quickly. You can download it from here: https://github.com/goeland86/Kamikaze2/releases/tag/2.1.0-rc4
Then there might be a bug in the octoprint_redeem plugin that won’t list files unless you upload a blank local.cfg file. Sorry I was unavailable to get more involved in your debugging process before.
Also with this RC4 you should see in Octoprint directly which version you’ve installed (It says 2.1.0 RC4 in the octoprint header). You can change it in the settings of course, but there’s an additional file you can read in /etc/kamikaze now that also contains the version and when the image was originally created. These two files will become part of the standard for future releases.
same problem still, i can connect on fresh install, but eventually it looses the ability to connect and ask’s to do the manual serial port thing. i tried usb, ethernet, and wifi…
i have 1 hunch im going to try so i am reflashing, and im not going to click the ‘restart redeem’ button in settings, ever. and see if that is what is causing my issues.
if that fails the only thing i can think of is finding a way to compare my fresh install files to the files after it stops working, but im not sure how to do that. maybe ill save the dmesg screen on first boot, then do a dmesg when its borked but not if that will catch it or not.
the sad thing that just dawned on me is i can’t even sell this replicape because its not working
ok so fresh flash, connected, played with motors a bit, i think powered down, once, maybe twice, and rechecked that everything worked and it did. I then look inside cura and redeem options and they are empty, no printer profiles. just the local.cfg and default.cfg. local being blank. default had some stuff in it.
so then i edit one line into the local.cfg, and then try to import a local.cfg, click save, power down, power up, can’t connect…
and again, when i can’t connect, my motors/fan on power supply is all making lots of noise and it never stops. When things are working, that noise gets very quiet after about 30 second from powering on, so its like something is freezing up during boot.
i copied a before and after dmesg and will upload them, they do vary slightly afound “5.4” and also towards the very end, things get out of order so it gets hard to follow/compare.
also of note it says ‘no cape found’ somewhere in there, which obviously seems like a huge red flag, except its also in the one that was working
working http://textuploader.com/d1af9
not workinghttp://textuploader.com/d1af0
Ok, so, if you look in both, you’ll see 4 lines where it’s looking for the replicape (working and not-working files): [ 3.357152] bone_capemgr bone_capemgr: slot #0: 'Replicape 3D printer cape,00 - it only shows “no cape found” for slots 1-3, but that’s normal. You only have one installed ![]()
My guess is what’s happening is that the configuration for redeem is getting messed up. Can you look at what the output of ‘systemctl status redeem -l -n 100’ looks like on the not-working image? You should be seeing more information there about what happens when redeem tries to start and fails. It may even tell you which part of the configuration file doesn’t work. Also you can look at the octoprint and redeem logs from the logs tab in the octoprint settings. The redeem log shows under the filename “plugin_redeem.log”, that may be easier if you don’t want to deal with the systemctl command, the log file will simply contain all the output from redeem, not just the last start’s.
Other detail to check - when you flash initially, do you then select a base configuration as the favorite in the redeem settings in octoprint, after you uploaded the local.cfg? (Upload a file with just an empty line through the octoprint settings if the default configurations don’t show, the available printer configurations should show up after that).
What would really help debug the setup is the output of redeem as explained above, whether you’ve selected a base printer configuration file for redeem to start working with, and the contents you add to local.cfg afterwards.
I’m really sorry you’ve had such a poor experience setting it up, because once you’ve started understanding how it works it’s just easier and a pleasure to work with it. Hopefully we’ll get you there soon!
That was it…it never occured to me that setting the local.cfg wrong would cause a ‘connection’ error. Im super surprized i didn’t find that during my researching that error.
The logs kept saying missing header, and then listed the the command i wrote. So for others running into this problem if u are changing a setting for steppers for example you need to write [Steppers] first. I was just putting the command in and assumed if i was doing it wrong it just wouldn’t update that setting.
It might be good to put that local.cfg trick in the wiki under kamikaze or at the very top of the redeem wiki. that whole dispearing thing made everything so much more confusing. Infact it might be good to put all these ‘quirks’ into the wiki so people know ahead of time that all these things might happen to them, or what to do if it happens.
I mean some of this is me being dumb, maybe most of it even, but i tried searching and i seen it mentioned 5 or so times here in the community search but no fix for it. and on google itself its listed many many times in relation to octoprint but nothing to fix it. I think i even recall ending up on octoprint’s website and there wasn’t anything listed about being dumb. So yah please think of the dumb people :), im sure there’s some kids out there too, i wish i had that excuse.
Seriously tho, octoprint needs to change that error from ‘manually add serial port’ to…FIX YOUR LOCAL.CFG lol…
So the problem is that redeem and octoprint talk through a virtual serial port. This means that if redeem fails to start that connection is broken and octoprint can’t really help diagnose it.
We’re planning on adding syntax checking to the file upload pane in the octoprint plugin, but it’s not ready yet.
Glad you going the error!
And I’ll be adding extra stuff to the wiki later today as well.
ok thanks again, now for the easy part right, tweaking all the settings? lol
Yep! We’ll be here or on slack off you need more help 