Stable firmware 2.01 (Duet 2) and 1.22 (Duet 06/085) released

whosrdaddy

Thanks David, I understand now. It's not a big issue anyway, since I am currently printing non stop, I will try your advice later

Qdeathstar

I consider this to be a bug:

Now that you can upload g-code while you print, if you upload a file with the same name as the file you are printing, the print will switch from the file you were printing to the new file.

dc42

@qdeathstar said in Stable firmware 2.01 (Duet 2) and 1.22 (Duet 06/085) released:

I consider this to be a bug:

Now that you can upload g-code while you print, if you upload a file with the same name as the file you are printing, the print will switch from the file you were printing to the new file.

I'll add this to the list of things to fix. The firmware already checks for trying to delete a file while it is being printed.

EDIT: I just found it was already on the list, but low priority.

dragonn

Maybe add a warning/question? This helped my last time when I need to add a pause command into a running print.

wilriker

@dc42 said in Stable firmware 2.01 (Duet 2) and 1.22 (Duet 06/085) released:

The firmware has has to seek backwards through the file from the end to find the last Z move. With large files this can get very slow because of the way the FAT file system works, especially if the SD card is formatted using a small cluster size. So to prevent DWC timing out, recent firmware versions apply a time limit to this operation.

To speed up access and minimise the chance of reaching the time limit, format the SD card using the largest cluster size you can, which is 64kb for 4Mb cards and smaller (FAT16 format), and 32kb for larger cards (FAT32 format). Send M39 to find the current cluster size.

I just ran M39 and got

SD card in slot 0: capacity 3.98Gb, free space 3.78Gb, speed 20.00MBytes/sec, cluster size 64kb

so my card is already formatted to the largest possible cluster size (it came this way I never touched it) and still I could reproduce @whosrdaddy's issue. Intersting why it works for @Dougal1957 with an even larger file though.

Just an idea: @Dougal1957 do you still have the stock SD card or do you maybe use a faster one? Also @dc42 do you know more details on the speed of the stock SD card?

Dougal1957

@wilriker Prob not I go thru cards quite a lot (take them out put them down and lose them lol) M39 gives

SD card in slot 0: capacity 15.93Gb, free space 15.18Gb, speed 20.00MBytes/sec, cluster size 32kb

appjaws

@dc42 said in Stable firmware 2.01 (Duet 2) and 1.22 (Duet 06/085) released:

The firmware has has to seek backwards through the file from the end to find the last Z move. With large files this can get very slow because of the way the FAT file system works, especially if the SD card is formatted using a small cluster size. So to prevent DWC timing out, recent firmware versions apply a time limit to this operation.

When uploading a laser file, which could be in excess of 30MB there is a large delay. I keep getting "could not fine end of file error".
For Laser files, the Object Height, Layer Height and Filament Usage are not required or recorded in the file, so the firmware will ever obtain the data.

dc42

@appjaws, what is the exact message you are getting, and when?

appjaws

DWC just sits after the file has been uploaded until it fills each box with N/A.
The firmware is searching for this data when it doesn't need to for laser files.
The "could not find end of file error" appears randomly during printing.
I will see if I can nail the exact conditions later

Edit. The "could not find end of file error" appears when the print starts

appjaws

This is a screen shot at the end of the Laser print.

=== Diagnostics ===
RepRapFirmware for Duet version 1.22 running on Duet 0.6
Used output buffers: 3 of 16 (9 max)
=== System ===
Static ram: 44652
Dynamic ram: 41436 of which 4024 recycled
Stack ram used: 136 current, 6084 maximum
Never used ram: 2108
=== Platform ===
Last reset 03:27:56 ago, cause: power up
Last software reset at 2018-08-03 12:50, reason: User, spinning module GCodes, available RAM 1836 bytes (slot 2)
Software reset code 0x0003 HFSR 0x00000000 CFSR 0x00000000 ICSR 0x00000000 BFAR 0xe000ed38 SP 0xffffffff
Error status: 0
Free file entries: 10
SD card 0 detected, interface speed: 21.0MBytes/sec
SD card longest block write time: 1071.5ms, max retries 0
MCU temperature: min 42.0, current 45.6, max 50.1
Date/time: 2018-08-03 16:48:52
Slowest loop: 1071.77ms; fastest: 0.09ms
=== Move ===
Hiccups: 0, StepErrors: 0, LaErrors: 0, FreeDm: 100, MinFreeDm: 79, MaxWait: 2429950ms, Underruns: 1012201, 0
Scheduled moves: 0, completed moves: 0
Bed compensation in use: none
Bed probe heights: 0.000 0.000 0.000 0.000 0.000
=== Heat ===
Bed heaters = 0, chamberHeaters = -1 -1
=== GCodes ===
Segments left: 0
Stack records: 1 allocated, 0 in use
Movement lock held by null
http is idle in state(s) 0
telnet is idle in state(s) 0
file is idle in state(s) 0
serial is idle in state(s) 0
aux is idle in state(s) 0
daemon is idle in state(s) 0
queue is idle in state(s) 0
autopause is idle in state(s) 0
Code queue is empty.
=== Network ===
Free connections: 15 of 16
Free transactions: 23 of 24
Locked: 0, state: 4, listening: 20071c20, 0, 0

