New firmware 1.21RC3 available
-
Jog controls, while being a "manual override" situation, could easily tell the controller to go beyond the hardware possibilities (printing head/spindle at coordinate 50 on one axis, and the user asks moving that axis with -100…). Thus manual override must be a "high level decision", so the controller should not accept any jog command as being such a decision by default, at least not with GUI based jog solutions.
Regarding 3D printing, I must admit that my own experience is non existent for now (not needed so far!). I do only CNC, and I do that only when there is a real a real need, not as a hobby. But I tend to understand the 3D printing problems, looking from above, as I follow the domain for many years.
Again, comparing to my every day situations, when I have to find ways to implement something in software that suits more customers, a solution to tell firmware it should no longer care about homing is clearly needed. How it is implemented is less important - it could be a 5-6 characters command or a 10K macro - it just needs to be rather simple way to access. Complex macros can be easily copy&pasted, simple commands can be turned into macros.
With 3D printing I see a lot of issues regarding printing resuming.. Worst case scenario - for a 10 hours job, the power goes away after every 20 minutes of printing. Let's consider that the printer is recovering when the power is back on, of course, with some delay. How about the missing microstepping status? Personally, I wouldn't even dare considering continuing a failed print. If really unlucky, a normally vertical wall would be just another staircase! And clearly this one would not go to heaven!
-
Unable to upgrade Duet 0.85 to 1.21RC3 from 1.19.2 using RepRapFirmware.bin. I tried utilizing DWC firmware update method first, and it appeared to transfer successfully and reboot, but it failed come back up. I tried erasing and utilizing the Bossac method. The new firmware transfers successfully via Bossac, but causes the Duet to reboot itself after 30 seconds or so repeatedly. (I can tell because the USB drops and reconnects about every 30 seconds.) Erased and Reflashed the firmware using Bossac back to 1.19.2 and the Duet is operating normally again.
Several users have reported this problem with various versions of RRF, one even with version 1.18. it's something to do with DHCP because setting a static IP address in the M552 command fixes it.
Please share your config.g file and I'll have another go at reproducing it.
-
I'm getting "Error: Attempt to seek on a non-open file." upon trying to print files from slic3r PE on 1.21RC3. The same files work OK on 1.20.
I can't reproduce this, nor find a reason for it. Can you share the GCode file? What is the filename? Does the print go ahead, or not?
-
Weirdly I also just got this "Error: Attempt to seek on a non-open file." error.
The first line (G28 X Y) is executed, and the the print stops with this error.I have to mention, this is not a regular gcode file from a slicer. It was generated by LaserWeb and should utilise a laser with M452 to cut paper. I tried to "fake" a few expected magic comments like layer height, slicer name, etc. but it still errors.
Here is my gcode file (manually reduced, but still shows the fault for me): https://www.dropbox.com/s/5mczpuy9vzst7jb/pew-pew.gcode?dl=0
Here my debug:
18:45:47 M122 === Diagnostics === Used output buffers: 3 of 32 (14 max) === Platform === RepRapFirmware for Duet 2 WiFi/Ethernet version 1.21RC3 running on Duet WiFi 1.02 or later Board ID: 08DDM-9FAMU-JWNSW-6J9F2-3S46N-KLJRT Static ram used: 16144 Dynamic ram used: 100584 Recycled dynamic ram: 2056 Stack ram used: 1224 current, 8496 maximum Never used ram: 3792 Last reset 00:01:47 ago, cause: software Last software reset at 2018-03-09 18:43, reason: User, spinning module GCodes, available RAM 3792 bytes (slot 1) Software reset code 0x0003 HFSR 0x00000000, CFSR 0x00000000, ICSR 0x0041f000, BFAR 0xe000ed38, SP 0xffffffff Error status: 0 Free file entries: 10 SD card 0 detected, interface speed: 20.0MBytes/sec SD card longest block write time: 0.0ms MCU temperature: min 40.6, current 40.9, max 41.2 Supply voltage: min 24.1, current 24.2, max 24.4, under voltage events: 0, over voltage events: 0 Driver 0: standstill, SG min/max 0/37 Driver 1: standstill, SG min/max 0/34 Driver 2: standstill, SG min/max 0/148 Driver 3: standstill, SG min/max not available Driver 4: standstill, SG min/max 0/160 Date/time: 2018-03-09 18:45:47 Slowest main loop (seconds): 0.155312; fastest: 0.000113 === Move === MaxReps: 2, StepErrors: 0, LaErrors: 0, FreeDm: 240, MinFreeDm 236, MaxWait: 61748ms, Underruns: 0, 0 Scheduled moves: 6, completed moves: 6 Bed compensation in use: none Bed probe heights: 0.000 0.000 0.000 0.000 0.000 === Heat === Bed heaters = 0 -1 -1 -1, chamberHeaters = -1 -1 Heater 1 is on, I-accum = 0.0 === GCodes === Segments left: 0 Stack records: 2 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 === Responder states: HTTP(1) HTTP(0) HTTP(0) HTTP(0) FTP(0) Telnet(1) Telnet(0) HTTP sessions: 1 of 8 - WiFi - Network state is running WiFi module is connected to access point Failed messages: pending 0, notready 0, noresp 0 WiFi firmware version 1.21RC4(08b3) WiFi MAC address ec:fa:bc:0b:fb:94 WiFi Vcc 3.33, reset reason Turned on by main processor WiFi flash size 4194304, free heap 14944 WiFi IP address 10.0.0.42 WiFi signal strength -48dBm, reconnections 0, sleep mode modem Socket states: 2 2 0 0 0 0 0 0 === Expansion === 18:45:41Error: Attempt to seek on a non-open file. -
I'm getting "Error: Attempt to seek on a non-open file." upon trying to print files from slic3r PE on 1.21RC3. The same files work OK on 1.20.
I can't reproduce this, nor find a reason for it. Can you share the GCode file? What is the filename? Does the print go ahead, or not?
I did, it got buried earlier in the tread. Here it is again:
; generated by Slic3r Prusa Edition 1.39.1-beta1-prusa3d-win64 on 2018-03-06 at 18:25:08 ; ; external perimeters extrusion width = 0.45mm ; perimeters extrusion width = 0.45mm ; infill extrusion width = 0.45mm ; solid infill extrusion width = 0.45mm ; top infill extrusion width = 0.40mm ; first layer extrusion width = 0.45mm M107 M106 P1 S0.1 I0 F500 H-1; M140 S110; G28 X Y G1 X150 Y100 M190 S110; G30 X150 Y100 G1 X150 Y100 Z25 M104 S267 T0; M109 S267 T0; M106 P1 S0.2 I0 F500 H-1; ; Filament gcode ;M290 S0.05 G21 ; set units to millimeters G90 ; use absolute coordinates M83 ; use relative distances for extrusion G1 Z0.300 F10500.000 G1 E-1.20000 F2280.00000 G1 X125.225 Y99.725 F10500.000 G1 E1.20000 F2280.00000 G1 F600 G1 X174.775 Y99.725 E2.38319 G1 X174.775 Y100.275 E0.02645 G1 X125.225 Y100.275 E2.38319 G1 X125.225 Y99.785 E0.02357 G1 X125.625 Y99.726 F10500.000 G1 X125.418 Y100.000 F10500.000 G1 F600 G1 X174.582 Y100.000 E1.00800 G1 E-1.20000 F2280.00000 ; Filament-specific end gcode ;END gcode for filament M104 S0 ; turn off extruder M140 S0 ; turn off bed M107; Turn off fans G91 G1 Z50 ; lift z G90 ;G28 Z; home all axes M84 ; disable motors M106 P1 S0.5 I0 F500 H-1; dim lightsIt's a tiny test object, just 2 lines. The same job sliced in S3D or Slic3r PE doesn't start on the CoreXY - the execution stops after finishing the G28 command.
Edit: As for the filename it was something very generic - test_line.gcode or something similar. No special characters. The file shows up in the "G-codes" tab in DWC, no issues there.
-
dc42: did you consider simulation mode and unhomed moves? I think I found a bug in RC3:
Simulating a print fails everytime with: "Error: G0/G1: insufficient axes homed".I know that the file in question prints fine, because I successfully printed it the day before yesterday.
-
Yes, that's a known issue.
-
Yes, that's a known issue.
So how about double tap homing on G30? Possible to add behavior to match bed leveling?
-
@nyt:
Yes, that's a known issue.
So how about double tap homing on G30? Possible to add behavior to match bed leveling?
I am looking at this now. It would be easier if I change the behaviour of G30 with no P parameter so that after probing it moves the probe up to the dive height, just as it does when there is a P parameter. Can anyone see a reason why I shouldn't make this change?
-
It would be easier if I change the behaviour of G30 with no P parameter so that after probing it moves the probe up to the dive height, just as it does when there is a P parameter. Can anyone see a reason why I shouldn't make this change?
Sounds good for my CoreXY. It would also be nice if I could do a fast-slow Z-home with G30. Currently the probe speed is fixed in M558 - and I don't really like copy-pasting my M558 lines to get different speeds.
Either M558 can take two parameters: a slow and a fast speed,
or G30 takes a new parameter to override the probe speed for the single probing move. -
Another possibility I have considered is to keep G30 behaving as now (but possibly with a speed override), but to make G30 P0 Z-9999 S1 do "1-factor calibration" on all machine architectures, i.e. set the Z height. Then in homez.g you would do G30 followed by G30 P0 Z-9999. The G30 with P parameter would support multi tap.
-
Speed override would be great, could do a normal home like that, then whatever multi tap command.
-
I have changed the code so that G30 by itself can do multi tap. Only G30 S-1 and S-2 now do single tap on!y.
-
I have changed the code so that G30 by itself can do multi tap. Only G30 S-1 and S-2 now do single tap on!y.
Great!! When is expected the next beta?
-
Tomorrow or Monday.
-
Recent code changes have changed z-probe "multi-tap" to use an average instead of aborting when none of the taps are within a specified tolerance. Is there a parameter to get the old (aborting) behavior?
The reason I'm asking is that I had a bltouch (since returned) that would trigger at seemingly random places in a range of almost .2mm. When that happens, I don't trust even an average and would prefer that the entire operation be aborted.
-
Recent code changes have changed z-probe "multi-tap" to use an average instead of aborting when none of the taps are within a specified tolerance. Is there a parameter to get the old (aborting) behavior?
The reason I'm asking is that I had a bltouch (since returned) that would trigger at seemingly random places in a range of almost .2mm. When that happens, I don't trust even an average and would prefer that the entire operation be aborted.
It doesn't just use an average. If two parameters are outside of the specified value, it keeps probing until they're within tolerance. I'm using 0.005 with the IR sensor.
-
I have 2 duet ethernets one is fairly recent while the other is at least a year old. I was running 1.21RC1 and upgraded the older one to RC3 with no issue. However the newer one, when upgraded to RC3, lost ethernet connectivity after the upgrade. I ran M552 and it said something like wifi disabled. I thought maybe I renamed the wrong firmware file so I flashed 1.21RC1 to it via Sam2.17 and it connected to ethernet. I carefully downloaded the combined version of RC3 and renamed it DuetEthernetFirmware.bin and uploaded. It upgraded and did the upgrade again and ethernet again wasn't working so I flashed it back to 1.21RC1 with sam2.17. Any idea why it seems to think this one is a duet wifi?
-
Please confirm that it thinks it is a Duet WiFi after installing RC3, by sending M115. If that confirms it, check that the two pins on the Ethernet daughter board connector nearest the edge of the PCB are properly soldered, both on the socket soldered to the Duet and the pins soldered to the daughter board.
-
I still have the issue with it skipping/ignoring M116 commands with RC3.
It really bit me in the rear when I tried a print with a non-heated build plate. (The only way I could get it to print was to completely preheat the nozzle before starting the gcode print.)I'll try to come up with some simple gcode file tomorrow.
