New firmware 1.18RC1


  • administrators

    I've released this on github. This version is now feature-complete, so any further changes prior to the 1.18 release will be just to fix bugs that any of you find. For the full change list since 1.17e, see https://github.com/dc42/RepRapFirmware/blob/dev/WHATS_NEW.md.



  • 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


  • administrators

    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 printer

    AM
    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.


  • administrators

    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).


  • administrators

    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
    
    

  • administrators

    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
    ok
    
    

    edit: 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 -11

    And finally, power cycling fixed everything again.

  • administrators

    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


  • administrators

    @str8up:

    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

    Thanks. 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.



  • @ChrisP:

    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


  • administrators

    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?


  • administrators

    No it doesn't, but in this version bed compensation and orthogonal axis compensation are disabled during homing moves.


 

Looks like your connection to Duet3D was lost, please wait while we try to reconnect.