search

Ankermgmt / ankermake-m5-protocol

Ankermake M5 protocol specifications and libraries *NOT AFFILIATED WITH ANKER*
GNU General Public License v3.0
161 stars 34 forks source link

Print from the web interface #113

Closed billyjbryant closed 1 year ago

billyjbryant commented 1 year ago

Description

This PR adds a new upload button to the home page that allows for uploading gcode files directly from the Web UI

Preview

image

Console logs:

[*] FileTransferService: Requesting start
[*] FileTransferService: Worker started
[*] Going to upload 12729275 bytes as 'wall-honeycomb-224x190size_mk3s__0.20mm_PLA_M5.gcode'
[*] Requesting file transfer..
[*] TOPIC [/phone/maker/AK7ZRG0C35700749/notice]
[*] Sending file metadata..
[*] Sending file contents..
[*] TOPIC [/phone/maker/AK7ZRG0C35700749/notice]
[*] TOPIC [/phone/maker/AK7ZRG0C35700749/notice]
[*] TOPIC [/phone/maker/AK7ZRG0C35700749/notice]
[*] TOPIC [/phone/maker/AK7ZRG0C35700749/notice]
[*] File upload complete. Requesting print start of job.
[*] Successfully sent print job
[*] FileTransferService: Requesting stop
[*] FileTransferService: Worker stopped

Testing PPPP print-file

To ensure that pppp print-file continues to work I tested it as well: 

billy  …/ankermake-m5-protocol   web-gcode-upload $  ♥ 08:34  ./ankerctl.py pppp print-file -n /mnt/c/Users/billy/OneDrive/Documents/3dPrinterSD/0_SLICED/FDM/wall-honeycomb-224x190size\(mk3s\)_0.20mm_PLA_M5.gcode 
[*] Trying connect to printer Vulcan (USPRAKM-008574-TPUPS) over pppp using ip 192.168.4.145
[*] Established pppp connection
[*] Going to upload 12729275 bytes as 'wall-honeycomb-224x190size_mk3s__0.20mm_PLA_M5.gcode'
[*] Requesting file transfer..
[*] Sending file metadata..
[*] Sending file contents..
100%|████████████████████████████████████████████████████████████████████████████████████████████| 12.1M/12.1M [00:18<00:00, 694kb/s]
[*] File upload complete

Fixes: #112

chrivers commented 1 year ago

Also, please retarget to upcoming/v1.1 :)

billyjbryant commented 1 year ago

I played around with putting this on the right bar but it makes the bar too long (IMO). image

chrivers commented 1 year ago

I played around with putting this on the right bar but it makes the bar too long (IMO).

Nice idea though.

We really don't need the file selector most of the time. Maybe we could just have an "upload" button, that then opens a modal with a file selector and instructions? That way it wouldn't take much space at all.

billyjbryant commented 1 year ago

We really don't need the file selector most of the time. Maybe we could just have an "upload" button, that then opens a modal with a file selector and instructions? That way it wouldn't take much space at all.

That sounds like an idea. Maybe we can put it on the top menubar? or where else would you envision seeing it?

chrivers commented 1 year ago

We really don't need the file selector most of the time. Maybe we could just have an "upload" button, that then opens a modal with a file selector and instructions? That way it wouldn't take much space at all.

That sounds like an idea. Maybe we can put it on the top menubar? or where else would you envision seeing it?

Yeah, that might work - I'm also not quite sure where we could fit it.

How about we just make a new tab for this? Like, completely regular, like the other 3?

That would be super simple, and easy to integrate.

billyjbryant commented 1 year ago

How about we just make a new tab for this? Like, completely regular, like the other 3?

Like a completely new tab with just the upload and thats it? Also, got thoughts on how to show the progress of the upload in the UI?

just-trey commented 1 year ago

I'd suggest putting it with .the other controls on the right. Then hide it once you start the print

billyjbryant commented 1 year ago

I'd suggest putting it with .the other controls on the right. Then hide it once you start the print

@just-trey the problem with hiding it, is that we have no event that would un-hide it when nothing is printing other than a refresh of the page. This is the same reason that we decided not to hide the progress information when there is nothing printing.

chrivers commented 1 year ago

How about we just make a new tab for this? Like, completely regular, like the other 3?

