Web interface doesn't see my gcode layer changes

Ok, so I'm still on ZPL's 1.05 web interface

when I used a gcode supplied with the firmware (i.e. ormaxis.g) the web interface detects layer changes fine.

When I use a file generated with slicer 1.26 (current experimental) it doesn't see layer changes (always thinks it's layer 1 of ....). So I know the issue is with how I'm generating g codes.
I assume this is because I missing some flagging line of code in my custom start gcode? if so, what do I need to add?

Does the web interface report the correct layer height? And does it display the first layer height/duration? If you get a chance, please post a screenshot of the print status page after the first few layers.

FYI the new web interface doesn't perform layer detection as the old one used to do, I moved the corresponding code into the firmware. Hence it would be good to know which values are reported during a Slic3r 1.2.6 print.

The layer height looks good. The first layer time just winds up being the print time - warm up time, since it thinks it's on the first layer the whole time.

I'm using DC42 1.04e firmware, so maybe that has something to do with it...
I'm also using the new '3D honeycomb' infil, so there might be more move commands in the infill than usual....

Here's a screenshot, the layer thickness is 0.5mm, and it just started the 3rd layer:



Let me know if you need anything else.

Edited 1 time(s). Last edit at 04/17/2015 01:57PM by shadow651.

I see, I believe the problem is that my firmware implementation (which is present in dc42's firmware as well) doesn't determine the first layer height if it's greater than or equal to 0.5mm. I'll change the threshold value to 0.55mm in my next firmware release, that will probably fix this issue. It would probably make sense to set some of these parameters using a G-code - I'll think about it again.

You could check this once more by setting the first layer height to 0.4mm, I guess the web interface will work just fine if you do that.

nevermind

Edited 1 time(s). Last edit at 04/17/2015 02:29PM by Darathy.

btw it has been reported to me that if you use absolute extrusion instead of relative extrusion, then the estimated end times are less accurate, because the firmware seems to start a new estimate every time a G92 E0 code is encountered (typically on each layer change).

---

Large delta printer [miscsolutions.wordpress.com], E3D tool changer, Robotdigg SCARA printer, Crane Quad and Ormerod

Disclosure: I design Duet electronics and work on RepRapFirmware, [duet3d.com].

Quote
dc42
btw it has been reported to me that if you use absolute extrusion instead of relative extrusion, then the estimated end times are less accurate, because the firmware seems to start a new estimate every time a G92 E0 code is encountered (typically on each layer change).

Are you sure? I know Cura generates G92 E0 calls as soon as the filament usage reaches nearly 10000mm (AFAIR) but I have not seen any slicer that generates G92 calls after each layer change. Besides, my implementation relies on the raw filament usage (which shouldn't be affected by G92 calls anyway) so I can't see how this would mess with the final print estimations. But, of course, correct me if I'm wrong

Quote
dc42
btw it has been reported to me that if you use absolute extrusion instead of relative extrusion, then the estimated end times are less accurate, because the firmware seems to start a new estimate every time a G92 E0 code is encountered (typically on each layer change).

Yea I already figured out that one by accident

seems that the stock RRP slic3r settings have absolute extrusion on, but I had relative in my config, so that caused some random over extrusion. Plus filament counts and filament time estimates that keep resetting to 0 and N/A everything G92 is in the file.


I'm still seeing this with first layer height set to 0.3mm and all other layers set to 0.1mm... but now it's not correctly indicating the first layer height..... I suppose before the first layer height and the rest were the same



Edited 1 time(s). Last edit at 04/17/2015 03:26PM by shadow651.

Quote
zombiepantslol

Quote
dc42
btw it has been reported to me that if you use absolute extrusion instead of relative extrusion, then the estimated end times are less accurate, because the firmware seems to start a new estimate every time a G92 E0 code is encountered (typically on each layer change).

Are you sure? I know Cura generates G92 E0 calls as soon as the filament usage reaches nearly 10000mm (AFAIR) but I have not seen any slicer that generates G92 calls after each layer change. Besides, my implementation relies on the raw filament usage (which shouldn't be affected by G92 calls anyway) so I can't see how this would mess with the final print estimations. But, of course, correct me if I'm wrong

No I am not sure, I am going on a report from another user - see [forums.reprap.org].

Edited 1 time(s). Last edit at 04/17/2015 03:50PM by dc42.

---

Large delta printer [miscsolutions.wordpress.com], E3D tool changer, Robotdigg SCARA printer, Crane Quad and Ormerod

Disclosure: I design Duet electronics and work on RepRapFirmware, [duet3d.com].

Thanks for that link - I'll look into it. I must admit I haven't used Slic3r in a while as I've been quite happy with Simplify3D...

well ,nevermind my erlier nevermind, i am printing a Y idler and it says 1st layer hight is as long as print time. 1st layer hight was 0.35 and rest 0.25


btw do i have to enable something in slic3r to show layer hight?

As promised I've just performed a few tests using Slic3r 1.2.6 and my firmware fork. I started off a standard Slic3r configuration, i.e. no configuration template was used. I tested the following circumstances:

1) Absolute E distances. Of course I had to run M82 in my start G-code to utilise those, however no misbehaviour could be observed on the web interface. The raw extruder positions were correct, even after the first few layers (and thus after several G92 E0 calls). This means the filament-based estimation is NOT affected by absolute E distances and/or G92 calls.
2) Different layer heights: I did multiple tests with 0.1mm first layer height and 0.2mm regular layer height and the firmware detected the current layer number as it is supposed to.

I don't know what else I could try to reproduce these faults, but they did not occur on my machine. Proof:



I do understand there is a problem if a really thick first layer (>= 0.5mm) is printed, but as I said I'll address this in my next firmware release. Well, I did a couple of minor changes to the class responsible for collecting print stats (PrintMonitor) in my recent firmware versions, but it's hard to believe the code malfunctions this way without those modifications.

well, I had printed one thing and it worked, and now printing something else and it's not....... both with less than 0.5 initial layers.....

I think the absolute extrusion thing might only happen when the printer is set for relative E, but slic3r is set for absolute E (which should technically never happen, and messes stuff up when it does). but it might be something with DC42's firmware and not yours *shrugs* not a big deal, as I don't use absolute.


I think the issue with the layer times might have something to do with 3d honeycomb, but I don't know for sure, I'll try to trace down the problem a little better since I'm experiencing it.
Darathy what was your slic3r infill type?

Edited 2 time(s). Last edit at 04/18/2015 12:29AM by shadow651.

i mostly use rectilinear. i noticed i had M83 in the start code for relative , do i have to run M82 for absolute to show layer hight?

You only need M82 if you want to use absolute E positions. The layer height should be detected if you copy the entire G-code file to your printer (won't work if you upload it with Pronterface as the firmware doesn't write comments in this case).

If you have a mismatch between the absolute/relative extrusion setting of the printer and the slicing software, incorrect web readout will be the least of your problems! In case you were unaware of the difference, relative extrusion sends the amount of filament to extrude during each move, while absolute sends the accumulated amount. e.g. if there are 3 moves each extruding 5mm of filament, relative mode will command 5, 5 and 5 while absolute mode will command 5, 10 and 15. A 4mm retraction after the last move would be sent as -4 in relative mode, but 11 in absolute mode (15-4). Thus any mode mismatch will result in grossly incorrect extrusion - if the printer is set for relative and Slic3r to absolute the printer will try to extrude way too much after a few moves (to the extent that your extruder will be slipping constantly), while the other way around will see the extruder moving back and forth extruding little or no plastic at all.

The only thing that would affect only the web interface is if the web related code thinks one mode was in use when it is in fact the other mode on both printer and slicer. In that case the print will be OK, but the web interface filament measurement will be wrong. I suppose a possibility of that happening is if the extrusion mode is set in config.g but not in the print file (custom start code) so the web interface does not "see" the printer mode being set, though whether that is a possibility or not depends on where the firmware and web interface picks up the mode. In any case, the extrusion mode should always be set in the print file (by putting it in the custom start code) in order to avoid the possibility of the printer being in the wrong mode for the print. It should also not affect the layer count.

Dave