Weird log files

[kloknibor]

How could it be that the write and lineread are different?

2016-12-06 17:19:53,395 INFO o.a.r.g.GCodeControl [PrintJobProcessorThread-1] Write 0: G1 Z8.486 F46.851

2016-12-06 17:19:53,396 INFO o.a.r.g.GCodeControl [PrintJobProcessorThread-1] lineRead: ok G1 Z-8.341 F180

2016-12-06 17:19:53,397 INFO o.a.r.g.GCodeControl [PrintJobProcessorThread-1] Write 0: G1 Z-8.386 F180

2016-12-06 17:19:53,397 INFO o.a.r.g.GCodeControl [PrintJobProcessorThread-1] lineRead: ok M17

2016-12-06 17:19:53,398 INFO o.a.r.g.GCodeControl [PrintJobProcessorThread-1] Write 0: M17

2016-12-06 17:19:53,499 INFO o.a.r.g.GCodeControl [PrintJobProcessorThread-1] lineRead: ok G1 Z8.486 F46.851

2016-12-06 17:19:53,499 INFO o.a.r.g.GCodeControl [PrintJobProcessorThread-1] Sleep:1500 2016-12-06 17:19:55,000 INFO o.a.r.g.GCodeControl [PrintJobProcessorThread-1] Sleep complete 2016-12-06 17:19:58,726 INFO o.a.r.j.AbstractPrintFileProcessor [PrintJobProcessorThread-1] { "layer": 385, "exposureTime": 25000, "liftDistance": 8.4862068147395, "liftSpeed": 46.85057580347334 , "layerAreaMM2":

[kloknibor]

Seems like it's doing fine from a pc

[WesGilster]

Upload the full log and I'll show you where this happens, I've seen this happen before, and I know what is going on.

Photonic3D will timeout listening for a response(2 minutes or whatever you've set) and then continue on and send another write. However in the mean time, the printer will have sent the response of the prior write. Now, Photonic3D will get the response of the previous read first, even though both responses are waiting in the serial input buffer. Now, both entries are in the buffer, but it only reads the first ok. Now we are out of sync on our reads.

I can probably fix the side effect of the timeout by making sure I empty the inputbuffer on each read instead of simply waiting for the first 'ok'. Technically, I "shouldn't" do that because it's possible to block, and that's not how gcode works but I can make Photonic3D hide that this timeout occurred.

The more curious issue is why we timedout waiting for our original response at all. I would be willing to bet that this is the identical problem to the previous timeout issue we've seen in the past.

[kloknibor]

Hi Wes,

It might be possible that the printer was paused due to removal of the hood. Unfortunately not the whole log of the file is present anymore :( Here you can find it :
LogBundle (13).zip

[WesGilster]

Looks like your right, the log rolled and we missed the event.