RepRapFirmware 3.0
-
The expansion board doesn't have an ext 5V input.
-
This post is deleted! -
I have made new builds of RepRapFirmware 3 available:
Duet WiFi/Ethernet: https://www.dropbox.com/s/fyvibzm0zl92hiy/Duet2CombinedFirmware.bin?dl=0
Duet Maestro: https://www.dropbox.com/s/m0r3ldy424mxf4v/DuetMaestroFirmware.bin?dl=0As before, use these with caution! In particular, test your endstops and Z probe before relying on them. See https://duet3d.dozuki.com/Wiki/RepRapFirmware_3_overview for required configuration changes.
The Duet Maestro build also has some improvements to the menu system:
- Fan speeds, print speed modifier and extrusion rate modifier have '%' displayed after them automatically
- New item 534 is the current IP address in one go (to replace items 530, 531, 532 and 533)
- New item 535 is the percentage of the current SD card file completed
- New item 536 is the estimated print time remaining, based on the percentage of the file that has been completed
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 said in RepRapFirmware 3.0:
@catalin_ro said in RepRapFirmware 3.0:
Even with the new firmware I would have to separate the two axis for the G0 Y0.09 command that compensates for the difference in switches positions. It would be nice to have, maybe only during homing and only while in relative mode, the possibility to issue a command like G0 Yaaa:bbb (the final retract, after the slow speed pass, a single G0 Y1.09:1.00 would handle the situation, combining the precise gantry alignment with the small retract). Alternatively, a solution for specifying a per axis alignment offset would be equally good, with immediate compensation through applying the corresponding number of steps.
That could be done, but it's a lot of work to do for just one or two users. It is really that difficult to adjust one of the endstop positions or add a shim to get them both to trigger at the same point?
Well, trying to achieve such a precision (0.09mm) when positioning the homing switch is really tricky, at least with classical mechanical switches. There are some cylindrical ones, similar to the NPN/PNP sensors and those can be indeed positioned very precisely. On the other hand, I'm on the same wave length with you - it is not worth making something really special for just few users as long as the solution already exists and it requires just a few extra lines in a macro. Things get significantly simpler by having to do the split, precise tune and recombine of the axis only for the alignment difference.
In my dual Y axis setup I have also installed limit switches (connected in series to the homing ones) to handle possible configuration problems and missed steps. If an axis has multiple steppers and multiple homing switches, will the M581 defined triggers handle them properly?
RRF 3 doesn't yet implement M581. I intend to change M581 to work with a single input, also I will add a facility to cause an emergency stop if any axis endstops are triggered unexpectedly.
The idea to specially handle the homing/limit switches is the best from my point of view. If it would trigger a macro, if present, instead of the emergency stop, it would be even better. There might be situations when hitting an endstop requires special action or, on the contrary, none at all (I have messed up myself quite a few jobs by mistakenly touching one of the endstops!) - after all the spindle end everything else could be stopped through the macro and the user could be asked for possible actions through some messages.
The special handling of the endstops also simplifies the homing scripts because of the no longer required M581 commands!
-
@dc42 said in RepRapFirmware 3.0:
It's difficult to find 5V buck regulator chips that accept higher than 40V input.
How about takeing 2 stages? 40V->buck to 12V-> buck to 5V
Many uses 12V fans and LED's and other accessories, it was one of the main selling points for me for the duex5 -
Metrol offers switches with repeatability as small as 1 micron. I’m using 3 micron repeatability switches. Sure, they cost a bit but if you only need one it’s reasonable. Like $60 usd iirc for 3 micron.
*not actually a robot
-
This may be already implemented but I've not seen it explicitly stated.
On a RailCore, because a single motor causes a diagonal move, it is possible to install two limit switches, probably Y axis and then move to home the Y axis so it is perpendicular to the X axis?
Furthermore, can there be an homing switch offset to compensate for the likely case where the two limit switches are not in exactly the same relative position so when the carriage is homed, it can be made perpendicular?
-
@bot said in RepRapFirmware 3.0:
Metrol offers switches with repeatability as small as 1 micron. I’m using 3 micron repeatability switches. Sure, they cost a bit but if you only need one it’s reasonable. Like $60 usd iirc for 3 micron.
Omron also has some very precise ones. But what would you use it for? If the motors are strong and do not loose steps within one print, it would not matter if the next print after a restart is slightly on a different place on the plate, or?
-
@lb said in RepRapFirmware 3.0:
@bot said in RepRapFirmware 3.0:
Metrol offers switches with repeatability as small as 1 micron. I’m using 3 micron repeatability switches. Sure, they cost a bit but if you only need one it’s reasonable. Like $60 usd iirc for 3 micron.
Omron also has some very precise ones. But what would you use it for? If the motors are strong and do not loose steps within one print, it would not matter if the next print after a restart is slightly on a different place on the plate, or?
I use a Metrol precision switch on my Z axis where it most certainly is important that homing is accurate.
-
Yes, in most cases it is not necessary. I need to align two idex print heads, and so I chose to do it precisely the first time every time.
I also used them for all my homing switches. This should allow me to re-home the printer, in the case of power failure or something, and continue printing without being more than 3 microns off, in theory. In reality, the switches' positions will differ by more than 3 microns due to thermal expansion alone, if the ambient temp increases or decreases, but it's easier to control ambient temp than variability of a cheap microswitch.
-
@dc42 said in RepRapFirmware 3.0:
I have made new builds of RepRapFirmware 3 available:
Duet Maestro: https://www.dropbox.com/s/m0r3ldy424mxf4v/DuetMaestroFirmware.bin?dl=0Initial testing shows endstops, probing, motion, fans and heaters work as expected. Actual printing to follow, but waiting on some warranty replacements from Tiertime for that to work.
-
@bot said in RepRapFirmware 3.0:
Metrol offers switches with repeatability as small as 1 micron. I’m using 3 micron repeatability switches. Sure, they cost a bit but if you only need one it’s reasonable. Like $60 usd iirc for 3 micron.
I have not argued about the switch repeatability, even the relatively low cost switches always insure the same position within 0.01mm. But installing them on the two Y axis (in my case!) in order to perfectly square the gantry is beyond tricky.
-
@veng1 said in RepRapFirmware 3.0:
This may be already implemented but I've not seen it explicitly stated.
On a RailCore, because a single motor causes a diagonal move, it is possible to install two limit switches, probably Y axis and then move to home the Y axis so it is perpendicular to the X axis?
Furthermore, can there be an homing switch offset to compensate for the likely case where the two limit switches are not in exactly the same relative position so when the carriage is homed, it can be made perpendicular?
That is exactly my case! The big X-axis gantry (now it probably weight a little above 20kg - this a CNC after all!) has a very small, rather difficult to measure directly, error from perfect 90 degrees. But it can be seen on small rectangular machined pieces using a professional 90 deg reference. Specifying an offset of the homing switch might be an interesting solution. For now I'm handling it exactly as shown in one of my previous messages.
But the problem can be perfectly handled with Duet3D only in the case of multiple stepper on each axis. With just two steppers for handling both X and Y axis (like in the RailCore configuration), perfectly squaring the gantry is impossible. It could be only if on each linear guide on the dual axis there would be two carriages, significantly spaced apart, or longer carriages are used.
-
@lb said in RepRapFirmware 3.0:
@bot said in RepRapFirmware 3.0:
Metrol offers switches with repeatability as small as 1 micron. I’m using 3 micron repeatability switches. Sure, they cost a bit but if you only need one it’s reasonable. Like $60 usd iirc for 3 micron.
Omron also has some very precise ones. But what would you use it for? If the motors are strong and do not loose steps within one print, it would not matter if the next print after a restart is slightly on a different place on the plate, or?
Again, this is a CNC and it is about insuring perfect 90deg between the two Y-axis and the X-axis. Also, in the CNC world it is not unusual to install various fixtures in several places on the machine and measure precisely their position only once. The steppers, once the machine is started, are kept energized indefinitely and the position quite precise after a proper homing.
-
Fair point. I wasn't specifically referencing your case, but just adding general comments about switch repeatability. In the case of needing to square the y axis, I think two metrol (or similar) switches could work. Just place the switches close enough to the same point on each side, and then determine the correct offset and input that into firmware and call it done. It would be repeatably square within 3 microns, depending on how securely and precisely you can affix the switches relative to one another and the y axis. (Edit: this would require making virtual axes, and assigning each side to a different axis for homing.)
That being said, is your Y axis not stiff/rigid enough to be driven on one side only, while maintaining perpendicularity to the X axis? Even if not, you could still drive both sides by one motor, coupling the two sides mechanically, eliminating the need to adjust perpendicularity with two motor positions.
*not actually a robot
-
@Catalin_RO
You are probably familiar with this trick considering how long you have been working with CNC. Mill or print a maximally sized L square or carpenter's square and then use it to draw a line on a piece of paper with a pencil along the side of L square at a right angle to one edge of the paper. Then flip the square, align it with the same pencil edge and and attempt to draw a line over the previous one. If the are congruent, the CNC or printer is square. If there is a gap at the far end, they the machine is not square. Only an exact 90 degree angle will cause the lines to be the same if the square is flipped. No expensive measuring equipment is required!So, given a software offset for the individual homing switches, adjust the offset until there is no gap at the far end.
-
@bot I am using the virtual axis split, align and re-combine for about a year already. So this is something that I pretty much understand and accept. The fact that the new firmware simplifies a little bit the homing scripts is a very good thing, but it won't make such a huge difference for me. Again, being mostly a software developer myself and considering that the configuration scripts for the Duet are mostly a one time job (well, until you change some hardware), I think that the current situation is more than OK.
As for the two Y axis stiffness, the WorkBee that I have is 750mm*750mm, so pretty large. Now it has proper linear guides on the two Y axis, and that makes things better. But, still, the distance covered by the carriages is less than 20cm so a single screw would not insure proper alignment even if placed in the center (most professional sites indicate a 2:1 rule, so the carriages should cover at least 37-38cm). Running a belt to drive both screws with the same stepper might have worked, but it would have made the mechanics a little bit more complex.
@veng1 I have professional grade machinist squares as I have used them for aligning various things over time, not related to CNC. So no need for any other tricks. As for the offset between the switches on the twin axis, I have precise mechanical reference points and I use calipers for determining those offsets. So far that has always provided the desired results!
-
I also have said professional measuring tools and assumed you did also based on some of our earlier conversations but I was describing a test approach that anyone could implement to check squareness.
-
@dc42 - Well done on the 3.0beta release!
I love the labels vs pin numbers change. Beginners will appreciate it and it will make things easier to follow in posts about problems. +1 to @deckingman's post using names instead of just designators. "Heater0" makes more sense than "H0". Being that config.g is not changed often it would be easier to come back to as well. I suspect it would grow config.g's file size, but I doubt that would be a problem. Would processing time be increased because of the larger words? I can see that being a factor.+1 for @brunofporto 's idea of a Migration tool, I get the "sanity checker" reply, it would be a great boon to avoid stupid slip ups in the conversion.
Being fairly new at this, I'll wait until it's a bit more mature to try it out, but will weigh in for the fairly large "converted machine" (CR-10S) crowd on the next release if I can. You need to hear from the average Joe's too ... LOL
@veng1 said in RepRapFirmware 3.0:
I also have said professional measuring tools and assumed you did also based on some of our earlier conversations but I was describing a test approach that anyone could implement to check squareness.
Thanks for this, I, for one, was glad to be reminded of this. I have a couple pro grade squares, but tiny differences are easily caught using this method. I had forgotten it, thx!
-
@dc42 More out of curiosity than necessity:
on GitHub I can see work currently only being done in thev3-devbranch and 2.03beta development has "stopped" (as far as public commits on GitHub are concerned).Will there be a 2.03, 2.xx, ... of RRF or does this mean the next version will be 3.0?
P.S.: I really like the flexibility that RRF 3.0 will provide.
