"no job running" while a print is running

[spiff72]

I have been getting issues lately when starting a print from the Octoprint interface (not via the Octodash touch interface) where it states "no job running" during my prints now, instead of showing the title of the file. I don't think that I have changed anything other than adding the enclosure temperature (via config file adjustment).

This behavior is very consistent lately. I have rebooted the RasPi and it doesn't change the result. I also find that the layer number displayed is incorrect lately - but I think that is an issue with the layer plugin. (Notice it says Layer 3 on the screen, but this is the first layer. The Octoprint web interface shows it is on layer 2).

The only thing that I can think of that is different is that I am adding a bit of custom GCODE via the "Start GCODE" section of my slicer (PrusaSlicer) to handle a temperature configuration for my exhaust fan (via the Enclosure Plugin). This is the code if it is helpful:

{if first_layer_temperature[initial_tool] > 225}
ENC O2 W0 S40
{else}
ENC O2 W0 S30
{endif}

[UnchartedBull]

Which version of OctoDash are you running? There was an issue with this in one of the versions, which caused everything to get out of sync. But I though I already included the fix. Could be that this hadn't made it into the last release. I hopefully can release a new version soonish, which should definitely fix this problem. Please wait a couple more days :)

I'll have a look at the Enclosure error. OctoDash adds +1 to everything, because the plugin started counting at 0 initially, that's why I moved everything up by one.

[spiff72]

Is there a way to check the Octodash version while a print is running?

[spiff72]

Also, I have the Layer Status Plugin configured to offset the layer height by 1 (in the "Layer" tab of the plugin settings), so if you have this hardcoded to add 1, that might explain this error.

[UnchartedBull]

There is no option to see that in OctoDash you could maybe do that via the CLI and get the version of the octodash package.

[spiff72]

Sorry - what would that command be? I am running out to an appointment and can check this when i get back. I am about 90% sure that I am running the latest version that shows up in the Releases tab though (1.3.3)...

[spiff72]

I figured it out with dpkg -s octodash

It is 1.3.3

[UnchartedBull]

Ok I'll have a look at why this happening. OctoDash is showing printing in the lower right corner and switched from main-menu over to the printing-screen, so the program definitely knows that a print is going on.

[UnchartedBull]

Did you start the print via the Cura or PrusaSlicer API by any chance?

[UnchartedBull]

Ok I did some further digging and this probably due to the fact, that there is some data missing in the API response object. Are you able to install the attached build of OctoDash and send a picture of the error, that is (hopefully) showing once you see the "no job running ..." screen? The build should be stable, but if you're planning a longer print, please wait until after that is done :)

https://drive.google.com/file/d/1mDDNjEI7MWGl-3pNCLU0A-sdlk1VxdIh/view?usp=sharing (GitHub won't accept that file here, since it is to large)

You can just install that via sudo dpkg -i octodash_1.3.3_armv7l.deb. If you run the update script again after that it should switch back to the normal version.

[spiff72]

I will install this later today and let you know. Will the error be on screen or do I need to look elsewhere for the error?

The print was started using the Octoprint interface. It is a multi-material print if that matters (technically the print only uses one material, but it was sliced for the MMU on my Prusa and assigned a single extruder for the job).

[UnchartedBull]

It should show as a normal error message (so the card that comes down from the top). Thanks for trying this out!

[spiff72]

I would do it remotely from work, but I can't see the screen from here. ;-)

I will try it later tonight most likely.

Thanks!

[UnchartedBull]

No pressure, take the time you need :)

[evannadeau]

I have this issue occurring now also. The only change is that I am now using the Prusa MMU2. Does OctoDash save the printer profile it would be looking at? As in terms of changes, that is where it would be, I think.

[UnchartedBull]

What I suspect is that if you print with MMU2 one or two of the attributes for the job information are missing / have a different name. I don't have a MMU2 so I can't test this locally. But feel free to download the dev build linked before and post the error here :)

What do you mean with printer profile exactly?

[evannadeau]

I mean in OctoPrint, I had to change my print profile to one that included multiple extruders. It was just a guess that maybe OctoDash was looking for jobs going to the old profile? I kinda doubt it, as it probably just looks for active print job via the API, but just guessing at the moment without looking at the code myself.

I'll take a look at the dev build, thank you.

[UnchartedBull]

You're 100% correct. OctoDash just queries the Job API and does not really care about printer profiles. One thing I could think of is, that the filament length isn't transmitted in the same way as it is for a normal printer. Since you have 1 tool with multiple filaments. Currently OctoDash is looking for data.job.filament.tool0.length I could think of OctoPrint transmitting data.job.filament0.tool0.length or something like that

