[1.4.2] List of gcode files shown empty after update
Just updated from 1.3.0 to 1.4.2.
Now the list of uploaded gcode files is always shown as empty (even if I switch to the "all" group).
When uploading new files I see no error in the logfiles - just no entry in the list of gcode files.
I already tries to delete all gcode files and even removed all groups but Default, still newly uploaded files aren't shown, the list stays empty.
Thus the only way to start a print atm. is via direct print - this works.
Now the list of uploaded gcode files is always shown as empty (even if I switch to the "all" group).
When uploading new files I see no error in the logfiles - just no entry in the list of gcode files.
I already tries to delete all gcode files and even removed all groups but Default, still newly uploaded files aren't shown, the list stays empty.
Thus the only way to start a print atm. is via direct print - this works.
Comments
Which OS is the server running on?
This is no usual behaviour so the question is, if ther eis some defect on filesystem or something prevents accessing the model folder in data storage/printer/(slug)/model folder. Did you check already if the folders are empty. The logfile to check would be server.log. You also should update to 1.4.3 in case a bug fixed in 1.4.3 is causing this.
sure, I have rebooted, even switched the printer off and on again.
Will have to contact the printer manufacturer which exact OS they use, think it is some kind of Linux (and/or check whether I have ssh access to the shell - currently the integrated Raspberry Pi directly boots into the Repetier Server UI). Have used the update feature in Repetier server which pulled the then-latest version yesterday. Am currently not at home, think it was 1.4.2. If 1.4.3 is available since today I can do the update. How would I install another version than the one that is pulled by the auto-updater?
Installed OS: Raspbian GNU/Linux 10 (buster)
Found some model files on the drive (the *.g files seem to contain gcode):
...
There seems to be enough space available:
Found this in the system.log:
...
Here the exemplary content of /var/lib/Repetier-Server/printer/iFactory3D__One_Pro/models/00000010_3DBenchy.gin:
xMaxMove: inf
When it reads inf it gets syntax error, becaus eit is no number. I tested this actually and I got the error message you have and it was recomputed (the gin file) and then had correct value. If you still have inf it might be something in your brnchy .g file causing this. Would be great if you can offer that slice for download so I can test if it causes the values to be computed as inf somehow.
None the less it would return info with missing/wrong default values but not stop loading.
Now the g-codes are associated to a group in /var/lib/Repetier-Server/printer/iFactory3D__One_Pro/modelGroups.json file. Check with
cat /var/lib/Repetier-Server/printer/iFactory3D__One_Pro/modelGroups.json
if it still correct. Has actually same format as old server so doe snot get updated. Anyhow, please also check if you see the models when you select group "All" instead of default or what ever you had active. This should show all g-codes regardless of which group it is associated.
. .. data jobs last_prints logs models Plates timelapse
pi@ONEPRO:/var/lib/Repetier-Server/printer/iFactory3D__One_Pro $ sudo find / -iname modelGroups.json
/var/lib/Repetier-Server/printer/iFactory3D__One_Pro/data/modelGroups.json
pi@ONEPRO:/var/lib/Repetier-Server/printer/iFactory3D__One_Pro $ cat data/modelGroups.json
{"files":[{"id":1,"p":"#"},{"id":2,"p":"#"},{"id":3,"p":"#"},{"id":4,"p":"#"},{"id":5,"p":"#"},{"id":7,"p":"#"},{"id":8,"p":"#"},{"id":9,"p":"#"},{"id":10,"p":"#"},{"id":11,"p":"#"},{"id":12,"p":"#"},{"id":13,"p":"#"},{"id":14,"p":"#"},{"id":15,"p":"#"},{"id":16,"p":"#"},{"id":17,"p":"#"}],"groups":["#"]}
Edit: The gcode files were shown with 1.3.0 (so did this still accept "inf"?). Semantically infinite makes sense - it is a belt printer
Apparently the "delete all g-codes in this group" functionality didn't delete anything, but the manual approach worked.
As soon as I upload the Benchy again, all entries disappear from the list. If I delete the Benchy from the models folder again and reboot the server they reappear.
Odd thing is that other, own models that I also sliced with IdeaMaker don't seem to lead to the same problem - even though they also have "xMaxMove: inf" in their *.gin file. So perhaps the "inf" thing isn't the actual problem with the Benchy? (And as said, the Benchy worked with 1.3.0)
Maybe it is related to belt printer. Did you select in shape that it is belt printer and select correct angle (45 i guess)? Maybe the transformation in combination is the problem, who knows. Belt has infinite z, but you should not set it. All prints start at z=0 so z length should just be size of belt at least in server. That is what looks best and you still see the object coming out and in to bed.
1.4.3 had some improvements for belts and xMaxMove is also quite new. Should be biggest x position during print and that is not inf. But with some math error it might get inf, question is just how since illegal computation lead to NaN and inf is harder to create.
Would be interesting to understand why it worked with Repetier Server 1.3.0. (I mainly updated because I had sometimes the issue that after stopping a print it immediately restarted unless I deleted the job from the print queue also . (The item was in the print queue with quantity 1). The printer support meant that this is a known problem, so I wanted to check whether this is already solved with the newest Repetier version. Initially 1.3.0 was preinstalled.)
> The printer support meant that this is a known problem
I'm not aware of this issue. But we changed quite some belt issues in the 1.4.x stream including automaically printing next files in queue switch so you can use it like a factory.
Let me know if it still happens and if there is a way to reproduce. Just tested in 1.4.4 2 files in queue and stoping one and no new job was started. Regardles if print next was on or off, which is good since manual stop means something is wrong normally.