adri84dj

Good afternoon,

I do not know if it's my problem, but I've made a couple of impressions with this latest firmware and the latest version of DWC, and it seems that the number of layers does not match the printed layers. My two impressions have finished in 52 of 50 layers

Greetings.

whosrdaddy

@dc42:

alt text

it is inconsistent, it seems not to depend on filesize.
for completeness, this is my M39 output:

SD card in slot 0: capacity 7.74Gb, free space 6.93Gb, speed 20.00MBytes/sec, cluster size 32kb

I did not have this problem on 1.21 firmware.

gideon

Hey,
I just came back somewhere, I wanted to operate the duet with the display just this did not respond well to the commandow, so I wanted to increase the temp but that does not work anymore, this went in firmware 1.21 still normal, this is a known problem
? I like to hear this

thank you in advance

gideon

sorry is not due to the firmware, but the touch panel does not work anymore, and I have not had it for a long time @dc42 what about warranty?

dc42

@gideon said in Stable firmware 2.01 (Duet 2) and 1.22 (Duet 06/085) released:

sorry is not due to the firmware, but the touch panel does not work anymore, and I have not had it for a long time @dc42 what about warranty?

Do you mean that the display is working, but the panel does not respond to touch? If so then it's most likely the touch panel on the display that is faulty. If you have the non-integrated version, then it's possible but not very likely that the PanelDue controller board has developed a fault.

gideon

@dc42 said in Stable firmware 2.01 (Duet 2) and 1.22 (Duet 06/085) released:

Do you mean that the display is working, but the panel does not respond to touch? If so then it's most likely the touch panel on the display that is faulty. If you have the non-integrated version, then it's possible but not very likely that the PanelDue controller board has developed a fault.

I have a separate PanelDue controller card,
I used the display yesterday, got the printer on again today, and now half of the touchscreen is working

BPisLife

This post is deleted!

dc42

@gideon said in Stable firmware 2.01 (Duet 2) and 1.22 (Duet 06/085) released:

@dc42 said in Stable firmware 2.01 (Duet 2) and 1.22 (Duet 06/085) released:

Do you mean that the display is working, but the panel does not respond to touch? If so then it's most likely the touch panel on the display that is faulty. If you have the non-integrated version, then it's possible but not very likely that the PanelDue controller board has developed a fault.

I have a separate PanelDue controller card,
I used the display yesterday, got the printer on again today, and now half of the touchscreen is working

You can try re-running the touch calibration, but if that doesn't work you will need a new display, unless you can find a replacement touch panel for it.

Catalin_RO

I have made a simple mistake when positioning the raw material on the CNC and the very last set of GCodes were outside the machine limits. As the spindle VFD is controlled through M3 and M5 commands, the GCode file had those as well. The GCodes outside the machine limits have been simply ignored, but the M5 was executed before the already queued moves finished, practically doing the final moves while the spindle was slowing down.

Luckily it was just a 2.5D cut, during the final passes, and no harm was really done, but if it were something different the end mill would have broken.

Could be added a safety check in the code for M5 to insure that there is no queued move to execute before powering down the spindle?

Later: Wrong! It always cuts the power of the spindle before finishing all queued moves!

dc42

@catalin_ro said in Stable firmware 2.01 (Duet 2) and 1.22 (Duet 06/085) released:

The GCodes outside the machine limits have been simply ignored

When in CNC mode, with firmware 2.0 and later any attempt to perform movement outside the machine limits should result in an immediate stop. Did this not happen, or are you running older firmware?