[evannadeau]

Ah, there is probably our answer. We need to look for other tools. I have tools 0 - 4 now. As a reference, as soon as I changed to this new printer profile, the Filament Manager plugin now picked up all my tools, so maybe we can find some code there. And the test print I just did, used only tools 1 and 2. I'll do a test print right now using tool 0 (Filament 1 from the MMU).

[UnchartedBull]

Ahhh ok they show up as different tools there. This would be fixable fairly easy as I can just add together these 5 or how many are available, which will make this work again. Would be great if you or @spiff72 could post the API answer to GET /api/job while printing with multiple filaments. Just to get to know the data structure and test the additions :)

Your temps did show correctly though, didn't they?

[evannadeau]

Yes, I believe everything else is showing up correctly and says printing in bottom right corner. I'm still running tests to try and figure this out. Seems that if it is a single colour print, there is no issue, but I'm not 100% sure yet, as I've found another bug. :) I will open a ticket for that shortly.

[UnchartedBull]

tool0 is currently hardcoded, so if that is used everything should be working. Would be also good to have the api response to GET /api/printer while running a MMU job, just to be sure :)

[evannadeau]

Yes, I'll get you as much data as I can. As a starting point, here is the printer at rest.
at_rest.zip

[spiff72]

This makes a lot of sense - I had been printing mostly with Extruder 1 (Tool 0) lately, but i was using Extruders 3 or 4 for the jobs that prompted me to post this issue.

…

On Tue, Feb 11, 2020 at 11:54 AM Evan Nadeau ***@***.***> wrote: Yes, I'll get you as much data as I can. As a starting point, here is the printer at rest. { "sd": { "ready": true }, "state": { "flags": { "cancelling": false, "closedOrError": false, "error": false, "finishing": false, "operational": true, "paused": false, "pausing": false, "printing": false, "ready": true, "resuming": false, "sdReady": true }, "text": "Operational" }, "temperature": { "bed": { "actual": 25.2, "offset": 0, "target": 0.0 }, "tool0": { "actual": 26.8, "offset": 0, "target": 0.0 }, "tool1": { "actual": 26.8, "offset": 0, "target": 0.0 }, "tool2": { "actual": 26.8, "offset": 0, "target": 0.0 }, "tool3": { "actual": 26.8, "offset": 0, "target": 0.0 }, "tool4": { "actual": 26.8, "offset": 0, "target": 0.0 } } } — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#411?email_source=notifications&email_token=ACXTM56TZU5YJUOBQ3K52ULRCLJ3FA5CNFSM4KSQESIKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOELNFSCI#issuecomment-584734985>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ACXTM567IV4JM655YUKM3ITRCLJ3FANCNFSM4KSQESIA> .

[UnchartedBull]

Ok here is fairly experimental build: https://drive.google.com/open?id=1G5Nme2aN-ZLKVtQ_TynBmhu_T8gh8v7u

This time this includes the newest features and everything, so there could be some stuff that isn't working. You will get the newest config, with the settings menu enabled and all the other new features though. Important to note that you can't go back and that your custom actions will be reset. Otherwise this should work. Final release will be in (hopefully) a few day. So no pressure to try this out, if you don't want to.

[UnchartedBull]

Should be fixed in the new release. Please reopen if the issue still persists.

[spiff72]

I intalled the second fixed version you posted in this thread, and I got an error message after rebooting:

So i took a shot at removing the config file, and ran through the initial setup screens.

I ran into a problem with the default port of 5000 (it failed to finish all the checks at the end). I then remembered this happened the first time I set this up and deleted the port value, and this got me through the rest of setup. I then went into the settings to set the enclosure temp sensor to "1", and when I exited I just got a black screen. So i rebooted.

This then took me to the main screen with an endless stream of API errors. I figured this was related to the port value, so I went to the config file, and the line showing the url for octoprint read:
"http://xxx.xxx.x.xxx:NaN/api/" (with the correct values for my octoprint server)
I fixed this by deleting the NaN (to match my old config file - which i had backed up).
Rebooted again, and all is good, at least as far as getting octodash up and running. I didn't get a chance to print anything yet because it was getting late.

Hopefully this is helpful info for you.

Thanks again (and the sneak peek at the settings stuff looks great!)

[spiff72]

