Auto Bed Compensation Javascript Error

esserr

Also updated to firmware 2.02 with same issue...very strange

dc42

The M374 command won't do anything useful there, because it's only mesh bed probing (G29) that generates a height map that can be saved to SD card. But putting M374 there shouldn't cause a disconnection.

Please post your config.g file so that I can try to replicate the issue.

esserr

0_1541023774302_config.g

Oh I see, I guess what I am trying to do is save the height map once then reference it on startup so I do not have to probe every time because I have solid bed mounts and no z-probe at this time. I plan on adding the z-probe soon. Should I just run the G29 once and use the results instead of the 5 probe points generated from the configurator? Would I delete these G30 probe points from the bed.g file?

Thank you again

dc42

Yes, use G29 instead. If 5-point probing was good enough for you before, then you should find a 3 x 3 mesh sufficient.

I'll try to replicate the problem tomorrow.

richardmckenna

@dc42 did you manage to replicate this. I now see this same error and no height map file being saved after upgrading. I'm using G29 in my bed file. and see it in both Chrome and Edge.

A JavaScript error has occurred so the web interface has closed the connection to your board. It is recommended to reload the web interface now. If this happens again, please contact the author and share this error message:

Version: 1.22.4-b1
Message: JSON.parse Error: Invalid character at position:107
URL: http://10.0.0.10/js/dwc.js
Line: 1065:9
Error object: {}

Software Information
Firmware Name: RepRapFirmware for Duet 2 WiFi/Ethernet
Firmware Electronics: Duet WiFi 1.0 or 1.01
Firmware Version: 2.02RC3(RTOS) (2018-10-17b2)
WiFi Server Version: 1.21
Web Interface Version: 1.22.4-b1

I've attached my bed.g and config.g.

Any thoughts?

dc42

I was unable to replicate it.

Please can you update DWC to the 1.22.4 release and check whether it still occurs. If it does, then it would be most helpful if you can get a Wireshark trace of the transaction that produces the error message. You can either save the trace and make the .pcap file available to me, or search for the faulty transaction. It will be an HTTP 200 OK response with the data type reported as JSON, but when you expand it, instead of displaying the JSON object it will offer "Line based text data". That's the data I need; so right click on it, select Copy, and then paste it into a post.

richardmckenna

@dc42 yes of course I will get that this evening.

richardmckenna

@dc42 ok I'm getting this response first and then following that I get the disconnect response. I assume because it's not catching the error.

GET /rr_reply HTTP/1.1
Host: 10.0.0.10
Connection: keep-alive
Accept: text/html, */*; q=0.01
X-Requested-With: XMLHttpRequest
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/70.0.3538.77 Safari/537.36
Referer: http://10.0.0.10/
Accept-Encoding: gzip, deflate
Accept-Language: en-GB,en;q=0.9,es;q=0.8

HTTP/1.1 200 OK
Cache-Control: no-cache, no-store, must-revalidate
Pragma: no-cache
Expires: 0
Access-Control-Allow-Origin: *
Content-Type: text/plain
Content-Length: 183
Connection: close

Bed equation fits points [15.0, 15.0, 0.547] [15.0, 180.0, 0.097] [170.0, 180.0, -0.255] [170.0, 15.0, 0.102] [80.0, 97.5, 0.102]
Error: G29: Height map file heightmap.csv not found

GET /rr_disconnect HTTP/1.1
Host: 10.0.0.10
Connection: keep-alive
Accept: application/json, text/javascript, */*; q=0.01
X-Requested-With: XMLHttpRequest
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/70.0.3538.77 Safari/537.36
Referer: http://10.0.0.10/
Accept-Encoding: gzip, deflate
Accept-Language: en-GB,en;q=0.9,es;q=0.8

HTTP/1.1 200 OK
Cache-Control: no-cache, no-store, must-revalidate
Pragma: no-cache
Expires: 0
Access-Control-Allow-Origin: *
Content-Type: application/json
Content-Length: 9
Connection: close

{"err":0}

Is this because I am running G29 S1 instead of G29 S0? What should be used to probe the bed, save the file and activate bed compensation or if file exists load the file?

This is what the configuration tool gave me.

M561 ; clear any bed transform
G28  ; home all axes
; Probe the bed at 5 points
G30 P0 X15 Y15 H0 Z-99999
G30 P1 X15 Y180 H0 Z-99999
G30 P2 X170 Y180 H0 Z-99999
G30 P3 X170 Y15 H0 Z-99999
G30 P4 X80 Y97.5 H0 Z-99999 S

G29 S1 ; Detailed Z-Probe. Load the height map from file and activate bed compensation.

dc42

Those are not the responses that cause the error message from DWC.

richardmckenna

@dc42 The only calls I can see before that were to GET /rr_status?type=2 HTTP/1.1 and GET /rr_status?type=1 HTTP/1.1. Here is the network trace the printer is at 10.0.0.10 and the PC is at 10.0.0.187.

My previous post is after I changed from DWC 1.22.4-b1 from your Git repo to 1.22.4 from Chris Hamm https://github.com/chrishamm/DuetWebControl. I was already running 1.22.4-b1 when you asked me to upgrade to 1.22.4 and Chris's version was the only one I could find that was specifically 1.22.4. So I don't know if there are any differences.

So I tried some other stuff last night if I run "Perform automatic mesh compensation (G29)" from the drop down menu. It proceeds to probe the bed in 20mm grid completes, saves the heightmap.csv and displays it.

If I then run Auto Bed Compensation it probes the bed at the 5 points defined in the map.g file then displays the height map.

So to me that seems like if there isn't an existing heightmap.csv and G29 S1 is run, it throws the error on the GET /rr_reply call. Then immediately after that GET /rr_disconnect is called.

Thanks

dc42

Thanks for providing the network trace. I was expecting to see an invalid JSON response, but there isn't one. So I suspect it is a DWC issue, not a firmware issue. I have asked chrishamm to take a look.

richardmckenna

@dc42 that’s great thanks!

chrishamm

Thank you very much for the Wireshark dump, it makes things easier to diagnose.

I tried out the same bed probing macro that you used and it worked without problems for me too, but once I copied the response from rr_reply and reran the corresponding parsing code I was able to figure out why it fails for you. Apparently DWC receives a multi-line string after the G32 call that it cannot deal with, so I need to work-around this.

I'll come up with a fix soon. In the meantime I suggest you remove the G29 S1 call from your bed.g - in fact I don't quite understand why you use it at all. You can only use bed compensation -or- mesh compensation, but not both at the same time AFAIK.

richardmckenna

@chrishamm cool thanks for looking at it.

G29 S1 is in the bed.g file as the RepRap Configuration Tool put it there