New firmware 1.18RC1
-
David,
I looked at the release notes. Could you elaborate on the use of M204 please. It's not on the Duet G code Wiki but I'm guessing it's default accelerations, T being travel moves and P being print moves but are they axis specific like M201? i.e can you set different default accelerations for print and travel for each of the axes, something like M204 XPnnn XTnnn YPnnn YTnnn etc?
Thanks
Ian
-
I'll add M204 to the wiki soon. They are not axis specific but they only apply to moves with an XY component. The most useful is the P parameter, because it lets you use a lower acceleration for printing moves than for travel moves, and on a Cartesian printer this acceleration is independent of the move direction.
-
David,
Thanks and respect for all your hard work on this.
Installed 1.18RC1 yesterday. After running Auto Cal then Mesh leveling I checked to see if the mesh compensation was active with M122. Are the Bed probe heights correct? This is a delta printerAM
M122
=== Diagnostics ===
Used output buffers: 1 of 32 (11 max)
=== Platform ===
Static ram used: 20304
Dynamic ram used: 72928
Recycled dynamic ram: 976
Stack ram used: 968 current, 11264 maximum
Never used ram: 25600
Last reset 15:05:08 ago, cause: software
Last software reset code 0x0003, HFSR 0x00000000, CFSR 0x00000000, ICSR 0x00400000, BFAR 0xe000ed38, SP 0xffffffff
Spinning module during software reset: GCodes, available RAM 33056 bytes (slot 1)
Error status: 0
Free file entries: 10
SD card 0 detected, interface speed: 20.0MBytes/sec
SD card longest block write time: 2.8ms
MCU temperature: min 26.3, current 31.2, max 39.5
Supply voltage: min 0.3, current 23.3, max 25.2, under voltage events: 1, over voltage events: 0
Driver 0: stalled standstill
Driver 1: stalled standstill
Driver 2: stalled standstill
Driver 3: standstill
Driver 4: standstill
Date/time: 2017-03-29 11:54:37
Slowest main loop (seconds): 0.087280; fastest: 0.000000
=== Move ===
MaxReps: 5, StepErrors: 0, MaxWait: 49669874ms, Underruns: 0, 0
Scheduled moves: 21597, completed moves: 21597
Bed compensation in use: mesh
Bed probe heights: 0.000 0.000 0.000 0.000 -0.116
Probe change coordinates:
=== Heat ===
Bed heater = 0, chamber heater = -1
Heater 0 is on, I-accum = 0.0
Heater 1 is on, I-accum = 0.4
=== GCodes ===
Segments left: 0
Stack records: 3 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
Code queue is empty.
=== Network ===
WiFiServer is running
SPI underruns 0, overruns 0
=== Webserver ===
HTTP sessions: 1 of 8 -
I mentioned this in the previous 1.18beta3 but I'm still having stability issues with these latest firmware releases on a number of Duet 06 boards.
I had an 06 board in a RRP Fisher that I have at home that if I flashed with version 1.18beta3, I could not connect to the web interface at all. If I tried, it would sometimes just about load a skeleton of the page, but usually not. However, every time I tried to access the web interface it would cause the board to sit and continually reboot. I could tell this was happening as the thermostatic fan would blip on briefly and the LEDs on the network would also all turn off for a short while. Loading 1.17e back on made everything work fine again. That said, I've now replaced that board with a Duet WiFi which is working fine with the latest version.
The second machine I've tried upgrading is another RRP Fisher that sits on my desk at work. I upgraded that a little while ago to 1.18beta3 and it's been working okay up until this morning, at which point it started doing exactly the same as the other I describe above. Having seen this topic about new FW, I've tried loading that and it was doing exactly the same thing. However, this time I tried powering over USB and enabling the debug logging. Here was the log:
[[language]] RepRapFirmware for Duet Version 1.18RC1 dated 2017-03-28 Executing config.g...HTTP is enabled on port 80 FTP is enabled on port 21 Done! Starting network... RepRapFirmware for Duet is up and running. Network up, IP= <removed><sent via="" terminal="">M111 S1 ok <sent via="" terminal="">M114 serial: M114 X: 0.000 Y: 0.000 Z: 0.000 E0: 0.0 E1: 0.0 E2: 0.0 E3: 0.0 E4: 0.0 E5: 0.0 Count 12035 12035 12035 ok <navigated to="" web="" interface="">Incoming transaction: Type connected at local port 80 (remote port 56358) Incoming transaction: Type receiving at local port 80 (remote port 56358) HTTP req, command words { GET / HTTP/1.1 }, parameters { } Incoming transaction: Type connected at local port 80 (remote port 56359) Incoming transaction: Type receiving at local port 80 (remote port 56359) HTTP req, command words { GET /css/dwc.css HTTP/1.1 }, parameters { } Incoming transaction: Type connected at local port 80 (remote port 56360) Incoming transaction: Type receiving at local port 80 (remote port 56360) HTTP req, command words { GET /js/dwc.js HTTP/1.1 }, parameters { } ConnectionLost called for local port 80 (remote port 56358) Assertion "(h != NULL) && (t != NULL) (programmer violates API)" failed at line 752 in ../src/Duet/Lwip/lwip/src/core/pbuf.c</navigated></sent></sent></removed>At this point the terminal becomes unresponsive, the web interface times out and again, the LEDs on the ethernet port flash off and the fan blips on. While this happens 100% of the time using Chrome, for whatever reason, if I use IE it occasionally gets a little further, and about 1 in 20 tries with IE it'll load the page fully as if there was never any problem.
While I mentioned that I was able to downgrade the firmware on my printer at home and have everything work again, this one now seems largely unusable. I really don't see why it should be a hardware problem, particularly as reverting to older FW at home fixed the issue, but with this one I can't find any other explanation as yet. I've tried 3 versions of firmware 1.17e, 1.18beta3 and 1.18RC1 in combination with 3 different WebControl versions 1.14-RC1, 1.15-b2 and 1.15 (I'm clutching at all straws here!), but nothing seems to work any more.
Even more interestingly, if I enable debugging from config.g this is as far as it gets, every time, without fail. After this, the ethernet LEDs flicker as usual for a few seconds, then go off, then they flicker for a bit and go off again, and it'll sit doing that until I pull the plug.
[[language]] RepRapFirmware for Duet Version 1.18RC1 dated 2017-03-28 Executing config.g...daemon: M555 P2 daemon: M550 P <removed>daemon: M551 P <removed>daemon: M540 P0xBE:0xEF:0xDE:0xAD:0xFE:0x50 daemon: M552 P0.0.0.0 daemon: M553 P255.255.255.0 daemon: G21 daemon: G90 daemon: M83 daemon: M569 P0 S0 daemon: M569 P1 S0 daemon: M569 P2 S0 daemon: M569 P3 S0 daemon: M569 P4 S1 daemon: M906 X900 Y900 Z900 E1200 daemon: M574 X2 Y2 Z2 S1 daemon: M92 X87.489 Y87.489 Z87.489 daemon: M201 X4000 Y4000 Z4000 E4000 daemon: M203 X15000 Y15000 Z15000 E9000 daemon: M210 Z50 daemon: M566 X1200 Y1200 Z1200 E1200 daemon: M665 L160.00 R81.720 B75.00 H177.104 X0.112 Y1.368 Z0.00</removed></removed>This is where things get really odd… since typing this, I've been trying a few more things.
My Fisher at work sits turned on 24/7, so I wondered whether it could be the power supply that was on it's way out, although in hindsight this is unlikely as some of the testing I did above was only being powered by USB. Either way, I swapped the one on my desk for one that I rarely use that sits connected but turned off in a cabinet on the office (at the time it was still running 1.12a), the odd thing is that both worked fine. I set a print going on the one that was giving me trouble and it printed fine. In the mean time, I updated the other to 1.18RC1 and managed to get as far as doing the 1st iteration of calibration but it then just stopped while probing on the second iteration. Shortly after, the original printer finished, so I removed the print and set clicked "Print Another" (great feature!). However, the head lowered to do a probe for the z-height that I usually do before a print, and then died too. At this point both machines reset themselves and then each produced 3 perfect prints one after another. I've just swapped them back and again they're both working as if the past 3 hours of frustration didn't happen.At this point I'm totally stumped. Is it possible that there's something on the network here that's causing the systems to reset and become unreliable? Keep in mind that both machines I've been having problems with today require passwords to get to the web interface.
-
Chris, thanks for that detailed report. In particular, that assertion failure message may be the key I was looking for.
-
No problem
If I can be of any help for testing, let me know as I have access to multiple Duets of varying versions on a range of setups… 4x v0.6, 3x 0.8.5, and a WiFi running deltas, Cartesian, and 5-axis.In the near future I'm also going to be looking at upgrading a 3DP workbench with a duet ethernet. However, I need to know that this current issue won't occur on that setup too, as it'll be on the same network and will need need to be able to function pretty much indefinitely without being power cycled.
FWIW, when I got into work this morning the Fisher that sits on my desk was unresponsive again although after a power cycle now seems to be working again (touch wood).
-
str8up, those bed probe heights look wrong to me. I will do some tests.
ChrisP, please can you load 1.16RC1 on one of your wired Duets and run M122 so that we can see how much free memory it has.
The Duet Ethernet uses a different network stack from the older Duets, so it is most unlikely to suffer from the same problem.
-
I'm going to assume that you meant 1.18RC1….
[[language]] M122 === Diagnostics === Used output buffers: 2 of 32 (8 max) === Platform === Static ram used: 45844 Dynamic ram used: 39916 Recycled dynamic ram: 256 Stack ram used: 1088 current, 4944 maximum Never used ram: 7344 Last reset 00:04:47 ago, cause: power up Last software reset code 0x7003, HFSR 0x00000000, CFSR 0x00000000, ICSR 0x0042f00f, BFAR 0xe000ed38, SP 0xffffffff Spinning module during software reset: GCodes, available RAM 5848 bytes (slot 1) Error status: 0 Free file entries: 10 SD card 0 detected, interface speed: 21.0MBytes/sec SD card longest block write time: 0.0ms MCU temperature: min 36.4, current 40.7, max 48.3 Date/time: 2017-03-30 11:28:46 Slowest main loop (seconds): 0.060730; fastest: 0.000110 === Move === MaxReps: 3, StepErrors: 0, MaxWait: 972ms, Underruns: 0, 0 Scheduled moves: 5, completed moves: 5 Bed compensation in use: mesh Bed probe heights: 0.000 0.000 -0.057 -0.011 -0.002 === Heat === Bed heater = -1, chamber heater = -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 Code queue is empty. === Network === Free connections: 15 of 16 Free transactions: 23 of 24 === Webserver === HTTP sessions: 1 of 8 FTP connections: 0, state 0 Telnet connections: 0, state 0 -
Thanks, that looks good in particular the never used RAM.
-
Ok, so it's died again (as in the web interface just sits loading indefinitely) having not been touched at all since the log I got for you before. I can still connect to it using USB though. Running M122 again gives the log below. I notice that it has 255 telnet connections. Could this be whats killing it?
[[language]] === Diagnostics === Used output buffers: 1 of 32 (17 max) === Platform === Static ram used: 45844 Dynamic ram used: 39916 Recycled dynamic ram: 256 Stack ram used: 3240 current, 4944 maximum Never used ram: 7344 Last reset 02:55:59 ago, cause: power up Last software reset code 0x7003, HFSR 0x00000000, CFSR 0x00000000, ICSR 0x0042f00f, BFAR 0xe000ed38, SP 0xffffffff Spinning module during software reset: GCodes, available RAM 5848 bytes (slot 1) Error status: 0 Free file entries: 10 SD card 0 detected, interface speed: 21.0MBytes/sec SD card longest block write time: 0.0ms MCU temperature: min 38.6, current 49.8, max 54.7 Date/time: 2017-03-30 14:19:59 Slowest main loop (seconds): 0.060425; fastest: 0.000000 === Move === MaxReps: 0, StepErrors: 0, MaxWait: 0ms, Underruns: 0, 0 Scheduled moves: 5, completed moves: 5 Bed compensation in use: mesh Bed probe heights: 0.000 0.000 -0.057 -0.011 -0.002 === Heat === Bed heater = -1, chamber heater = -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 ready with "M122" 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 Code queue is empty. === Network === Free connections: 1 of 16 Free transactions: 24 of 24 === Webserver === HTTP sessions: 0 of 8 FTP connections: 0, state 0 Telnet connections: 255, state 1 okedit: So I just disabled Telnet using USB and now I can get the web interface to load a basic text version that looks pretty awful. Every time I try to load / re-load the page, the terminal gives the following message too.
[[language]] Network::ConnectionAccepted() - no free ConnectionStates! ```and occasionally this:[[language]]
Network: Connection error, code -11And finally, power cycling fixed everything again. -
Indeed it looks like it kept opening new Telnet connections and that used up all the network resources, which didn't all get freed when you disabled Telnet. Did you have any Telnet sessions to the Duet?
-
No I didn't have any sessions open. That's not to say that someone else on the network wasn't trying to gain access though…
For the time being, I've just disabled Telnet in the config and I'll see how it goes. -
Here is the heightmap.csv data.
RepRapFirmware height map file v1 generated at 2017-02-30 10:19, mean error -0.01, deviation 0.12
xmin,xmax,ymin,ymax,radius,spacing,xnum,ynum
-100.00,100.10,-100.00,100.10,105.00,20.00,11,11
0, 0, 0, 0, -0.107, -0.261, -0.329, 0, 0, 0, 0
0, 0, 0.041, -0.028, -0.038, -0.016, -0.050, -0.051, -0.177, 0, 0
0, -0.032, -0.144, -0.122, -0.152, -0.150, -0.120, -0.119, -0.113, -0.012, 0
0, -0.034, -0.019, 0.040, 0.043, 0.100, 0.131, 0.080, 0.059, 0.122, 0
0, -0.098, -0.132, -0.081, -0.059, -0.030, 0.039, -0.010, 0.059, 0.109, 0.153
0, -0.078, -0.041, 0.017, 0.089, 0.109, 0.170, 0.161, 0.193, 0.159, 0.202
0, -0.140, -0.159, -0.080, -0.032, 0.050, 0.067, 0.137, 0.160, 0.151, 0.121
0, -0.071, -0.059, -0.039, -0.068, -0.018, 0.012, 0.077, 0.191, 0.270, 0
0, 0, -0.122, -0.237, -0.149, -0.061, 0.020, 0.060, 0.117, 0.102, 0
0, 0, 0, -0.128, -0.093, -0.043, -0.021, 0.048, 0.090, 0, 0
0, 0, 0, 0, 0, -0.052, -0.069, 0, 0, 0, 0 -
Here is the heightmap.csv data.
RepRapFirmware height map file v1 generated at 2017-02-30 10:19, mean error -0.01, deviation 0.12
xmin,xmax,ymin,ymax,radius,spacing,xnum,ynum
-100.00,100.10,-100.00,100.10,105.00,20.00,11,11
0, 0, 0, 0, -0.107, -0.261, -0.329, 0, 0, 0, 0
0, 0, 0.041, -0.028, -0.038, -0.016, -0.050, -0.051, -0.177, 0, 0
0, -0.032, -0.144, -0.122, -0.152, -0.150, -0.120, -0.119, -0.113, -0.012, 0
0, -0.034, -0.019, 0.040, 0.043, 0.100, 0.131, 0.080, 0.059, 0.122, 0
0, -0.098, -0.132, -0.081, -0.059, -0.030, 0.039, -0.010, 0.059, 0.109, 0.153
0, -0.078, -0.041, 0.017, 0.089, 0.109, 0.170, 0.161, 0.193, 0.159, 0.202
0, -0.140, -0.159, -0.080, -0.032, 0.050, 0.067, 0.137, 0.160, 0.151, 0.121
0, -0.071, -0.059, -0.039, -0.068, -0.018, 0.012, 0.077, 0.191, 0.270, 0
0, 0, -0.122, -0.237, -0.149, -0.061, 0.020, 0.060, 0.117, 0.102, 0
0, 0, 0, -0.128, -0.093, -0.043, -0.021, 0.048, 0.090, 0, 0
0, 0, 0, 0, 0, -0.052, -0.069, 0, 0, 0, 0Thanks. The bed probe heights are correct, because after G29 you will see the first 5 points from the height map. The first 4 are zero because you are probing a circular bed.
-
No I didn't have any sessions open. That's not to say that someone else on the network wasn't trying to gain access though…
For the time being, I've just disabled Telnet in the config and I'll see how it goes.If this is a corporate network there could be all sorts of port scanners, vulnerability assessment tools or even, unfortunately, compromised machines looking to spread a virus or malware. These may well see the Duet as an 'interesting' target as telnet is a legacy protocol that used to be in use by network infrastructure vendors a great deal. There a huge lists of default passwords and usernames out there that these programs use to brute force the telnet connection and take over such devices. One example of such a list:
http://www.defaultpassword.com/
If this is a smaller office or home network then the malware/virus case is more likely. It might be possible to identify the source traffic, either by binary search (Switch half of the machines off, if the problem recurs, switch half of the remainder off, etc). Alternatively, you could use a tool like Wireshark to look for the offending node but this is more complex with WiFi in the mix.
Hope this helps.
David
edit - clarity
-
This is why I added the facility to support http but not telnet or ftp, with telnet and ftp turned off by default. But it doesn't explain why earlier versions of firmware worki for ChrisP.
-
I'm on a university network, so I'm pretty certain that there's at least one machine that will have been hacked and is scanning all the ports. To be honest, I probably should have figured out the problem sooner as it's not the first time it's happened.
As for it working with other firmware, I wonder whether it was just an unfortunate coincidence. When I had the problem back on Wednesday, I had tried older firmware versions and had those fail too - that's what initially made me wonder whether it was a hardware problem.
Anyway, having turned off Telnet (which I didn't use anyway), all is fine again… hopefully
-
Hi David, I know previously we discussed using G30 to reset the z height after grid levelling/calibration and you mentioned doing this on a grid point. I just installed this firmware and after calibration I did a G30. I noticed the nozzle change x,y position fractionally before the G30 executed, does the firmware auto position on a grid point for this in this version?
-
No it doesn't, but in this version bed compensation and orthogonal axis compensation are disabled during homing moves.
-
I've just released firmware 1.18RC2. I am particularly keen for Duet 0.6/0.8.5 users to test it, to see if it resolves the network issues that some users had with beta3 and RC1.
