Duet Web Control 2.1.2 released

ChrisP

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

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?

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?

dc42

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

ChrisP

@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:~ $

dc42

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.

chrishamm

Thanks for the debug logs. In 1 you can see DCS assigns the correct filament:

[debug] Filament Filamentum PLA Extrafill has been assigned to extruder drive 0

This message is generated when the filament has been updated from the firmware. In two there are a couple of updates for move (where the assigned filament is stored) which is fine, but it does not occur when M702 is finished. So I believe RRF increases the seqs.move field before M702 has fully finished, hence the updated filament never makes it to DCS. So when you restart DCS as per 3, it queries the full object model again before it does anything else, hence the filament is displayed properly again.

The same issue may be present in standalone mode, but in any case I'll have a look at it, try to reproduce, and fix it.

GrodanB

Hi

Do not know or understand if this is related or not to the above problem but I still have problem that loaded filament "jumps" tool when cancelling a print... (commented on it in 2.11 release thread)

This was loaded on T1 and after I cancelled the print it jumped. Normal end of print does this to but when the printer is allowed to finish by it self both tools has no filament loaded.

Since it do not stop me from using my printer (most prints are successes) this is more an annoyance than a stopper but if I can help in pinpointing the problem or verify the fix please just ask.

Thanks for all the good work.

ChrisP

@chrishamm @dc42
Thanks both for looking into this.

I'll have a go at running in standalone later but for now, as per @dc42 original request. Here are two further logs with details of what state things show.

Immediately after a print finished, M701 DWC and filaments.csv all correctly show that filament is loaded (I'm certain that at the start of the print DWC and .csv were wrong, but I didn't see when it changed - presumably during the print, but I don't know why).
I then used the drop down option on DWC to unload the filament and immediately copied the log: 4.txt
At this point DWC incorrectly shows filament loaded, M701 is correct and filaments.csv is incorrect
Since M701 was showing correctly that there was no filament loaded, I used it again with the S parameter to manually load the next filament. Immediately after pressing enter on this in the console i noticed DWC corrected itself to showed no filament loaded checking .csv also showed that had now updated - I did this while waiting for heat up so at this point the new filament hadn't loaded.
After filament load, DWC incorrectly shows filament not loaded, M701 is correct again and .csv is incorrect. HEre is the log immediately after the load: 5.txt
Started the next print with DWC showing no filament loaded, but something clearly knows it is at it used the filaments config file during the print's start code.

Hope this helps. As i said, I'll try standalone later, but if there's anything else you want me to try, just let me know.

garyd9

The issue of fans not working properly in DWC when the fan was configured with an "X" parameter is confirmed resolved with DWC 2.1.2. Thank you.

jay_s_uk

@chrishamm

Simulation times for me aren't getting shown in the jobs list once the simulation is completed. This was on a duet 3 with SBC running RC7 and DSF 1.3.2

I haven't tried on a duet 2 yet.

droftarts

@jay_s_uk Simulation times show for me on Duet 2 Wifi and Duet 2 Maestro (RRF 3.01-RC7, DWC 2.1.2).

Ian

garyd9

@chrishamm

DWC 2.1.2 running in Chrome under Win10 w/ Duet3 (standalone) 3.0.1 RC7:

I'm finding at times that the "last layer time" isn't being updated on the status page under some conditions.

One place I think replicates this is if the computer running DWC goes into standby, and then I wake the machine while I print is in progress. The status page layer times runs "catchup" for a second, but the "last layer time" gets stuck at some time that seems to be similar to the "Job Duration" time.

At that point, the "current layer time" updates as expected, and goes back to zero on layer changes, but the "last layer time" never changes.

The "layer chart" also appears to get out of whack.

(I'm really hoping you can replicate this, because I'm at a loss for words to describe it properly.)

If I refresh the browser window, everything starts working again.

chrishamm

@garyd9 Thanks for reporting this, I suspect one place in DWC2 that could cause this behaviour. Can you please test this new build and let me know if the problem is gone? https://www.dropbox.com/s/znzevo862ny7kr6/DuetWebControl-SD.zip?dl=0

dc42

@jay_s_uk said in Duet Web Control 2.1.2 released:

@chrishamm

Simulation times for me aren't getting shown in the jobs list once the simulation is completed. This was on a duet 3 with SBC running RC7 and DSF 1.3.2

I believe @chrishamm said it's a known issue that DSF doesn't yet write the simulated time to the end of the GCode file.

EDIT: it's listed at https://github.com/chrishamm/DuetSoftwareFramework/tree/dev#known-issues.

jay_s_uk

@dc42

Thanks for that. Didn't realise there was a separate known issues list.
It would be helpful if a central list was maintained.

dc42

@jay_s_uk said in Duet Web Control 2.1.2 released:

@dc42

Thanks for that. Didn't realise there was a separate known issues list.
It would be helpful if a central list was maintained.

Yes it is a bit hard to find. We're going to standardise release documentation so that known issues are always easy to find.

garyd9

@chrishamm said in Duet Web Control 2.1.2 released:

@garyd9 Thanks for reporting this, I suspect one place in DWC2 that could cause this behaviour. Can you please test this new build and let me know if the problem is gone?

Uploaded to my duet3. Will try to keep an eye out for the issue and ping back.

ChrisP

@dc42 said in Duet Web Control 2.1.2 released:

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.

So having just tried this in standalone mode, I cannot find a way to replicate the issue this way.

c310

what is the way to add duet driver temperature to the chart?

this successfully adds MCU

M308 S2 Y"mcu-temp" A"CPU" 				; CPU temp sensor

but this does nothing

M308 S3 Y"drivers" A"drivers" 			; drivers temp sensor

i tried M308 S21 Y"drivers" A"Duet_drv" too with no luck

how to get drivers temperature visible?

Danal

If I recall, TMC drivers don't actually report temperature. They just report OK vs Nearly too hot vs Too Hot. (or conceptually similar).

So they can't be graphed. (usefully)

A Former User

So they can't be graphed. (usefully)

true story, you'll just get 0C, 100C and 150C but it'll be in the extra tab or what its caled.