Stable firmware 2.01 (Duet 2) and 1.22 (Duet 06/085) released
-
@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
-
@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. -
@appjaws, what is the exact message you are getting, and when?
-
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 laterEdit. The "could not find end of file error" appears when the print starts
-
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 -
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.
-
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.
-
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 thisthank you in advance
-
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?
-
@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.
-
@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 -
This post is deleted! -
@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 workingYou 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.
-
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!
-
@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?
-
It is latest firmware! But it was nothing like an immediate stop...
No more GCodes were executed from the file but the already queued ones were allowed to completely finish and the final M5 was also executed, before actually ending any movements.
When doing another machining, with everything within machine limits, I found out that the M5 was also executed before all movements were finished (the spindle was actually fully stopped while the end mill was still moving through the material!!!).
A quick and dirty workaround was to replace M5 by G4 P0 M5, no properly waiting for any movements to fully finish. Shouldn't M5 wait for the movement queue to be empty before executing by default?
-
I installed a maestro on a printer with a 12864 display. With previous versions of the firmware the display would have the name and a number. Turning the encoder knob would increase or decrease the number.
With the latest version I get the following:
Error Loading menu
File Main
Can't open menu fileHowever, pressing the button on the display causes an emergency stop and the SD card reader works as well.
From the information that I have found I know it's not something that is fully featured or supported, but what is the current expected behaviour?
-
-
I can't connect to DWC and other than repitier usb to send m552 s1 I have no other way to control machine. Now what do I do? I installed this stable firmware and the DWC found a few line below on same page. Board turns on psu with m80 command when I plug in usb. That might be a repitier thing. I type ip address and nothing. Now I've been printing for more than a year with this, worked with the files many times and read every word of the instructions. I performed every step correctly. I had 1.21rc1 running before this upgrade. and DWC 1.22. now I loaded the versions found in this post and I'm no-longer printing.
-
Router page show ip config as static and full packets sending receiving. It's online full access enabled. But web interface doesn't load.