markwal / OctoPrint-GPX

An OctoPrint plug-in to use GPX as the protocol layer underneath rather than replacing g-code to talk to s3g/x3g machines, for example, a FlashForge.
GNU Affero General Public License v3.0
104 stars 26 forks source link

GPX not saving settings in config file #24

Closed agilliam80 closed 8 years ago

agilliam80 commented 8 years ago

I originally posted an issue, but I decided to just remove octoprint all together.

agilliam80 commented 8 years ago

I was going to downgrade to a previous version but I ended up trying Jessie lite again. Once installed and configured it wont let me save to a replicator 1 dual. It keeps staying at replicator 2 (default) No matter how many times I change it and save, it doesn't save. I tried editing the gpx.ini and add machine_type=replicator 1 but it doesn't seem to work either. Changing the gcode flavor is saving now from reprap to makerbot. Everytime I try to print a single extrusion file it starts heating the right extruder and not the left and the heated bed. It wont let me change to Replicator 1 dual. For some reason one of my installs is set to a replicator 2 dual with HBP and I cant change that either to a replicator 1 dual. Again these are fresh installs and happening on 2 pis now. 1 is a RPI 3 by element 14, and the other is a RPI 2 by element 14. These both were working fine with wheezy I wish now I hadn't reimaged and upgraded. I have reimaged the cards multiple times and still same outcome. Any ideas? I cant figure this one out.

agilliam80 commented 8 years ago

It seems also as if everytime I go and try to set it machine type to r1d, it just keeps adding more and more to the file. When I view it now it has the same information in the file 6x. If I do change it to a rep 1 again it has the same info again added to the gpx.ini. I'm not sure what is going on. I guess I have to deal with the old wheezy version :(

markwal commented 8 years ago

The ini file uses the same machine names as the command line so replucator 1 dual is r1d.

My guess is that by editing the gpx.ini it now has permissions that doesn't allow the octoprint user to modify so the save it's actually failing. It may show up in the logs.

