RepRapFirmware 3.0

Catalin_RO

@bot said in RepRapFirmware 3.0:

@catalin_ro

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.

bot

@catalin_ro

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.

veng1

@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.

Catalin_RO

@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!

veng1

@Catalin_RO

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.

PuterPro

@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!

wilriker

@dc42 More out of curiosity than necessity:
on GitHub I can see work currently only being done in the v3-dev branch 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.

dc42

I plan to do a 2.03 release but it will be essentially 2.02 with bug fixes. Some of the new features in the existing 2.03 beta releases will be removed.

A Former User

@dc42 said in RepRapFirmware 3.0:

I have made new builds of RepRapFirmware 3 available:

Seems G1 S3 is different on 3.0 with a Duet 2 Maestro (cartesian)

If i do
G0 Z5
G1 S3 Z400

I get a Z value of whatever was stored in M208 regardless of where I trigger the end stop. Same if I use H instead of S. On 2.02 release it gives me the correct Z height for whatever posittion I trigger the endstop at (which the wiki lead me to believe was only for delta printers)

(I also notice there is no longer a DuetMaestroFirmware.bin for the 2.02 release, but the Duet2Firmware-2.02b.zip gets the job done I guess)

dc42

@bearer said in RepRapFirmware 3.0:

@dc42 said in RepRapFirmware 3.0:

I have made new builds of RepRapFirmware 3 available:

Seems G1 S3 is different on 3.0 with a Duet 2 Maestro (cartesian)

If i do
G0 Z5
G1 S3 Z400

I get a Z value of whatever was stored in M208 regardless of where I trigger the end stop. Same if I use H instead of S. On 2.02 release it gives me the correct Z height for whatever posittion I trigger the endstop at (which the wiki lead me to believe was only for delta printers)

Thanks for reporting this. I will fix it in the next release.

A Former User

@dc42 said in RepRapFirmware 3.0:

@bearer said in RepRapFirmware 3.0:

@dc42 said in RepRapFirmware 3.0:

I have made new builds of RepRapFirmware 3 available:

Seems G1 S3 is different on 3.0 with a Duet 2 Maestro (cartesian)

If i do
G0 Z5
G1 S3 Z400

I get a Z value of whatever was stored in M208 regardless of where I trigger the end stop. Same if I use H instead of S. On 2.02 release it gives me the correct Z height for whatever posittion I trigger the endstop at (which the wiki lead me to believe was only for delta printers)

Thanks for reporting this. I will fix it in the next release.

On that note, would it be worth while having M208 without parameters show the current values? Probably most usefull for testing as opposed to opening the config-overide.g file.

dc42

@bearer said in RepRapFirmware 3.0:

On that note, would it be worth while having M208 without parameters show the current values? Probably most usefull for testing as opposed to opening the config-overide.g file.

It already does!

The general rule with RepRapFirmware is that a command without parameters, or with just the parameter to select which of several instances you want, reports existing values.

Examples of commands that report values when no parameters are provided:

M201 M203 M204 M207 M208 M302 M564 M572 M574 M584 M906 M913 M915

Examples of commands that report existing values when just the instance selection parameter (e.g. tool number, drive number, heater number) is provided:

M305 M307 M569 M591

A Former User

Odd, I was sure I tried that as you say it seems to be the norm. It does it now for both 3.0beta and 2.02.

A Former User

0_1557346956321_32e04b68-8f62-482a-9ac7-322053c27cf1-image.png

It only shows the output from M208 if you run it from the G-code console. The quick g-code thing at the top will run the command, but the output gets truncated in the log, even when the console is otherwise showing.

Dougal1957

@bearer Which version of DWC are you running I think there was a few issues like this with the early V2 releases

A Former User

@dougal1957
Duet Web Control 1.22.6 (as distributed with Duet2Firmware-2.02 release)

dc42

I'm sorry, I can't reproduce that. The GCode Console shows the reply whichever box I enter it in. I tested with DWC 1.22.6 and with 2.0.0RC6.

Alexander Mundy

I'm at the stage of commissioning a new Delta with a new Duet 2 wifi board (don't have the towers installed yet but the base is done) and figured I might as well start a clean slate with 3.0. I installed the beta firmware and updated to the latest wifi server and web interface. I have printed out the wiki overview but if someone has a working delta config.g that they would share for me to look at while I try to config this new printer to 3.0 it would help.

gtj0

@dc42 Bed levelling via G32 S3 doesn't seem to be working.

bed.g:

M561
G29 S2
G1 F600
G30 P0 X0 Y3 Z-99999 ; probe near a leadscrew
G30 P1 X227 Y455 Z-99999 ; probe near a leadscrew
G30 P2 X455 Y3 Z-99999 S3 ; probe near a leadscrew and calibrate 3 motors
G1 F2400
M98 Phomexy.g

When run, the 3 points are probed and the results displayed...

Leadscrew adjustments made: 0.086 -1.598 -0.980, points used 3, deviation before 1.027 after 0.000

But the 3 Z motors aren't actually activated to effect the changes needed.

Running v3-dev branch as of today.

dc42

@alexander-mundy said in RepRapFirmware 3.0:

I'm at the stage of commissioning a new Delta with a new Duet 2 wifi board (don't have the towers installed yet but the base is done) and figured I might as well start a clean slate with 3.0. I installed the beta firmware and updated to the latest wifi server and web interface. I have printed out the wiki overview but if someone has a working delta config.g that they would share for me to look at while I try to config this new printer to 3.0 it would help.

I didn't have to make any config changes to run RRF3 on my delta. The same is likely to be true for you unless you use a Z probe whose output is connected to an endstop switch instead of to the Z probe IN pin.