V1.8 is much slower than predecessor(s)

[Googliola]

I noticed that it takes additional time (maybe 15-20s) before I see an output in the command window and starts uploading.

With the same network settings, V1.7 the search for a printer starts almost immediately.

No biggie, but just maybe something you wanna look into.

[macdylan]

Thank you for your feedback. Can you provide more information?

• has the hosts.yml file been created?
• using HTTP or SACP? Passing -debug arg to run to get more detail.

[Googliola]

• hosts.yaml is present: printers:
  • ip: 192.168.1.23 id: SnipSnap model: Snapmaker J1 token: "" sacp: true
• SACP I guess (that seems to be the default) Here's what I could grab from the console before it closed (it worked just fine). 30 secs before smfix starts.

[Googliola]

Just to make sure that my versioning of smfix.exe is messing things up, I now keep only one copy of it in the same directory and rerun the test. Same result:

[Googliola]

Same with V1.7:

The console for smfix just quickly pops up and then it's gone. No delay at all.

[macdylan]

Try to use -smfix c:\Proggies\smfix-win64.exe to temporarily resolve this issue. I apologize for the inconvenience. when -smfix is not specified, sm2up will attempt to search in the directory, which may be ths issue. Could you please let me known approximately how many files are in that directory (c:\Proggies) ?

[macdylan]

I made an update: https://github.com/macdylan/sm2uploader/releases/tag/v1.9 Please let me know if this issue is solved.

[Googliola]

Ran the test with V1.9 and delay is gone. I have 10 files in and about 40 folders in my sm2up directory (c:/proggies). I suspect that smfix walked the whole tree including subdirs which slowed it up considerably as the last match might and probably was at the very end of the walk..

[Googliola]

While the upload works without delay now, the preview image is not displayed on my J1. It seems as if smfix is skipped altogether now, despite smfix being present in the same directory. Using "C:\Proggies\sm2uploader-win64.exe"; in PrusaSlicer post-processing script.

When I add smfix to post-processing script, like so "C:\Proggies\smfix-win64.exe"; "C:\Proggies\sm2uploader-win64.exe";

Things work like they used to.

[macdylan]

Sorry i didn't test it in windows, now i did: https://github.com/macdylan/sm2uploader/releases/tag/v1.10

And also, if your printer IP is fixed, I recommend add -host SnipSnap flag in the pp script. or use OctoPrint mode.

[Googliola]

V1.10 now finds smfix in no time and shows the path in the console. So that's good.

-host SnipSnap flag did not make much (any?) difference in my case.

What do you mean by OctoPrint mode? These are my settings and the error I get when I test the hostname (but upload OK!):

Your response time is just crazy good. Thank you!

[macdylan]

To use OctoPrint mode, first you need to remove the pp script settings.

You can create a start-octoprint-j1.bat file in the sm2up directory with this content:

c:\Proggies\sm2uploader-win64.exe -host SnipSnap -octoprint localhost:6789
@PAUSE

Save and double-click to execute, it will appear in the cmd window that says ... now you can upload files to http://localhost:6789

Fill that http://.... into the OctoPrint settings and click the Test button.

Screenshot in #4

-host SnipSnap means there is no need to start Discovery and instead use the cached info in hosts.yaml, which will save 4-6 seconds.

[macdylan]

If you dont known how to create .bat files, follow this:

• Open notepad.exe and write down the above content
• Save, select All files (*.*) in "Save as type"
• Locate to target dir, write the file name to start-octoprint-j1.bat and click the save button

[Googliola]

Your instructions are great, thanks for your efforts. (I used to work as a software tester and have a good sense for the source of errors :) I followed your instructions, but connection was refused, see for yourself:

Since I was not familiar with the [::] notation (I am mostly a Windows person), I replaced it with localhost and there you go: *ignore the fact that localhost is missing in the first screenshot. I restarted the server with localhost included, same result.

Case closed. But I would distill the instructions and our findings from this issue and create a short how-to section on github for others to use the server option more easily.

Thanks again. It was a pleasure to cooperate with you, McDylan! Cheers