One more thing - I poked around in the settings again after making that post, and I saw that the NaN value showed up in the port value. I ended up saving settings after adjusting something else (file sort order), and I got stuck in the black screen (of death!) and this time before rebooting i checked the config file via ssh and the NaN was added back into the URL line again. Deleted NaN, rebooted, and back to normal until I change settings again.

I tried changing the port to 5000 again, and I get the black screen after exiting the settings again.

[UnchartedBull]

Ok it seems like there are multiple things wrong here:

First the port input field in the settings menu ... Weird thing is, that it works just fine in the no-config setup. I'll have a look on how to do this correctly with an empty port. Did you try port 80?

Second thing is the config not being updated correctly. Normally you shouldn't see the error you have there, but rather you should be taken directly to the setup screen with all the values prefilled.

And lastly the black screen after saving the settings. I definitely have to investigate this. Would you mind sharing both of your configs (old & new) (don't forget to remove your API Key). This would be really helpful. Thanks!

[UnchartedBull]

Ok the second issue is me being not the smartest. I started the branch for the fix, before I merged the settings update branch. So only two issues left. I'll also don't need your old config then, but the new would be awesome, as I can't reproduce the black screen issue.

[UnchartedBull]

https://drive.google.com/open?id=1bvwU8wMqO0gJkG6HjUBwxkfm31xq0hku here is the latest update that will fix the NaN values. The black screen issue will then be fixed with the final release, so please report back if this issue still occurs with the latest build.

[spiff72]

OK - here is my config file (prior to me installing the updated build you just posted).
As I mentioned, I remember the port value was a sticking point for me when I first installed Octodash, and I may have posted an issue or a comment regarding this at that time (Confirmed -- Here is the link to my comment:
#198 (comment) )

Based on the thread above - port 80 does work.

config.json.zip

[spiff72]

I installed the latest build you posted now, and rebooted the pi. Unfortunately that is all I can do (other than interaction via ssh now, as I am accessing it remotely - I can't touch the screen to wake it up). I do have a camera pointed at the screen, and I can see that it made it to the initial screen, and it currently shows "Shhh. Octodash is sleeping - touch screen to wake up", and there is an error card about not being able to read printer status. This is pretty typical, as I think the printer hasn't connected yet (it normally will when I touch the screen, and then the error can be dismissed).

I also looked at the config file and I don't see the NaN in there. Maybe I should just change it to port 80 and be done with that...

[UnchartedBull]

I just loaded your config into my dev environment and wasn't able to reproduce the error with the black screen after a config save. The thing OctoDash does after a config update is to reload the Website, I may have to test this on the Pi as the app may get killed during the process and doesn't restart correctly ...

The issue with the port is fixed though. So feel free to leave that empty, or enter 80 it should work both ways around. In the config file there will be no port listed then :)

[spiff72]

I can't be sure, but I assumed the error was a result of the "NaN" getting dropped back into the URL port field. If you fixed the NaN re-adding itself to the URL port field during config saves, I think that will likely have fixed the issue. I will check this tonight now that the fixed build is loaded.

Is there any way to simulate/emulate screen touches or inputs via an ssh connection?

[spiff72]

Well - I am still unable to do anything if I save anything in the setup menu.

I tried when I got home today, and when i saved I got the black screen of death again. I inspected the config file and it had replaced the blank space there with "null". So I changed it to 80, rebooted, and the same thing happened. Just going into the settings menu, changing nothing, and hitting the "save" button kicks me to the BSOD. The 80 value for the port stays now, though (no more null or NaN)

[UnchartedBull]

I think the black screen is due to the reload that happens after a config change. Somehow Electron thinks, that the website was closed and is closing the whole app, which will not get restated. Hence the black screen (which is actually just the normal desktop of Ratpoison). Currently trying to figure out a way around this.

[UnchartedBull]

Ok I think I finally fixed that. Here is the latest version: https://drive.google.com/open?id=1f67WDOKAOIu0C0vNFR3H1Quz2NKh4RW2. Although I hope to finally release the next version soonish, but feel free to try the dev build and report back :)

[spiff72]

i will install it and let you know later tonight whether the BSOD is fixed.

Thanks!

[spiff72]

I can confirm that the BSOD bug seems to be squashed! Exiting settings leads to the Octodash splash screen and then back to the home screen.

I also noticed that it behaved better when waking from "sleep". The printer was connected to Octoprint, and when I touched the screen to "wake" octodash, it didn't cause a reconnection event on the printer.

[UnchartedBull]

Great to hear that. The Standby Screen improvements were merged with #378.