New firmware 1.21RC3 available
-
Okay, well that's simple enough. That was though just a minor issue, its the fact that RC3 doesn't seem to work on corexy that was the main event for me.
Please provide more details of why RC3 didn't work for you, along with any relevant GCode files.
-
It's working with my CoreXY OK.
(I'm chasing some print artifacts, but they exist on 1.20 as well, so I don't think it's FW related)
-
In my case it was "Error: Attempt to seek on a non-open file." when trying to print anything sliced on Slic3r PE on my CoreXY. Reverted to the old firmware and finished the print without issues. I'll run a couple more tests on both my delta and the CoreXY in the evening.
-
I get that right at the end of files from Cura. Not at all from S3D. But it prints the full print for Cura.
-
Okay, well that's simple enough. That was though just a minor issue, its the fact that RC3 doesn't seem to work on corexy that was the main event for me.
Please provide more details of why RC3 didn't work for you, along with any relevant GCode files.
Hi David sorry scroll up a bit I provided a report and an M122. Corexy and attempting to print a SlicerPE file, so same issue others have had, downgrading just FW fixed it. Deltas working perfectly on rc3.
-
I'm also running a CoreXY - didn't experience any issues with RC3 so far, about 5 prints or so successfully finished.
DC42: I think it would make sense to add the new debug information about SD cluster size to M122 as well.
-
In my case it was "Error: Attempt to seek on a non-open file." when trying to print anything sliced on Slic3r PE on my CoreXY. Reverted to the old firmware and finished the print without issues. I'll run a couple more tests on both my delta and the CoreXY in the evening.
Thanks. Please can you confirm or otherwise:
1. The fault only occurs when you try to print a file from SD card. In particular, just listing the files on the DWC GCode Files page doesn't provoke the problem;
2. The fault only occurs if the file was sliced by slic3r PE;
3. All files sliced with this version of slicer PE exhibit this issue when you try to print them.Please supply a small test file that demonstrates the problem.
-
I have had to revert to rc2
I need to move the hotend to the center of the bed prior to Z0.
I also have a startup procedure in my start gcode on S3D. Even though the machine had all axis zero'd the print would not start. So I disabled the homeall part of the startup but because I use M32 to level the bed using 3 motors and that includes homeall nothing happened. I then noticed that the heaters had been turned off due to a power reset!!!!Why are we introducing a procedure that Z has to be zero'd before and other axis can move? This may well be good for Delta printers but is no good for my coreXYUV machine. This seems a backward step.
Would it be possible for a user option to switch this on or off?
Sorry for the rant, feeling a bit dissapointed -
Z does not have to be homed or zeroed before the other axes can move. Did you read the upgrade notes?
-
Okay, well that's simple enough. That was though just a minor issue, its the fact that RC3 doesn't seem to work on corexy that was the main event for me.
Please provide more details of why RC3 didn't work for you, along with any relevant GCode files.
Hi David sorry scroll up a bit I provided a report and an M122. Corexy and attempting to print a SlicerPE file, so same issue others have had, downgrading just FW fixed it. Deltas working perfectly on rc3.
I use SlicerPE and no problems on my CoreXY.
-
I've tried it out, both S3D and Slic3r PE files work on my delta (it gives the "Error: Attempt to seek on a non-open file." popup at the end of the print though), while neither would print on the CoreXY. The printer executes the G28 command and stops with the error message. The same result repeats regardless of the object in question, I'll try to attach a sample G-code here.
; 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 lights -
I don't know if this was fixed in RC3 or not, but I just noticed the following issue in RC2:
When setting up a z-probe with P5 (It's a BLtouch) A3 (probe each location up to 3 times) and B1 (turn off bed heater while probing), the heater gets turned off for the FIRST of multi-tap probes, but not subsequent multi-tap probes.
So, assuming a M558 of:
M558 P5 X0 Y0 Z1 H5 F100 T4000 A3 B1
and a bed.g containing the following:
G30 P0 X1.1 Y-69.2 Z-99999
G30 P1 X-50 Y65.5 Z-99999
G30 P2 X49 Y65.5 Z-99999 S3(and the manual levelling assistant configured.)
In each of the above probes, the heater is turned off for the FIRST test in each location, but the heater is turned back on (and stays on) for the SECOND probe. (My probes are apparently within 0.03 of each other, as I don't see a third probe in any location.)
Thanks for posting this - I wasnt sure how to use the Bed heat on/off within M558. Also I wasnt aware that multitap was in the RC2 version. Im on RC3 and needed to change the P parameter of Probe MODE to 9 [ P9 ] for RC3 as per the notes. I will test out RC3 with the bed on/off settings and report if RC3 is working as inted for this feature
-
Thanks for posting this - I wasnt sure how to use the Bed heat on/off within M558. Also I wasnt aware that multitap was in the RC2 version. Im on RC3 and needed to change the P parameter of Probe MODE to 9 [ P9 ] for RC3 as per the notes. I will test out RC3 with the bed on/off settings and report if RC3 is working as inted for this feature
Sorry to quote myself - but … I just tried this and I dont see any changes in the DWC interface indicating to me the heated bed is getting shut off between probes ... What are you using to monitor that activity ...
-
I don't know if this was fixed in RC3 or not, but I just noticed the following issue in RC2:
When setting up a z-probe with P5 (It's a BLtouch) A3 (probe each location up to 3 times) and B1 (turn off bed heater while probing), the heater gets turned off for the FIRST of multi-tap probes, but not subsequent multi-tap probes.
So, assuming a M558 of:
M558 P5 X0 Y0 Z1 H5 F100 T4000 A3 B1
and a bed.g containing the following:
G30 P0 X1.1 Y-69.2 Z-99999
G30 P1 X-50 Y65.5 Z-99999
G30 P2 X49 Y65.5 Z-99999 S3(and the manual levelling assistant configured.)
In each of the above probes, the heater is turned off for the FIRST test in each location, but the heater is turned back on (and stays on) for the SECOND probe. (My probes are apparently within 0.03 of each other, as I don't see a third probe in any location.)
I believe that was fixed in RC3 along with the other multi-touch issues, but please check.
-
Me again, tried 1.21rc3 and found CoreXZ isnt moving along its "planes" anymore its as though ive left it in cartesian mode.
only change was updating from v1.20 to 1.21rc3 and changed my z movements with S2 parameter.Gav
-
You won't see any indications in DWC because it is a temporary suspension of heating. However, all the heater LEDs on the Duet will go off; and any heater LEDs on the hot end (e.g. Smart Effector) or bed heater will go off too.
-
Me again, tried 1.21rc3 and found CoreXZ isnt moving along its "planes" anymore its as though ive left it in cartesian mode.
only change was updating from v1.20 to 1.21rc3 and changed my z movements with S2 parameter.Gav
OK, I see the problem. S2 invokes direct motor movement; but on a CoreXZ printer, you need to move both the X and Z motors to move Z. Here are two possible workarounds:
1. As you don't have a Z endstop switch, make sure you say so in config.g (Z0 in the M574 command), then you can use S1 instead of S2 in that G1 Z command;
2. Instead of G1 S2 Znn use G1 S2 Xnn Znn to get the correct Z movement (one of them may need to be negative, I can't remember).
I have been considering introducing a new mode S4 for G1 commands. This would mean:
1. Movement is allowed regardless of whether axes have been homed (like S1, S2 and S3);
2. Axis mapping is not performed (like S1, S2 and S3);
3. Coordinates are always interpreted in Cartesian space;
4. On Delta and SCARA printers, X and Y movements using S4 are not allowed;
5. Coordinates are always interpreted as relative (not sure about this one, because absolute S4 movements might possibly be useful on CoreXYU and CoreXYUV machines). -
1. As you don't have a Z endstop switch, make sure you say so in config.g (Z0 in the M574 command), then you can use S1 instead of S2 in that G1 Z command;
so this has kind of worked, but having a bltouch probe thats defined as M574 Z2 right? whats the correct way to define a z probe but no endstop?
-
As long as you are using G30 to do Z homing in homez.g and homeall.g (not G1 S1 Znnn moves), M574 Z0 will work just fine. That says you have a Z probe and no endstop.
-
ended up using method 2, working as expected now
apart from the z not homed before z as in other thread, im almost there 
thanks again