Like a completely new tab with just the upload and thats it? Also, got thoughts on how to show the progress of the upload in the UI?

Yes, that was my idea. I realize that tab is not going to be incredibly full of content, but it'd be nice and simple, at least? :)

As for progress, we have a bit of a challenge.

We can certainly stream the file to ankerctl. We could then provide upload-to-ankerctl progress updates over the ctrl websocket.

(although uploading to ankerctl is probably not that slow, until the files get quite large)

A bigger problem, is that when transferring from ankerctl to the printer, we have to start the message with the complete md5sum and size of the file. So ankerctl must receive the file fully, before we can start sending to the printer.

Once again, we should be able to send a kind of upload-to-printer progress updates through the ctrl websocket, and have the ui update.

This makes me think we should seriously consider how much we could connect to the upcoming moonraker api implementation, so we don't have to do all this work twice :)

I mean, as long as we have an API, it shouldn't matter too much for our frontend what flavor it is.

chrivers commented 1 year ago

As for where we place the feature - I'm not religious about it, but I do agree with you that it's hard to make it fit nicely in the right-hand menu.

If we make a separate tab for it, we could get support for having a print queue, saving old jobs, a history, etc. All that would make sense to have on a "Jobs" tab, I think.

Do you agree?

just-trey commented 1 year ago

+1 if we want to go that far with the implementation

billyjbryant commented 1 year ago

If we make a separate tab for it, we could get support for having a print queue, saving old jobs, a history, etc. All that would make sense to have on a "Jobs" tab, I think.

How would we envision a print queue working?

billyjbryant commented 1 year ago

This is what I had come up with last night. I can make this a separate tab if we think that is a better flow. screen-capture.webm

chrivers commented 1 year ago

This is what I had come up with last night. I can make this a separate tab if we think that is a better flow. screen-capture.webm

I don't mind the idea of a popup, although I personally prefer a separate tab.

But I don't think it makes sense for one of the tab bar buttons to open a popup, while the rest change the active tab. It's just weirdly inconsistent.

If we go that, we should make it not part of the tab list, and make it stand out a bit more:

image

I'd prefer we just make a tab, though. Even though we don't have a lot of content for that tab right now, I think it would make sense to put it there. Especially since we are probably going to implement some job queue features for moonraker anyway.

What do you think?

billyjbryant commented 1 year ago

I'm not opposed to a tab, I just think it will look weird, in order to not have the footer suddenly jump up i'm going to have to force height of the container DIV. I'll play around with it tonight.

I do like the idea of having a leading button that is more separated from the tab menu and a different color to control the popup. Maybe we can go the popup route for the time being then develop a tab around it once we are ready to add other capabilities?

billyjbryant commented 1 year ago

How about this, I will build both, and let you decide which looks better :) good ole fashioned A-B test :D

chrivers commented 1 year ago

How about this, I will build both, and let you decide which looks better :) good ole fashioned A-B test :D

Sounds great! I like that :)

billyjbryant commented 1 year ago

@chrivers ok, try this on and see how you like it. :)

chrivers commented 1 year ago

This looks great!

I've been trying it out locally, and I have to say I prefer the tab style, where we have a tab for printing. I think it makes a lot of sense, and integrates well with the existing ui.

While looking at it, I had an idea that I want to run by you.

The instructions for hooking up PrusaSlicer take an entire tab right now. It's great that we have detailed instructions, but it's something that users very rarely need to do.

When we get instructions for other slicers, we need a way to collapse / navigate to the individual instructions.

So how about we (in a future PR!), make the Print tab (from this PR) show 2 cards:

Local print
[file input] upload form
PrusaSlicer Integration
collapsible section

The user can click the prusaslicer card, to get the detailed instructions.

That way, we don't need a prominent tab for rarely-used intructions, and we collect all methods of printing into one tab.

That seems like a good solution to me - what do you think?

If you agree, let's work this PR into adding the "Print" tab, and then we can add on the slicer rework in another PR afterwards :)

billyjbryant commented 1 year ago

If you agree, let's work this PR into adding the "Print" tab, and then we can add on the slicer rework in another PR afterwards :)

Sounds like a good idea to me. I'll go ahead and re-work the PR.

billyjbryant commented 1 year ago

@chrivers take a look tell me what you think