PrusaSlicer Repetier-Server 1.5 Upload and print confusion

rwillett

Hi,

I'm running Repetier-Server 1.4.2 (RS-1.4.2). I have two Prusa MkS3+ printers and am doing some repetative printing andwanted to see if RS-1.4.2 offers any advantages over two Octoprints each on a Pi 4.

I have RS-1.4.2 setup on a single 8GB Pi 4 with both printers. That worked well and was easy to do.

I really like the thumbnail rendering.

However I am struggling to get "upload and print" on my PrusaSlicer with RS-1.4.2 groups. I set a group up on each of the two Prusa's and send the gcode down to the Prusa. The file doesn't go into the group selected but goes straight to the Print Queue, it is printed and then as far as I can see, dissappears so I can't reprint it. It doesn't go to the group specificied and once it's printed, vanishes.

If I upload from PrusaSlicer to a group, it does work, but then I have to go to RS-1.4.2 to manually send it to be printed.

The lack of history seems odd, no ability to reprint if a job is lost, the upload and print seems plain wrong to me.

Any help or advice welcomed,

Rob

Repetier

Actually what prusa does is correct. The print queue ha sno groups and if you select upload and print it gets send to print queue and not to permanent storage. If you send to group it gets not printed because that is just for storage and you need to select it and run print, which actually makes a copy to print queue. Prusa Slicer has no option to store and print.

In default settings a print vanishes from queue if it was printed to the end. If it gets stopped it will remain for reprint. So main problem is if it gets printed to the end and then you see that you had issues so quality is bad and want to reprint. MOst often you will try with different slicer settings, but I see it could be a past print. So maybe adding a recent print recover function would cool here. Will discus this with the team. 

rwillett

Thanks for the reply.

I'm unclear why PrusaSlicer is the issue here, if I send a file to be printed, Repetier-Server can control and manage exactly what happens. I don't want PrusaSlicer to store and print, thats what I hoped Repetier-Server would do for me. I want to use the right tool for the job, PrusaSlicer slices things and generates g-codes, Repetier-Server manages the printing and storage. Surely you can decide how to manage this?

Given that large USB filesystems are common and indeed probably the norm, having a history seems relatvely easy to do, indeed I think you have most of the framework in palce now, you have the concept of Groups and a History group asanother default could be an option, files get automatically copied into that when they hit the print queue.

Thoughts and views welcomed.

Thanks

rob

Repetier

PrusaSlicer is no issue, I just described what it does. It either sends it to print queue or it sends it to group. There is no option in server to have both so slicer has no selection for both. Groups are always visible since slicer does not know if you want to store or print. If you want both you need to send it twice or store and in server start the print.

rwillett

Thanks, thats the point I was making.

if PrusaSlicer sent this to print, then Repetier Server should queue it up as normal AND then add it to group called History, so we have a copy saved. You have all the tech in place now as far as I can see. if it's a good print, you can move it to a better group.

Sending it to a Repetier-Server group can also send it to be printed. You control Repetier-Server so you can put a flag on a group that PrusaSlicer sends to that copies to the print queue. Again you have all the tech in place.  You can have a group that doesn't print as well, just put a flag on the group settings.

Sorry if I have misunderstood, but to me, you have all the components now, you need to put them together. I also know that these changes are not as simple as I make out. I was a C andUnix developer so some things are harder than they look.

Thanks

Rob

Repetier

I think in general it is too confusing if if then have to select:
- Store gcode
- Queue print
- Print
- Store and Queue
- Store and print

Which is the result of this. Also if we do it every client needs to be reprogrammed:-( I doubt that all will change. Already the queue option is not inside prusa and I don't think it will be added. I've told them about the existance, but they want the obvious what users normally want - store or print.

What we will do is remember last x printed files so you can still reprint even if it was removed from print queue. So files are not deleted directly in case you need them due to an error again.

rwillett

I think I'm missing the point here, so let me give examples.

PrusaSlicer (not any client) doesn't need anything changing, we use the same interface as now, the same words.

1. When the user selects "Upload", it goes to the group selected in the Repetier-Server dialogue box - No change.

2. When the user selects "Upload and Print" AND any group but "Default" is selected, then the file is sent to the Repetier-Server print queue, as now, but is also copied to the selected group in Repetier-Server. The new behaviour is the copy from the Repetier-Server print queue, but since you control the server and you already have the functionality, this shouldn't be that complicatated. I assume there's a directory system and/or a database, e.g. SQLite.

3. When the user selects "Upload and Print" AND the "Default" group is selected, then the file is sent to the Repetier-Server print queue - No change

4. Every file printed is automatically sent to a Group called "History" which is a new Group that exists for each printer which is a simple time ordered list of what has been printed.  - This is basically the same as point 2 but to a specific Group.

The changes are copying a file from the print queue to a specific Group. That's it.

Thanks

Rob

Repetier

Print queue and models are different folders and past prints will also become a new folder.
Default is a existing group that you decide to neglect here plus that uploa dmodel and upload print are different urls with the later not getting the group at all since queue has no groups.

As developer I know I can write that but I also do not think it is a good idea, despite I understand you want that function. But I also get support questions and this would cause even more questions in total as it gets complicated. It needs new client UI to make it clear for everybody and you can as client developer already just upload to both functions if you want that. But that is not the typical usage and just a small improvement for the lazy wanting to skip a step. And wth the new past prints it is even needed less as this cures the main reason you want a copy.

rwillett

Ok, I'll leave it then.