RepRapFirmware 2.03beta1 available
-
in that case was the S-2 param a typo?
-
No, that's correct: it adjusts the Z offset of the current tool. You can use M500 to save the new G10 command.
-
no conditional, for the moment or for version 2.03?
-
@nicolab28 said in RepRapFirmware 2.03beta1 available:
no conditional, for the moment or for version 2.03?
Not yet. In view of the large number of small feature requests that have come in recently, I plan to do an early 2.03 release, and I have postponed conditional GCode and and remainder of the implementation of S-curve acceleration until 2.04.
-
@dc42, in your opinion (and I'd never hold it against you), how stable is this for delta printers in particular? It appears that the larger changes are for core and cartesian printers, but I'm not familiar enough with the RRF code to understand how that might impact delta printers.
My reason for asking is that I'd love to have the M36 changes and add support in the paneldue firmware to display the simulation time estimate (if available) instead of the layer estimate.
However, I only have a single delta printer (and I use it a lot), so I need it to be fairly reliable.
As an alternative, I could probably cherry-pick just the M36 changes, but then I'd need to set up an environment for recompiling the full RRF...
Thank you
Gary -
It's working fine on my delta. The changes I made to delta printer kinematics were fairly minor, mostly two things:
- The code to handle endstop corrections has changed a little;
- If the print height gets to the point at which not every XY point can be reached at that height, the firmware spends more time than it used to checking that each move can be made without any of the carriages hitting the endstops.
-
On my cartesian with 2 independent Z axis for bed leveling the numbers don't converge as they do with 2.02.
19:56:12: : Leadscrew adjustments made: -3.296 -0.516, points used 2, deviation before 2.035 after 0.000
19:55:35: M98 P""0:/macros/X Axis callibration"": Leadscrew adjustments made: -2.407 -0.295, points used 2, deviation before 1.458 after 0.000
19:54:52: : Leadscrew adjustments made: -1.442 -0.159, points used 2, deviation before 0.868 after 0.000
19:54:19: M98 P""0:/macros/X Axis callibration"": Leadscrew adjustments made: -0.568 0.256, points used 2, deviation before 0.288 after 0.000
19:53:48: G28
19:53:08: G28
19:52:42: Connection established!
19:52:42: Page Load complete! -
@boldnuts, thanks for reporting this. Unfortunately I won't be able to look into it until next week due to other commitments. So I suggest you revert to 2.02 for now.
-
@boldnuts said in RepRapFirmware 2.03beta1 available:
On my cartesian with 2 independent Z axis for bed leveling the numbers don't converge as they do with 2.02.
19:56:12: : Leadscrew adjustments made: -3.296 -0.516, points used 2, deviation before 2.035 after 0.000
19:55:35: M98 P""0:/macros/X Axis callibration"": Leadscrew adjustments made: -2.407 -0.295, points used 2, deviation before 1.458 after 0.000
19:54:52: : Leadscrew adjustments made: -1.442 -0.159, points used 2, deviation before 0.868 after 0.000
19:54:19: M98 P""0:/macros/X Axis callibration"": Leadscrew adjustments made: -0.568 0.256, points used 2, deviation before 0.288 after 0.000
19:53:48: G28
19:53:08: G28
19:52:42: Connection established!
19:52:42: Page Load complete!I have the same problem with bed levelling.
With 2.03b1 the 2 independent Z axis levelling moves are divergent.
Reverted back to 2.02 and levelling works correctly. -
@insertnamehere, thanks for confirming this fault.
-
RRF 2.03b1, WifiServer 1.23b1 Possible issue or regression with the new firmware (or the new wifiserver):
I had to reboot all my access points this morning twice and afterwards I found that my duet/wifi (board 1.04) wasn't auto-reconnecting to the wifi. The PanelDue console display showed the first disconnect and reconnect, and then showed "lost connection, auto reconnecting" followed by "timeout trying to connect."
I thought that newer versions would endlessly keep retrying to reconnect.
After I used a macro that stops/starts the wifi module, it connected fine.
I've attached a picture of the PanelDue console page after restarting the wifi module:
-
Hello!
Wow! I've been away for a bit but I came back today for some software updates and I noticed one line in the new firmware notes that grabbed me.
"Support for additional towers on delta printers (up to 6 in total)"
I spent many years on the road as an operator with the Skycam (Flying Camera on Wire System) for the Olympics, NFL, NBA, etc. and it's a four-point system with the four reels arranged in a square or rectangle all sending cable out to a camera spar (and a bunch of other stuff, blah blah).
One reason I made my giant delta printer was it reminded me of a three-point Skycam.
By creating the ability to use four or more towers/motors, you have opened up another use for the Duet 3D which is creating and controlling hardware for camera systems.
Did I read the notes right? We can make delta systems with four motors and towers - "quad printers"?
Thanks!
A
-
Yes you could do that.
Duet WiFi hardware designer and firmware engineer
Please do not ask me for Duet support via PM or email, use the forum
http://www.escher3d.com, https://miscsolutions.wordpress.com -
@dc42 That is so exciting.
Another new project. Ha!
Will there eventually be some additional documentation on how to configure things?
If you have four motors for movement with a fifth for the extrusion head, will the "Machine Status" list the motors as numbers or how will that be visualized (Instead of X, Y, Z .. 1,2,3,4)?
Very exciting!
Thanks,
A
-
How to configure more than 3 towers is already documented, at the end of the wiki page on confguring RRF for a delta printer.
-
Thanks!
A
-
Good. thanks.. ^
-
CoreXZ working as normal so far. Took a little bit to work out the matrix thing within M669 but working as expected. Also stall detection is working for me, had to increase the sensitivity of one of my additional axes which wasn't a problem. And no issues so far with the wifi server
