Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Feedback for release v0.3.4rc1.dev3 #242

Closed
FormerLurker opened this Issue Sep 15, 2018 · 16 comments

Comments

Projects
None yet
4 participants
@FormerLurker
Copy link
Owner

FormerLurker commented Sep 15, 2018

This issue is for any general feedback regarding the new rc/devel release of Octolapse. Let me know if you have any bugs, issues, or if things are working just great! See the release notes here.

If you want to keep tracking the latest rc/devel branch to be notified right away when new releases are available and you are using Octolapse v0.3.4rc1.dev0 (a few versions earlier might work too) or above, go to Octoprint Settings(wrench)->Software Update->Click the settings wrench in the upper left corner. Then switch the OctoPrint version tracking to 'Release' and the 'OctoPrint Release Channel' to 'Devel RCs'. If you aren't notified right away, you can click 'Force Check for Update' under 'Advanced Settings' in the software update plugin.

Note: I've received reports of problems running Octolapse on Safari, specifically involving opening, adding, and editing printer profiles. If you are able to test with Safari and send me any console error logs, I'd be appreciative, Thanks!

@SystemDisc

This comment has been minimized.

Copy link

SystemDisc commented Sep 16, 2018

I'm printing now. I'll let you know if Octolapse gets triggered this time. Here're the GCode and Octolapse settings I'm using for this print.

Archive 2.zip

@SystemDisc

This comment has been minimized.

Copy link

SystemDisc commented Sep 17, 2018

@FormerLurker It didn't trigger at all again.

@SystemDisc

This comment has been minimized.

Copy link

SystemDisc commented Sep 17, 2018

I have no issues getting it to trigger in the current version that's in the Plugin Manager

@FormerLurker

This comment has been minimized.

Copy link
Owner Author

FormerLurker commented Sep 17, 2018

@SystemDisc, sorry to hear that!

When I swapped out my settings with the settings you posted I noticed that there was still an error with the current snapshot guid, and it was the same error I saw before (current_snapshot_profile_guid does not exist). Did you follow this step that I sent in the last thread:

Once Octoprint comes back up, make sure to select a different snapshot profile manually (any old profile will do), then select the one you want to use. That will fix the broken (missing) guid issue.

I'm hoping you DIDN'T follow the above step, else something different is happening. I've gotten one report of issues with Safari (which are very difficult for me to test), so hopefully there is no overlap.

Try changing the snapshot profile to 'layer change - compatibility', then immediately download your settings file and send it to me. If you notice that it reverts to the 'Every 01:00 - Compatibility' profile at some point (the first item in the list) without you changing it, please let me know.

Thanks!

@SystemDisc

This comment has been minimized.

Copy link

SystemDisc commented Sep 17, 2018

Oh, sorry. I didn't follow that step. I'm trying again.

@SystemDisc

This comment has been minimized.

Copy link

SystemDisc commented Sep 18, 2018

When I switched snapshot profiles, I got an error about the GUID missing. The same error came up (with a different GUID) when switching back. After switching back and forth between some snapshot profiles a few times, the error eventually listed the GUID as null, and on the next switch immediately after that there was no longer an error message.

I'm running a print now and Octolapse is being triggered. I'll let you know what the results are after the print finishes.

@FormerLurker

This comment has been minimized.

Copy link
Owner Author

FormerLurker commented Sep 18, 2018

@SystemDisc, I've seen that issue before, but haven't been able to pin down exactly why it happens. I've noticed that when I get that error it is usually when I first boot up the pi or run the debugger and then never again. It's probably some kind of race condition or a knockout qwirk I have yet to pin down. I've added some breakpoints and will try to catch it in the act.

Glad Octolapse is finally triggering, and thanks for all of your help so far!

@ryanneufeld

This comment has been minimized.

Copy link

ryanneufeld commented Oct 7, 2018

I'm trying the rc as well, and even though my gcode has a G90 comamnd I'm getting the position error.

Further to this, it seems like it starts recording many layers after the first. It's recording the whole time-lapse though

