Commit "Removed toolNumberAdjust" broke M563

gtj0

@dc42:
M563 S"HotEnd" P0 D0 H1 => Error: M563: in file macro: M563: internal error at file ../src/GCodes/GCodeBuffer/BinaryParser.cpp(173)

691e0e9af0090fe708272c48750d5ece833c554c is the first bad commit
commit 691e0e9af0090fe708272c48750d5ece833c554c
Author: David Crocker dcrocker@eschertech.com
Date: Thu Mar 12 14:24:01 2020 +0000

Removed toolNumberAdjust

Also corrected OM property job.file.fileName

dc42

I fixed that on Friday.

gtj0

~~Then you forgot to push the commit or broke it again on Saturday.~~

This is the last commit I have...
commit c3d4e00bfe66e613728d23889b6c2db727b9eb08 (upstream/v3.01-dev, origin/v3.01-dev, v3.01-dev)
Author: David Crocker dcrocker@eschertech.com
Date: Sat Mar 14 17:23:20 2020 +0000

Fixed deploy/retract probe issues when using SBC

Also disabled daemon again when using SBC

EDIT:

This is strange. I had to revert the original commit to get it to work but I just rebuilt with the commit and it still works. I wonder if I'm having issues with the firmware updating successfully.

Sorry about the noise.

dc42

@gtj0 said in Commit "Removed toolNumberAdjust" broke M563:

I wonder if I'm having issues with the firmware updating successfully.

There is a gotcha at present if you use M505 to change to a different sys folder. When uploading new firmware, you must ensure that DWC is showing /sys on the System page, not the subfolder of /sys that you have switched to. Otherwise DWC uploads the new firmware binary into that subfolder instead of /sys. The IAP program always looks for the firmware binary in /sys.

Also bear in mind that if you ever revert to firmware 2.x then you need to update to 3.0 before you can install 3.01.

gtj0

@dc42 I scp it to /opt/dsf/sd/sys/ and run M997 manually.

I was testing another issue where I stopped getting the results of running a bed level and had the same problem. I'd do a git bisect to get the offending commit then rebuild the full v3.01-dev again to make sure and it was still fixed. I'm going to have to pay more attention to what the control server is saying the next time I upload a new binary.

dc42

Do you build your own DSF too? If so then you might want to build it from my branch, until the dev branch catches up with it.

gtj0

I didn't know you had a branch. Good idea. I'll give it a shot. Thanks.

dc42

@gtj0 said in Commit "Removed toolNumberAdjust" broke M563:

I didn't know you had a branch. Good idea. I'll give it a shot. Thanks.

I only created it today. It contains changes needed for compatibility with recent changes to RRF. Caution, I have only just started testing it.

gtj0

I see you also fixed the "System.IO.Pipelines" issue. Took me a while to figure out that one the other day.
Otherwise looks OK.

gtj0

@dc42 Could something is the recent RRF commits have altered how short segments are printed? I've got a 5cm circle that's now seemingly printing in much larger segments that the slicer generated. I'm not sure how that's possible but something's changed and I can't put my finger on it.

dc42

I can't see how that's possible either, unless a DSF plugin combines segments. RRF doesn't combine segments.

gtj0

Yeah I don't get it either. I'll track it down, thanks!