Duet Web Control 2.1.2 released


  • administrators

    I'm happy to announce the release of DWC 2.1.2. It is now available here: https://github.com/chrishamm/DuetWebControl/releases/tag/2.1.2 It is compatible with the latest RRF 3.x(-RC) versions and the latest DSF version 1.3.2. It should be compatible with RRF 2.x as well but I have not tested this in depth yet.

    Please use this thread to report issues or use my GitHub page if you encounter any problems.



  • Could be beneficial to have some consistency between RRF and DWC/DSF with respect to versioning and stable/unstable. 2.1.2 looks like a stable release.

    I.e RRF 3.01-RC7 is unstable, RRF 3.01 will be stable but DWC 2.1.2 and 1.3.2 could be either or both.

    Coordinating the announcements pkg.duet3d.com would also be a good thing, possibly clearly indicating stable/unstable to avoid having users eagerly waiting for new versions struggling to find the update when it comes to the Duet3+SBC situation.



  • found an issue in that I have updated my D3 with SBC to rc7 and DWC 2.1.2 the M122 gives

    5a0f5791-bd51-4348-a59d-bac9e027ea58-image.png

    But DWC Shows this
    1b7977ea-e908-4816-b5b6-1c9232483787-image.png

    Obviously they are out of sync slightly also when do you expect to push DSF 1.3.2.

    Doug


  • administrators

    @bearer said in Duet Web Control 2.1.2 released:

    Could be beneficial to have some consistency between RRF and DWC/DSF with respect to versioning and stable/unstable. 2.1.2 looks like a stable release.

    They are all independent projects which interact with each other, hence the release notes saying which version works with what. The feature sets of the different projects vary so IMO it would not make much sense to release them all with the same version numbers.

    @bearer said in Duet Web Control 2.1.2 released:

    Coordinating the announcements pkg.duet3d.com would also be a good thing, possibly clearly indicating stable/unstable to avoid having users eagerly waiting for new versions struggling to find the update when it comes to the Duet3+SBC situation.

    There are already two independent package feeds (stable vs unstable) with a meta package for each bundle (e.g. DSF 1.2.x + DWC 2.0.7 + RRF 3.0 on the stable feed compared to DSF 1.3.2 + DWC 2.1.2 + RRF 3.01-RC7 on the unstable feed). Hence there is no need to perform manual updates, it can be all done by running only apt-get.

    I hope to release 1.3.2 on the stable package feed when I've got some more feedback.


  • administrators

    @Dougal1957 I published DSF 1.3.2 just a minute ago so you probably haven't got my latest updates yet. Also there is no need to upgrade RRF manually on the SBC, it's done automatically by the RRF package.



  • @chrishamm said in Duet Web Control 2.1.2 released:

    it's done automatically by the RRF package

    when DCS works;)



  • @chrishamm it didn't prob because I am not getting 1.3.2 yet i will try again



  • @Dougal1957 said in Duet Web Control 2.1.2 released:

    it didn't prob because I am not getting 1.3.2 yet i will try again

    which is why it would be better to delay the announcement until the package feeds were also updated



  • All working as expected now maybe worth pushing the updates prior to announcing them?



  • @bearer our comments crossed



  • @chrishamm said in Duet Web Control 2.1.2 released:

    IMO it would not make much sense to release them all with the same version numbers.

    absolutely agree; it would just make life easier if you could look at the version number and tell if its a stable or unstable version.

    @chrishamm said in Duet Web Control 2.1.2 released:

    Hence there is no need to perform manual updates, it can be all done by running only apt-get.

    with the odd exception I'd agree, but when you announce the update before its on the package feed you'll get the situation above. especially when there is a small but angry mob awaiting a new version it seems unnecessary.


  • administrators

    @bearer @Dougal1957 You guys are just too fast for me 😄 The package server needs approx. 1 minute to regenerate the package lists and I guess you just beat it to that. I'll try to slow down the announcement next time!

    PS: I understand the argument about the version numbers in regards of stable/unstable but that's why I added unstable to the title. I don't want to upset users expecting to have a working machine by releasing fresh code immediately on the stable feed.



  • @chrishamm said in Duet Web Control 2.1.2 released:

    I'll try to slow down the announcement next time!

    ❤



  • @chrishamm
    Just updated to RC7, DWC 2.12 and DSF 1.3.2 and am still having issues with using the filaments functions. I've just loaded a filament and it doesn't show on DWC. Tried a hard refresh (Ctrl-F5) - still no change. Trying M701 in the console view shows the filament correctly.
    2020-04-14.png


  • administrators

    @ChrisP Odd, it's working OK on my setup:

    11120e94-3259-45e2-874f-baefc6bdc172-image.png

    Can you share your filament macros?



  • @chrishamm said in Duet Web Control 2.1.2 released:

    @ChrisP Odd, it's working OK on my setup:

    11120e94-3259-45e2-874f-baefc6bdc172-image.png

    Can you share your filament macros?

    Hmm, interesting! Yeh sure...

    Here's load.g:

    M98 P"0:/macros/Filaments/PLA/Load"
    

    And here's the contents of my generic PLA load that the above calls:

    ; Move head
    G90			; absolute positioning
    G28
    G1 X60 Y60 Z100 F9000
    
    ; Display message
    M291 P"Please wait while the nozzle is being heated up..." R"Loading PLA" S1 ;T5
    
    G10 S200		; Set current tool temperature to 200C
    M116			; Wait for the temperatures to be reached
    M292 P0			; cancel message
    
    ; Display new message
    ;M291 P"Ready to feed filament. Insert filament and press Ok." R"Loading PLA" S2
    M291 P"Ready to feed filament. Insert filament and press function button." R"Loading PLA" S1
    M577 P1 S0		; pause and wait for endstop trigger
    M400			; wait for all moves to finish
    M577 P1 S0		; pause and wait for endstop trigger
    M400			; wait for all moves to finish
    M292 P0			; cancel message
    
    M83			; relative e steps
    G92 E0			; reset e steps
    G1 E10 F300		; Feed 10 mm of filament at 5 mm/s
    G1 E475 F3600		; Feed 475 mm of filament at 60 mm/s
    G1 E20 F300		; Feed 20mm of filament at 5 mm/s
    G1 E10 F120		; Feed 10mm of filament at 2 mm/s
    
    G4 P1000		; Wait one second
    G1 E-10 F1800		; Retract 10mm of filament at 30 mm/s
    
    M400			; Wait for moves to complete
    
    M292			; Hide the message
    
    G10 S0			; Turn the heater off again
    G92 E0			; Reset the extruder count
    M84 E0			; Turn extruder motors off
    G28
    ;T-1			; deselect tool
    

    Note that the T-1 at the end is commented out and has been for a long time - it was from some previous experiment as I was looking for a way to de-select the tool after loading. I've left it in just in case its somehow caused an error - the above is the exact script that was run.

    I'll admit that I haven't power cycled since updating... but I wouldn't have thought that should be required, really.



  • So, the first print with new FW DSF etc has just finished fine. Selected the tool and issued M702 to unload and immediately after I hit enter, the filament suddenly appeared on the tool. Whats even more weird, is that after the unload had finished the filament was still listed on the tool and M701 says there no filament in the selected tool!


  • administrators

    @ChrisP said in Duet Web Control 2.1.2 released:

    So, the first print with new FW DSF etc has just finished fine. Selected the tool and issued M702 to unload and immediately after I hit enter, the filament suddenly appeared on the tool. Whats even more weird, is that after the unload had finished the filament was still listed on the tool and M701 says there no filament in the selected tool!

    Please double-check using M115 that you really are running RRF 3.01-RC7, because we did a fix in RC7 for something very similar.



  • @dc42 said in Duet Web Control 2.1.2 released:

    Please double-check using M115 that you really are running RRF 3.01-RC7, because we did a fix in RC7 for something very similar.

    No problem - see screenshots below. Whether it makes any difference, I'm using this with a Duet3 + SBC, so I assume its more a DSF issue for @chrishamm than RRF?

    There's definitely still an issue... after my post last night where I unloaded the filament and M701 confirmed this but DWC showed filament present, I let the head cool and turned it all off for the night.

    This morning, I turned it on to get you the requested info and DWC still shows filament loaded. As seen in the screenshot, I then did an M115 to confirm the FW version, set the active temperature to 0, selected the tool then an M701. The screenshot below was taken immediately after. As you can see, both DWC and M701 still show filament loaded despite the last thing I did last night was to unload the filament.
    2020-04-15.png

    Next, I deleted the contents of my unload script so that I could perform the unload without actualy heating or moving etc, and issued M702 to unload (this took 3 attempts?). At this point, both DWC and M701 confirm no filament - great!
    2020-04-15 (1).png

    However, just for fun, I then power cycled the whole machine and and tried to load filament. While M701 confirmed that there's filament loaded, DWC still doesn't.
    2020-04-15 (2).png

    After waiting for the head to cool, I power cycle and again and despite filament being loaded (and M701 confirming this previously), neither DWC or M701 show this now.
    2020-04-15 (3).png

    Indeed, the contents of filament.csv confirm this. Its date-stamped with the unload at 08:47 rather than the load I did at 08:51 (which isn't shown in the previous colsole log as I used the drop-down on DWC).
    2020-04-15 (4).png

    To confirm, the issue I had previously with RC6/ DSF 1.3.1 was simply that neither DWC or M701 remembered what filament was loaded after powerup, irrespective of the contents of filaments.csv. After powerup it was fine.


  • administrators

    @ChrisP Can you run DCS in debug mode, try to load/unload the filament and post the console output here? It really sounds like DSF does not get an update about the new filament even though we thought we had fixed this in RC7. In fact I haven't been able to reproduce this issue since then.


  • administrators

    I think there are two different issues here:

    1. Filament status (as reported by M701) not always being saved during a power cycle. The status is saved to SD card. My guess is that the data wasn't flushed to SD card before you powered down the Pi. One for @chrishamm I think - perhaps DSF needs to ask Linux to flush the write cache after writing the filament data? If instead of just powering off you tell Linux to shut down, does the problem still happen?
    2. DWC not always agreeing with M701 about whether filament is loaded. This may be caused by RRF not always updating the relevant sequence number after loading/unloading filament (or updating it too early in the sequence), so that DWC doesn't know that it has changed. If you can pin down the circumstances under which this happens, I will look into it.


  • @chrishamm said in Duet Web Control 2.1.2 released:

    @ChrisP Can you run DCS in debug mode, try to load/unload the filament and post the console output here? It really sounds like DSF does not get an update about the new filament even though we thought we had fixed this in RC7. In fact I haven't been able to reproduce this issue since then.

    Sure. I did in fact start DSC in debug mode and did a new unload/load and didn't notice anything weird. Unfortunately, I needed to get a print done so I started that... I'll post an pair of unload/load logs after that. Is there any particular sequence you're interested in ie. after a power up or immediately one after another?

    @dc42 said in Duet Web Control 2.1.2 released:

    I think there are two different issues here:

    1. Filament status (as reported by M701) not always being saved during a power cycle. The status is saved to SD card. My guess is that the data wasn't flushed to SD card before you powered down the Pi. One for @chrishamm I think - perhaps DSF needs to ask Linux to flush the write cache after writing the filament data? If instead of just powering off you tell Linux to shut down, does the problem still happen?
    2. DWC not always agreeing with M701 about whether filament is loaded. This may be caused by RRF not always updating the relevant sequence number after loading/unloading filament (or updating it too early in the sequence), so that DWC doesn't know that it has changed. If you can pin down the circumstances under which this happens, I will look into it.

    Yeh, this seems logical - particularly with Linux perhaps not flushing the file.
    Is there a way that I can check #2? Does M701 pull from the OM in DCS and DWC from RRF then?


  • administrators

    @ChrisP said in Duet Web Control 2.1.2 released:

    Is there a way that I can check #2? Does M701 pull from the OM in DCS and DWC from RRF then?

    I assume DCS passes M701 to RRF on the Duet, and RRF will report the filament status based on its own variables.

    Starting from a situation in which M701 and DWC agree on the filament status, are you able to find a command or sequence of commands that causes them to disagree, without power cycling?



  • @dc42 said in Duet Web Control 2.1.2 released:

    Starting from a situation in which M701 and DWC agree on the filament status, are you able to find a command or sequence of commands that causes them to disagree, without power cycling?

    Yes. Indeed, I just managed to do that when doing the unload/load that @chrishamm asked for logs for. Hopefully the following will answer both questions. I've attached as txt files as the forum complains the post is too long otherwise, even if split in two.

    Firstly, immediately after my print finished, I killed DCS on the pi and started a debug session on a connection through putty. Here's the output after that starts - nothing weird here, I think:
    1.txt

    Next, I unloaded the filament using the drop-down on DWC. Here's whats added to the log after that completed:
    2.txt

    At this point, DWC still showed the filament as loaded. Running M701 leaves this in the log:

    [debug] IPC#16: Got new UNIX connection, checking mode...
    [debug] IPC#16: Command processor added
    [debug] IPC#16: Received command SimpleCode
    [debug] Waiting for execution of M701
    [debug] Processing M701
    [debug] HTTP: Sent M701, remaining space 1512, needed 24
    [debug] Completed M701 => No filament loaded in the selected tool
    [debug] IPC#16: Connection closed
    

    I then reset just DCS and refreshed the web page. DWC still showed the filament loaded but M701 does again too, I checked filaments.csv and this also still has the filament there and loaded - so this is clearly the first issue that filaments.csv isn't being updated after a load/unload.
    Just to double check, I ran another unload and sure enough, filaments.csv and DWC still show filament loaded, M701 doesn't. I then manually removed the filament from filaments.csv and reset DCS and this time neither DWC or M701 show the filament loaded.

    Finally, here's what the log shows after a reset of DCS and an attempt to load:
    3.txt

    At this point, M701 shows the filament as loaded, but DWC and filaments.csv doesn't.

    So to answer @dc42 question, yes - from a fresh start, either load or unload a filament and DWC always seems to disagree with M701. For completeness, here's a list of what version I have of everything - I'm assuming they're all up to date as this is what I was left with after updating yesterday evening:

    pi@starttex:~ $ apt list 2>/dev/null | grep duet
    duetcontrolserver/unstable,now 1.3.2 armhf [installed,automatic]
    duetruntime/unstable,now 1.3.2 armhf [installed,automatic]
    duetsd/unstable,now 1.0.6 all [installed,automatic]
    duetsoftwareframework/unstable,now 1.3.2 armhf [installed]
    duettools/unstable,now 1.3.2 armhf [installed,automatic]
    duetwebcontrol/unstable,now 2.1.2 all [installed,automatic]
    duetwebserver/unstable,now 1.3.1 armhf [installed,automatic]
    pi@starttex:~ $
    

  • administrators

    Thanks. As you have been resetting DCS in this sequence, I'm not clear whether this is an issue with RRF after all. You could try to replicate the problem in standalone mode if you wish; otherwise I'll wait to see what @chrishamm says.


Log in to reply