File line number 14 was expected, but 9 was received!

[nadipietro]

If this is a feature request describe it here

_REPLACE_THISFEATURE_REQUEST_DESCRIPTION_GOES_HERE

Version of Octolapse

Octolapse Version: ___0.4.0

Version of OctoPrint

OctoPrint Version: ___1.4.0

When you ran into the problem, did you have diagnostic logging enabled?

Diagnostic Logging was Enabled: ___yes

What were you doing when the problem occurred

1. ___starting a new print (in test mode or actually printing)
2. ___if I reboot OctoPrint, it will work the first time
3. ___if I start another print, I will get this fault again.

What should have happened?

___I guess it should capture the time lapse images

What happened instead?

___I get an error in the top right corner Octolapse Timelapse Stopped File line number 14 was expected, but 9 was received!

Operating System running OctoPrint and Octolapse

OS Name: OctoPi Os Version: 0.18.0

Printer model & used firmware incl. version

Printer Model: Ender 3 Pro Printer Firmware Version: Ender-3 Pro1.1.6BLTouchV3.1 PowerLossContinueEnglish 4.23

Browser and version of browser, operating system running browser

Browser: Microsoft Edge Browser OS: Windows 10, build 18362_19h1

Link to the gcode file you were printing when the problem occurred

Link to Gcode File: ___don't know how to do this

Link to settings.json

Link to settings.json with all passwords removed: _REPLACE_THISSETTINGS_JSON_LINK_GOES_HERE

Link to plugin_octolapse.log

Link to plugin_octolapse.log: LINK_GOES_HERE

Link to octoprint.log

Link to octoprint.log: _REPLACE_THISLINK_GOES_HERE

Link to contents of Javascript console in the browser

Link to javascript console output: _REPLACE_THISLINK_GOES_HERE

Screenshots and/or videos of the problem:

Screenshot/Video Links: _REPLACE_THISLINKs_GO_HERE

Please consider becoming a patron

If you like this project, please support my work by becoming a patron, and consider adding a 'star' to the repository. It takes a lot of time and effort to maintain the project and respond to issues. The cost of test prints, software, cameras, printer parts, etc. can quickly add up, so every bit helps.

You can find various videos and tutorials by subscribing to my Youtube channel. You can also follow me on Twitter.

[FormerLurker]

I can't do much without having a debug log (see the wiki here for details how to report an issue). I can give you a guess. Did you by chance use the 'Restart' function here:

If so, this is a known issue that is going to take some time to solve. Just use cancel instead and things should work correctly if this is your problem. Otherwise create a debug log according to the link above and upload it here.

[nadipietro]

Thanks for the reply.

No, I have not done a “RESTART” of the print. Although, I have paused and resumed a print with no issues.

I’ve attached the log file and a gcode file.

As I tried to indicate, after a system restart everything will print fine and the Octolapse plugin works. If I try to run the same exact print I get the fault. If I load a new print, I still get the fault. But if I restart the system again, the print will work and I don’t get the fault and Octolapse works correctly. It doesn’t make any difference if I’m in test mode or live print mode. As well, I have gotten the same results from several different prints.

Raspberry Pi 3B+

OctoPi 0.18.0

OctoPrint 1.4.0

OctoLapse 0.4.0

Python 2.7.16 (with ver. 2 dev. added)

Microsoft Edge Version 83.0.478.54 (Official build) (64-bit)

Windows 10 Build 18362.19h1

Please let me know if you need any more information.

Best Regards,

Nick DiPietro

[FormerLurker]

