Problem with JSON reply (tested DC42 1.09a/b)

I'm getting a pop up error from the web front end (latest from DC42 git repository) while printing:

"An AJAX error was reported, so the current session has been terminated.
Please check if your printer is still on and try to connect again.
Error reason: SyntaxError: Unexpected token i"

I've captured the JSON reply to the rr_status request with wireshark and the problem appears to be with the filament variable (near end of string) being "inf" rather than a number.

JSON string...

{"status":"P","coords":{"axesHomed":[1,1,1],"extr":[43.2],"xyz":[201.82,87.34,6.90]},"currentTool":1,"params":{"atxPower":1,"fanPercent":100.00,"speedFactor":100.00,"extrFactors":[100.00]},"seq":6,"sensors":{"probeValue":0,"fanRPM":0},"temps":{"bed":{"current":-11.7,"active":-273.1,"state":0},"heads":{"current":[210.0],"active":[210.0],"standby":[0.0],"state":[2]}},"time":1053.4,"currentLayer":23,"currentLayerTime":32.2,"extrRaw":[43.2],"fractionPrinted":67.8,"firstLayerDuration":68.9,"firstLayerHeight":0.30,"printDuration":1037.6,"warmUpDuration":180.5,"timesLeft":{"file":321.8,"filament":inf,"layer":364.4}}

Error message from [www.jsoneditoronline.org]

Error: Parse error on line 1:
...e":321.8,"filament":inf,"layer":364.4}}
-----------------------^
Expecting 'STRING', 'NUMBER', 'NULL', 'TRUE', 'FALSE', '{', '[', got 'undefined'

Any ideas what I might have misconfigured? It's running on a cartesian printer with a DC42 mini Z sensor not an Ormerod if that makes any difference.

Thanks,
Mark

Edited 1 time(s). Last edit at 06/17/2015 08:48AM by FatFreddie.

Hi Mark, I'm guessing that "inf" means infinity. I'll take a look at the firmware and see if I can work out what could be generating that, and how to fix it.

---

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
Hi Mark, I'm guessing that "inf" means infinity. I'll take a look at the firmware and see if I can work out what could be generating that, and how to fix it.

There was a problem in my PrintMonitor class, however a fix for this issue (in fact a possible division by zero) is included in my 1.09a firmware release.

Quote
zombiepantslol

Quote
dc42
Hi Mark, I'm guessing that "inf" means infinity. I'll take a look at the firmware and see if I can work out what could be generating that, and how to fix it.

There was a problem in my PrintMonitor class, however a fix for this issue (in fact a possible division by zero) is included in my 1.09a firmware release.

Thanks, Christian. My 1.09b release includes the PrintMonitor changes from your 1.09a release. So when Mark said he was using "latest from github", perhaps he meant 1.09a. Mark, can you confirm which version you are using?

Edited 1 time(s). Last edit at 06/17/2015 12:45PM 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].

I've just looked at the code, and although I have included zpl's change, I think there are a couple of other possibilities for division by zero in the filament estimation. If Mark confirms that the problem definitely occurs in 1.09b, then I'll make a fixed version available.

---

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].

Hi David,

Yes, it seems (though it's hard to tell for sure) to be a little less frequent in 1.09b but it still happens after a few minutes of printing.

Thanks,
Mark

Quote
FatFreddie
Hi David,

Yes, it seems (though it's hard to tell for sure) to be a little less frequent in 1.09b but it still happens after a few minutes of printing.

Thanks,
Mark

I've put a new build at [dl.dropboxusercontent.com]. I haven't tested it yet, so try it at your own risk! The only intentional changes are to avoid two possible divide-by-zero issues that I think that area of the code had.

PS - are you by any chance using absolute instead of relative extruder movement?

Edited 1 time(s). Last edit at 06/17/2015 06:11PM 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].

Hi David,

Your changes fixed the JSON problem - thank you :-)

I am (was) using absolute extrusion - it's the default for Slic3r and what I've been using on my Mendel.

The filament usage based time calcs still don't work (stays at n/a) - looking at the generated G code, it resets the extruder using G92 E0 before each layer change which is what's presumably confusing it.

I tried the test print again using relative extrusion and everything worked fine so I'll use that in future.

I have to say that I'm impressed with how it all works, a sound original concept and great development by you and ZPL. It makes using the Melzi w LCD setup on my Mendel feel very low tech :-)

Thanks,
Mark

Hi Mark,

Relative extrusion is recommended for RepRapFirmware. My fork doesn't currently handle printing time estimates from filament consumption when you use absolute extrusion, but I think zpl's fork and the official 1.09 version may do.

---

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].

Appears to work OK Fore me FW: 1.09b, Web:1.06. Also the Ext-ruder Drive Status Readout is Fixed. in the FW: 1.09a is was not working. Good Job

Quote
FatFreddie
Hi David,

Your changes fixed the JSON problem - thank you :-)

I am (was) using absolute extrusion - it's the default for Slic3r and what I've been using on my Mendel.

The filament usage based time calcs still don't work (stays at n/a) - looking at the generated G code, it resets the extruder using G92 E0 before each layer change which is what's presumably confusing it.

I'm glad to hear the changes worked for you.

What I'd really like to do is to run our program verification tools on the firmware source. Then I could be sure that similar problems won't occur in future. Sadly, the source code is not up to the standard needed to run the tools. I am only one of several contributors to the firmware, so bringing the source code up to the required standard isn't really an option.

I'll look at making the filament estimation work with absolute extrusion in my next release; but unless you use Cura (which only supports absolute extrusion), I suggest you switch to relative extrusion.

---

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].

Hello,

Any chance you could post this fix again? I have the exact same issue on this firmware!

Quote
grant.baxter
Hello,

Any chance you could post this fix again? I have the exact same issue on this firmware!

Grant, please can you confirm:

1. Which firmware you are referring to: 1.09x-dc42, or another version?

2. Which of the three time estimates has the dud data.

3. Is the dud data "NaN" or "INF" ?

There have been two different problems of this nature in previous firmware versions, so I need to know which one has re-surfaced..

---

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].