Posts made by daveidmx

With the RTOS port I assume it's now easier to add additional background tasks to the firmware. When a print starts, could the firmware also start running a simulation in the background, and when complete that simulation time could be fed back to DWC/PanelDue for an additional (and presumably more accurate) print time estimate?

Are there any plans for adding Windows network printer support to Duet RRF? If not, what is the appetite for an outsider to look into writing this? It looks like what's needed is a subset of WSPrint 2.0 support. (Notably: "You do not need to perform SOAP validation and processing. You can instead use string detection and replacement.")

https://docs.microsoft.com/en-us/windows-hardware/drivers/3dprint/enabling-wsprint-on-a-device

If this feature is implemented, it should take into consideration that G1 S2 moves on delta and corexy command individual motors to move, rather than moving in XYZ-space.

<edit>I see this has already been implemented, and there has already been a bug fix for this.</edit>

@dc42 Confirmed.

I scripted up a test print that linearly increases the acceleration with Z-height from "0" (60) up to 9000. Ringing indeed becomes prominent as the acceleration time falls down towards and below the ringing period.

My default profile has bulging corners but almost no visible ringing, but I'm happy to run some tests for you with more aggressive settings. (Looking forward to the new motion planner!)

Can you give me a table of test values you'd like to see? For reference, I'm on a CoreXY with a default profile of 180 jerk, 3600 accel, 60mm/s external perimeters. With these values, I have no observable ringing on the X-axis, and (if I squint hard and use a flashlight) 0.6mm wavelength on the Y for an 0.01s period, assuming it was up to speed at that point.

Yep, that's the behavior I see. I just didn't expect the tpost file to be required, based on the docs. Cheers!

True about the listed M116--I wasn't expecting that one to wait, I was just including it in the quoted command sequence for completeness. What I was expecting was for the T0 command to perform an implicit M116 based on this:

T Select Tool

The sequence followed is:

1. Set the current tool to its standby temperatures specified by G10 (see above),
2. Set the new tool to its operating temperatures specified by G10 and wait for all temperatures to stabilise,
3. Apply any X, Y, Z offset for the new tool specified by G10,
4. Use the new tool.

Running 2.0, I'm configuring a new profile for S3D. I've modified the S3D "firmware configuration" to use G10 and M116 rather than M104 and M109 for setting tool temperatures, so it doesn't stomp over my "standby" temperatures. (Side note: could M104 and M109 be made to control only the active temperature and not the standby temperature?)

According to the docs, T0 should wait for temperatures to stabilize since I do not have tfree/tpre/tpost scripts configured, but this code sequence does not wait, and instead charges on printing cold:

T-1
G10 P0 S210
M116 P0
T0

I'm able to work around this by adding a tpost0.g containing an M116 P0.

Is this user error, doc error, or a bug?

On 2.0RC6, DWC 1.21.1, I'm seeing the same thing as @zerspaner_gerd . When filament is loaded, I can click "Tool 0" to get a dropdown and select "Unload Filament". Once that's processed and the filament is unloaded, the menu is gone. If I click "Tool 0" at that time, it just cycles Active/Standby/Off.

M701 S"..."from the gcode console works fine, and once the new filament is loaded the menu re-appears.

@dc42 There were ~70. Half of those are test macros and related subroutines that maybe shouldn't be in there. (The entry-point macros are in /macros but I didn't want the subroutines to show up on the "macros" DWC UI menu.) The other half are config.g, but factored apart such that reusable parameters were in one place.

https://github.com/daveidmx/VORON/tree/feature/config/Firmware/DuetWifi/V2/daveidmx

For example, here are my homex.g and homeall.g, written such that the actual Z-hop moves and X/Y/Z probe moves are in their own files. They are re-usable and only need to be changed in one place.

; homex.g
M98 P"homing_zhop_up.g"
M98 P"homing_probe_x.g"
M98 P"homing_zhop_down.g"

; homeall.g is a slightly optimized XYZ homing script that probes X, Y, and Z together without an intervening Z-hop between each axis
M98 P"homing_zhop_up.g"
M98 P"homing_probe_x.g"
M98 P"homing_probe_y.g"
M98 P"homing_probe_z.g"
M98 P"moveto_center_xyz.g"

Maybe these should be shipped off to /macros?

After reorganizing my /sys files into subfolders (to get down below the limit so they call appear in DWC) I noticed that subfolders of /sys don't appear on DWC either. Would that be a DWC feature request, or is there firmware-side support needed too?

Is there a different way I should be doing this to maintain DWC editability of all my config files? (I can move some of them to /macros, but it wouldn't make sense for them ever to show up on the UI to be called individually. Is that what's expected, though?)

I did a full, fresh format, copied all the files back, and booted up. DWC still shows some files as missing. (Alphabetically the last ones, now, more or less.)

However I was able to do an "M98" to run one of the macros that does not appear in DWC, and that macro executed successfully. So it would seem that the part of the system does in fact know about and can read those "missing" files just fine!

I suspect dc42's comment here explains some of the symptoms I was seeing:
https://forum.duet3d.com/topic/5394/new-firmware-2-0rc5-available/30

My remaining concern is that the files were initially missing in Windows too, before running chkdsk. Is it possible that the reduced buffer sizes might cause directories to get truncated when they're written out?

I will pull up my pre-repaired image to make sure I'm not misremembering.

Pulled the SD card and put it in a reader. Confirmed that the files don't appear under Windows either.

I ran Windows chkdsk on the volume. Afterwards I did a comparison between my backup and the recovered volume, and it looks like chkdsk was able to recover everything. So it seems like filesystem corruption for sure, and of a recoverable variety. Hopefully that will give you an idea of what's going on.

Let me know if you want this disk image and I'll PM you a link.

PS C:\Users\David> chkdsk d:
The type of the file system is FAT32.
Volume Serial Number is 13A9-FA3E
Windows is verifying files and folders...
File and folder verification is complete.
Windows found errors on the disk, but will not fix them
because disk checking was run without the /F (fix) parameter.
Convert lost chains to files (Y/N)?

I updated from 1.21 to 2.0RC5, and when the device rebooted it looks like I'm missing a bunch of files from /sys. According to my backup, I had 72 files beforehand, and there are 48 now.

Is there any information I can provide now after the fact to investigate?

<edit>
I think my issue is at least partially (if not fully) explained by this comment:
https://forum.duet3d.com/topic/5394/new-firmware-2-0rc5-available/30
There's one remaining concern though. (See below.)
</edit>

Sounds good. Thanks for looking in to this!

I've done a few prints today without seeing the symptoms. Watching the console for a while showed connections on socket 0 and 1 after a few hours (even returning to 0 after being on 1 for a while) where yesterday this would climb incrementally up to 7 and then fail. Based on those two things, I'd tentatively say this seems to have resolved the issue.

Installed. Will report back.