Please attach the log via the github interface (reply to the email with an attachment won't work unfortunately), preferably using gist.github.com, then pasting a link in this issue. Thanks!

[FormerLurker]

Also, attach your gcode file and settings.json. that will help me replicate your issue. Thanks again!

[nadipietro]

I’m not sure what the settings.json is or how to get it……

Regards,

Nick

From: FormerLurker [mailto:notifications@github.com] Sent: Tuesday, June 23, 2020 1:27 PM To: FormerLurker/Octolapse Octolapse@noreply.github.com Cc: nadipietro nadipietro@cs.com; Author author@noreply.github.com Subject: Re: [FormerLurker/Octolapse] File line number 14 was expected, but 9 was received! (#553)

Also, attach your gcode file and settings.json. that will help me replicate your issue. Thanks again!

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/FormerLurker/Octolapse/issues/553#issuecomment-648304960 , or unsubscribe https://github.com/notifications/unsubscribe-auth/AQBW2KKISV26QYAIODJ73STRYDQYDANCNFSM4OF24HZA . https://github.com/notifications/beacon/AQBW2KJTVDYFO7JHJRD4IHDRYDQYDA5CNFSM4OF24HZKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOE2SFSQA.gif

[nadipietro]

plugin_octolapse (1).log

CE3PRO_SmartTemperatureTower_TempFloor_210 - Octolapse - eSun PLA Pro+.zip

[FormerLurker]

Please see the wiki here for details how to report an issue, including how to get settings.json. It is step by step and quite detailed. Thanks!

[nadipietro]

settings.zip

[FormerLurker]

That did it, thanks! Also, and I'm sorry to be asking for items piecemeal, but what plugins do you have installed? You can just post your octoprint.log file, which will contain this info. I'm asking because I took a look at your gcode file and can't figure out how the line numbers are getting messed up. If some plugin is stripping out commands (maybe some warm-up plugin?), that would explain it.

[nadipietro]

octoprint.log

[nadipietro]

I get the same results if I preheat, or not.

[FormerLurker]

So there are a lot of plugins in that list that alter the gcode stream. Obviously I need to figure something out that doesn't rely on the line numbers, but for now could you try disabling all other non-bundled plugins except Octolapse, then reboot and see if the issue persists. If it is a plugin compatibility issue perhaps I can replicate the issue and fix it if I know what plugins are causing the problem.

I know this is an arduous process, and I appreciate your willingness to give me so much info!

[nadipietro]

OK, I'll try to determine which, if any, are getting in the way

[nadipietro]

I'm in the middle of a print right now, but I'll test this when done.

[nadipietro]

I went through all of the 3rd party plugins. They all seemed to allow Octolapse to work correctly, except "Restore Leveling After G28". Both X & Y crashed and i couldn't start the print, at all. Perhaps you can see what's going wrong.

Thanks

[FormerLurker]

OK, I see. I think that it's likely related to injecting gcode leading to line number changes. However, you can easily modify your start gcode to fix this without relying on the plugin. Just find G28 in your start gcode and replace it with this (including the G28) :

G28 ; Level Bed
M420 S1 ; Restore Leveling

Then, reslice and you should be good. Let me know if you have issues.

[sr1329]

I had the same problem. Solved. Thanks.

[marauderlabs]

I have a similar problem and fixed the first part with the M420 S1 but still I continue to get this error. octolapse.timelapse - ERROR - File line number 15 was expected, but 10 was received! This is the same one that showed up in the octoprint UI and as well as in the plugin log.

Please let me know what other info I can gather to help.

[FormerLurker]

@marauderlabs, I would need to see your gcode file to make any progress debugging your issue.

[marauderlabs]

Here it is, and the settings and log (with debug mode). The log for the current print starts at around line 280 in the log file.

CE3_tooth_top.gcode.zip settings.json.zip plugin_octolapse.log.zip

Thanks a ton, for your efforts!

[FormerLurker]

@marauderlabs, did you disable the 'Restore Leveling After G28' plugin? That is the point of adding the M420 S1 command, to eliminate the need for that plugin.

FYI, there is NOTHING WRONG with that plugin, but the kind of injection it's doing screws up Octolapse's line number detection. At some point I'll ask @foosel if it's possible to add another bit of metadata to the hooks that tells me the file line number, not the the number of gcodes sent.

Fyi, you COULD also use the classic triggers, which do not need to know exactly which file line is being sent exactly. However, prints take a bit longer (depends a lot on the model), quality may be a bit lower, and you won't get a preview. As with everything, it's a trade-off.

Let me know if that helps.

[foosel]

@FormerLurker FYI, the fileline: should already be just that, unless I'm misunderstanding your request.

[FormerLurker]

@foosel , I think we have touched on this before. I had trouble getting the existing metadata element to do what I wanted, but i can't for the life of me remember why exactly. I will double back on this. Thank you for the response! I hope we can catch up soon.

[marauderlabs]

@FormerLurker I have removed the plugin. I didn't notice that the plugin too existed in my installation. Thanks for pointing out. I had 'Restore levelling after g28 in the firmware'. I had only removed that to test this. I wanted to understand if having that restoration in firmware would conflict with octolapse.

Would I need to inject M420 S1 in my gcode through the slicer in that case too for octolapse to not have trouble?

[FormerLurker]

Yes, put it in the start gcode.

[marauderlabs]

I'm trying to understand how this part functions. So if I run a gcode (say downloaded from the internet and doesn't have the level-restoration(m420) in it but my firmware executed it automatically on G28, would that be a problem for octolapse? (or only cases like injection by octolapse through a plugin would cause that trouble?

[FormerLurker]

It is just the injection that messes up the snapshot plan. It is a limitation I hope to eliminate. Disabling that plugin will fix it. I assumed you needed the M420 because you have that plugin installed, which is why i suggested adding it to your start gcode instead of letting that plugin do it automatically. Maybe you don't need it though.

[fella5]

Glad I found this... I just disabled the plugin "Restore Leveling After G28" for now.

[FormerLurker]

@fella5, this is a recurring issue that I'm hoping to fix. It affects a bunch of plugins, like cancel region. Another workaround if you want to use the restore leveling plugin is to switch to the 'Classic' triggers, which don't have this issue (but have other drawbacks).

[davbcr]

Sorry to bother Guys, but i've the very same problem with Octolapse 0.4.1 and my Alfawise U30 pro. I've #restore level after G28 active on my FW and due to i've UBL active with BL touch sensor i'd like not to disabilitate it. Octolapse is still answering "File line number 13 was expected, but 11 was received!" each printing. Is there a way to fix it?

[bepstein111]

Sorry to bring this back up, but I'd like to ask for clarification on one thing, as some people have mentioned it but I don't think there's been a solid answer: Does having #include RESTORE_LEVELING_AFTER_G28 enabled in Marlin have the same effect as having this plugin installed? That is, in order to get Octolapse to function properly with Smart triggers, do I need to disable that feature in Marlin? I currently run G28, G29 L1, G29 A to load my latest bed mesh, and I'm unsure if M420 S1 will do the same thing.

P.S. I'm currently running into this issue ("File line number 12 was expected, but 10 was received!") so if the answer to my above question is no, there's something else triggering this issue because I don't have the "Restore Leveling After G28" plugin installed.

[Yukigamine]

Does having #include RESTORE_LEVELING_AFTER_G28 enabled in Marlin have the same effect as having this plugin installed?

I ended up on this thread because of the error "File line number 2 was expected, but 2 was received!" and now am wondering the same thing.

I can go through the rest of my plugins to figure out if any others are manipulating my gcode, but it also seems odd that Octolapse is throwing an error when in theory it received the line number that it was expecting. 😆

[FormerLurker]

I plan to figure out a way to deal with this, but the gist of the issue is that the snapshot plan records the line numbers where a snapshot should be taken before the print even starts. This is much more efficient than testing every gcode before sending it, and it allows Octolapse to examine an entire layer before making a decision about where to take a snapshot. Unfortunately the line numbers can be changed via gcode injection, and it will take a feature request to fix this (I believe). Anyway, it's been on my mind for a good long while.