Commit "Removed toolNumberAdjust" broke M563



  • @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

  • administrators

    I fixed that on Friday.



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


  • administrators

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



  • @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.


  • administrators

    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.



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


  • administrators

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



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



  • @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.


  • administrators

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



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


Log in to reply