X-motor strain releif v8.gcode.gz

image
plugin_octolapse.log.gz

@FormerLurker

This comment has been minimized.

Copy link
Owner Author

FormerLurker commented Oct 8, 2018

@ryanneufeld,

This is happening because there are movement commands (G1 in this case) before your XYZ axis mode is set:

G92 E0.0
G1 X60.0 E9.0  F1000.0 ; intro line
G1 X100.0 E12.5  F1000.0 ; intro line

In my opinion this is not a safe operation.

Fortunately it is quite easy to fix! Just move the G90 to the very top of your start gcode.

Also, I'm not sure why that G92 command is there (G92 E0.0) since M83 is set above that. There could be some reason.

Is this the default start gcode for the Mk3 Slic3r PE profile?

@ryanneufeld

This comment has been minimized.

Copy link

ryanneufeld commented Oct 9, 2018

@FormerLurker

This comment has been minimized.

Copy link
Owner Author

FormerLurker commented Oct 9, 2018

@ryanneufeld, thanks for your response. Perhaps someone should post an issue on their github page regarding the those G1 commands. If for some reason one sends a G91 and then starts a print without a power cycle, it's possible to literally run into trouble :)

Did moving G90 to the top fix your issue, by the way?

@ryanneufeld

This comment has been minimized.

Copy link

ryanneufeld commented Oct 9, 2018

@smplfy

This comment has been minimized.

Copy link

smplfy commented Oct 12, 2018

Hi there, just noticed when running an external DSLR that I had a communication timeout. Seems to function mostly normally but every time the snapshot is taken I get this:

"Communication timeout while printing, trying to trigger response from printer. Configure long running commands or increase communication timeout if that happens regularly on specific commands or long moves."

Sometimes I get that message twice in a row.

@FormerLurker

This comment has been minimized.

Copy link
Owner Author

FormerLurker commented Oct 17, 2018

@smplfy, so sorry for the late response, but I've been unable to work on Octolapse for the last week or so.

Check your camera profile and look at the 'Timeout' setting. I think it defaults to 5000MS (5 seconds). That's a really long time IMO, but if you are taking very high resolution images it takes a long time to both save the image to your camera's RAM, and then even longer to copy them to the PI via USB (probably usb 2.0). Though increasing the timeout will (hopefully) eliminate the error message, you have two options to reduce the amount of time it takes to acquire an image from the DSLR in the first place:

  1. Reduce the resolution - this will have a big impact. If you dont need 4000x6000 or higher resolution for video editing (or some other purpose) you should consider reducing it somewhat.
  2. Prevent the camera from downloading the image to the pi until right before the timelapse renders. This has the unfortunate side effect of preventing snapshot preview (the picture won't update on the Octolaspe tab), preventing snapshot transposition (flip, mirror, transpose, etc), and preventing text overlays (rendering settings).

Please take a look at this reply I made on the Octoprint discourse site: https://discourse.octoprint.org/t/octolapse-how-to-turn-off-saving-and-rendering-to-the-pi/4341/5?u=formerlurker

It explains how to configure Octolapse so that it:

  1. Deletes all images on your camera SD card recursively (this stinks, but it's necessary. backup your family photos first!)
  2. Set the capture target to SD instead of internal RAM.
  3. Capture an image from the DSLR, but return IMMEDIATELY after the shutter closes, before the image is saved to SD.
  4. Right before rendering download all of the images from the camera and rename/place them in the appropriate directory so that the timelapse can be rendered normally.

Note: Rendering a 4K+ video on an RPI takes a really long time and takes a lot of space.

I'm working on a guide for this process, as well as another setup video.

Let me know if this helps.

@smplfy

This comment has been minimized.

Copy link

smplfy commented Oct 18, 2018

@FormerLurker

This comment has been minimized.

Copy link
Owner Author

FormerLurker commented Nov 15, 2018

This is now closed since V0.3.4 has been released. Thank you for your contributions, and be sure to check out the feedback issue for v0.3.4.

Closed!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.