My suggestion would be to delete gox.ini. Click the "disconnect" button in octoprint, then set it via the settings panel and click save (don't edit it with a text editor). Then click connect.

I'd you still have troubles, upload the gpx.ini somewhere and post a link here.

agilliam80 commented 8 years ago

I just reinstalled wheezy and it works fine now. So I have my pi 3 since wheezy won't run on it and I am going to try yet another SD card and try again. Before I edited the gpx.ini I just cat'd before to check. After many reimagine I then edited. But each time was the same. I checked md5 and all was good. I'll post back in a few. But I can tell you he ini looked like most all I Ini for gpx, except each time I changed the printer it would put the exact same info in again. Each time I did it, it essentially appended instead of replaced. Or like echo >> instead of echo > if that makes sense.

On Tuesday, August 2, 2016, Mark Walker notifications@github.com wrote:

The ini file uses the same machine names as the command line so replucator 1 dual is r1d.

My guess is that by editing the gpx.ini it now has permissions that doesn't allow the octoprint user to modify so the save it's actually failing. It may show up in the logs.

My suggestion would be to delete gox.ini. Click the "disconnect" button in octoprint, then set it via the settings panel and click save (don't edit it with a text editor). Then click connect.

I'd you still have troubles, upload the gpx.ini somewhere and post a link here.

— You are receiving this because you modified the open/close state. Reply to this email directly, view it on GitHub https://github.com/markwal/OctoPrint-GPX/issues/24#issuecomment-237141660, or mute the thread https://github.com/notifications/unsubscribe-auth/AMFHSy8dAsgLBDCqKXMgnQKNWU1up0nDks5qcCQfgaJpZM4JbIoq .

Sent from iPhone on T-Mobile LTE

agilliam80 commented 8 years ago

Ok so same thing happened again. I thought it wasn't printing correct due to a profile issue with replictorg.. I set it to the correct one, and brought in a gcode file I printed succdessfuly on wheezy to the Jessie lite, and it heated right extruder and not the left like it did in wheezy.

The location of my gpx is here on my onedrive. https://1drv.ms/u/s!An4OlBR1JmKjx3k2ZphUUfUpBwYj This is also a good example of what keeps happening. Everytime I change anything under gpx, it appends everything to gpx.ini.

This is a virgin install, nothing else added besides fptd now so I could get the gpx.ini, and I changed the locale, timezone etc. nothing in octoprint except for installing gpx, and changing to a rep 1 dual.

Without being able to change this, i am unable to access my 2nd extruder, it thinks its a replicator 2.

This is a view of permissions of gpx.inipi@OctoPi:~/.octoprint/data/GPX $ ls -al total 12 drwxr-xr-x 2 pi pi 4096 Aug 2 22:43 . drwxr-xr-x 5 pi pi 4096 Aug 2 22:47 .. -rw-r--r-- 1 pi pi 278 Aug 2 22:44 gpx.ini pi@OctoPi:~/.octoprint/data/GPX $

Im going to rm -rf gpx.ini and restart octoprint.pi@OctoPi:~/.octoprint/data/GPX $ rm -rf gpx.ini pi@OctoPi:~/.octoprint/data/GPX $ ls -al total 8 drwxr-xr-x 2 pi pi 4096 Aug 2 22:58 . drwxr-xr-x 5 pi pi 4096 Aug 2 22:47 .. I dont know why it says total 8? There is no files just the . and .. paths. pi@OctoPi:~/.octoprint/data/GPX $ sudo service octoprint restart pi@OctoPi:~/.octoprint/data/GPX $

This is the default config view of octoprint / gpx after deleting the file. https://1drv.ms/i/s!An4OlBR1JmKjx3sB2iggfELTeRC1

Then I change the settings like this https://1drv.ms/i/s!An4OlBR1JmKjx3ppnrXOoMbzFfD7

Then I hit save, and re open the settings for gpx https://1drv.ms/i/s!An4OlBR1JmKjx3x-Ny72Lzq9YDnc

The new gpx.ini file is this, mind you the software interface shows replicator 2, yet the config shows r1d. [printer] build_progress=1 ditto_printing=0 gcode_flavor=makerbot machine_type=r1d recalculate_5d=0

ODDLY shows r1d, yet when I try to print it prints as if it was a replicator 2, and heats the right extruder instead of left.

agilliam80 commented 8 years ago

Now I went back and set it again to replicator 1 (r1d), and it appended the gpx.ini file again. so it shows this again. [printer] build_progress=1 ditto_printing=0 gcode_flavor=makerbot machine_type=r1d recalculate_5d=0 build_progress=1 ditto_printing=0 gcode_flavor=makerbot machine_type=r1d recalculate_5d=0

Not trying to be over whelming with information, but those same files I sliced with different rep 1 dual, clone 1 dual, etc. those files all print correctly on wheezy using left extruder. upload same gcode files to Jessie and they heat right extruder. (we know why, cause it keeps forcing it to be a replicator 2), but wanted to clear any profile errors with slicing up.

ReplicatorG is setup as R1 clone dual, Replicator 1 dual, etc

I think I have figured it out.... Its a 1.2.12 + issue. Since Jessie lite comes with 1.2.10, and it had that problem from a virgin install. Wheezy didnt, but As soon as I upgraded my wheezy to 1.2.15,same thing started happening to the machine type. Now I am unable to use the wheezy system now too, I have to reimage it.

I have 4 pi's just fyi, and 4 different sd cards ranging from 32gb and 64gb. 1 x pi 3, 2 x pi 2, and 1x pi 1 and they all do the same thing with Jessie lite octoprint 1.2.10+. So I guess I have no choice but to go back down to a pi 2 :( so I can use octoprint 1.2.older version that comes on wheezy.

agilliam80 commented 8 years ago

I have it working sort of. I reinstalled repg 40r33 and its set to rep 1 dual. Octoprint Jessie lite shows it as a rep 2 but it is actually heating left and right extruder accordingly but having issues with the HBP being heated. I don't know what the heck went screwy or whatever on my part. But I'm still befuttled that the config file shows r1d inside the actual ini file, yet in the program shows rep 2. Maybe that's where my misunderstanding came from? For some weird reason, I used to beable to slice a file with left extruder and SAVE it as LEFT_FILE.gcode, and then slice that same file again using RIGHT extruder and save it as RIGHT_FILE.gcode, but now i cant. If I re-slice it, it saves BOTH files with the NEW slice config. so It looks like that part was on my stupid system, which i don't know why that started doing it that way.

Everytime the server is restarted, i have to re select rep 1 dual to get it to work. Another work around in 1.2.15 i had figured out. It will work fine untill i restart the octoprint server, then boom it goes down as soon as i select rep 1 dual again it works fine.

OK, I have to stop, This is actually frustrating the heck out of me. It just stopped working AGAIN.. No matter what it heats the right extruder and wont heat the HBP. and I noticed this again after updating to 1.2.15... GRR

It also appears that upgrade feature is bugged on my version. It says I have an upgrade avail which i am already on 1.2.15, i click it and it says I'm to date. then says i have update again. click upgrade and it says upgrading 1 second later says done.

agilliam80 commented 8 years ago

Cant figure this out, but somehow it worked its way out. Maybe something I did I don't know. Sorry I didn't get back sooner to clear this out. I have been gone since this was put up.