It's out! Firmware 1.21 released
-
Subtle change noticed…
My procedure:
- Home axis
- Warm up bed / enclosure
- Run bed probe
- Warm up nozzle
- Check nozzle height with my calibrated feeler gauge (scrap of paper )
- Use G10 to set tool offset - i.e. if feeler'ed ideal z=0 plane is at Z=-0.15mm I'll send 'G10 P0 Z0.15'
The G10 used to update the reported z position instantly. Now running the G10 command would virtually shift the axis but the value reported on 1.21 web control only updates after a G1 move of the z-axis - which may be a no-distance move.
-
Subtle change noticed…
My procedure:
- Home axis
- Warm up bed / enclosure
- Run bed probe
- Warm up nozzle
- Check nozzle height with my calibrated feeler gauge (scrap of paper )
- Use G10 to set tool offset - i.e. if feeler'ed ideal z=0 plane is at Z=-0.15mm I'll send 'G10 P0 Z0.15'
The G10 used to update the reported z position instantly. Now running the G10 command would virtually shift the axis but the value reported on 1.21 web control only updates after a G1 move of the z-axis - which may be a no-distance move.
On my list to look at.
-
2. In FDM printer mode, that is correct. The reason is that it is quite common for a skirt to exceed the bounds of the bed. In laser and CNC mode the print will be terminated. If you want this changes, please suggest what you would like instead in the Firmware Wishlist section.
Of course they are right. If it was just the skirt, brim or raft, it would be a good feature.
I can live with that, if I know itI have noticed inconsistent Z-value display in firmware 1.21. Observed at nozzle change and Babystepping, Babystepping did not show any z-change.
-
That's correct, the displayed height is now in user coordinate space, i.e. what was commanded in the last G0 or G1 command before any baby stepping, axis skew correction, tool offset, workspace coordinate offsets or bed level correction. The machine coordinates are also sent to DWC, so in future DWC may display machine coordinates too.
-
OK, I see after doing the Update CoreXY has issue, which I have now, and I read all around what it can't do anymore, but no CLEAR method to fix the homing setting.. just little snippets that are making no sense to me. what exactly do I have to do now that the firmware is updated do I have to do/change to get it to run again? I'm am far from a Codey guy, but can usually figure stuff out, but this makes no sense to me... the Update info says the G1 won't work anymore and need to add some S2 command, but what S2 command? where? does it need a value? do you remove the G0 or G1's from the homing files? Do I have to go in and edit all four Home files in the firmware? will I have to add S2 every time I use the G1/G0 commands?
-
OK, face book people helped out and seems I have it working correctly now.. needed to go through all the homing settings file, add and S2 to the end of ever G1 line, unless there is a S1 already there. did screw up and it wasn't sensing the end stops at 1st, but luckily I have copied and save the text in note pad. Started from scratch and re added the S2's and now it seems to be working.
on another note, did a search and basically came up with nothing so.. What is S1 and S2? what do the mean/do?
thanks
-
Snnn Flag to check if an endstop was hit (S1 to check, S0 to ignore, S2+S3 see note, default is S0) 1
1RepRapFirmware can be set to enable or disable the "sensing" of endstops during a move. Using the S1 or S2 parameter on a delta printer causes the XYZ parameters to refer to the individual tower motor positions instead of the head position, and to enable endstop detection as well if the parameter is S1. If S3 is passed instead, RepRapFirmware will measure the axis length. -
Honestly, is there a way to return it to the old method? I'm finding this rather annoying. Have changed over the Home files, and yet 50% of the time I still get an error. hit the home button like 3 times and it'll finally home.. and then another 25% of the time it'll ignore the end switch and just try and keep going and get all clicking while trying to rip apart my printer. Sounds like it's an advantage to Deltas, but for me on the CoreXY it's really not. Still building/tinkering with the printer and often want to be able to move away from home to work on something, especially the bed. If I add a new nozzle say I want to be able to move away from home, change things, get things loose then home and adjust to bed height and such, now I have to slam it into the nozzle before I can do anything. Also if there is a glob of old drip on the nozzle, I have to heat it up,. clean it off, home the thing, then can move away. Or (like just happened to me) it homes, slams into the cold, hard glob and twists and breaks the hotend or mount.
Also, just a thought but wouldn't it have been better if the firmware update had updated the home files? Or make this feature apply when you enter the Delta option in the firmware and leave it alone for the rest?
-
If you mean that you want to allow axis movement before the axis has been homed again, that's easy. Just put M564 H0 in config.g.
-
@dc42 said in It's out! Firmware 1.21 released:
If you mean that you want to allow axis movement before the axis has been homed again, that's easy. Just put M564 H0 in config.g.
so that will return homing to back like it was before the update? I don't need the extra S2's all over the place?
-
@dc42 I have my Duet WiFi up and running very well, but this tweaking of the coding is somewhat new to me. I would love to be able to go back to moving before/without homing. Can you tell me where in config.g and what syntax if any for me to enter the M564 H0 command? Thanks!
Nice Forum BTW Everyone here seems cool and helpful. -
It doesn't matter where in config.g you put the M564 H0, but I suggest near the end.
-
Thanks a ton!
-
@dc42 said in It's out! Firmware 1.21 released:
It doesn't matter where in config.g you put the M564 H0, but I suggest near the end.
Seems to work great! thanks
-
what is the reason to why add the S2 on the G0 G1 for corexy?
-
in my 1.21 file print progress % calculation wrong
those 6 layers left hardly consumed more than 10 cm of filament.
-
@c310 said in It's out! Firmware 1.21 released:
in my 1.21 file print progress % calculation wrong
those 6 layers left hardly consumed more than 10 cm of filament.
Please provide the GCode file. Looks like it didn't manage to pick up the correct amount of filament required from the GCode file.
-
here is the gcode file done by slic3r
0_1523467244888_óãîëîê ëåñòíèöû.gcode
another thing is encoding of file name (now it is completely wrong. i guess it is about UTF... )
...file name in explorer - i removed card from duetwifi and put into win10 machine ...
-
Looks like Windows is displaying the filename in a local code page. DWC should handle Unicode if the installed font supports the particular characters. PanelDue supports Unicode characters up to 0x17F only.
-
@dc42
Yes, It is related to what slicer created the fileIf sliced with Repetier Host Cura, shown in the Generated by Cura_SteamEngin 15.01.
The error happens when calculation Object Height/Layer Height/ and Filament Usage.
Onec calculation is done only Object Height that has any data, Layer Height/ and Filament Usage has n/aAll other slicers I tried worked just fine Slic3r 1.2.9, Slic3r 1.34.1-prusa3d-win64, Sl1c3r 1.37.1-prusa3d-win64