I’m pleased to be able to make a major announcement!

KITS ARE ON THE WAY!

We’re partnering up with Project R3d to make RailCore II kits a thing.

What this means for the Open Source RailCore:
The RailCore will remain Open Source. The BOM, Build Guide, and fusion models will remain published as they are, and will be updated as we make changes. Nothing changes at all there, all future adding and improvements will be compatible with existing RailCores. The option of self-source building will remain available.

So what are the kits?
To the largest extent possible Project R3d intends to offer a “True to the BOM” 300ZL kit - the final components aren’t 100% done, and some minor changes will be necessary, but overall it will be the same RailCore you can get today, just with “one click shopping”.

What to expect in the kit:
Duet & Duex5 electronics will be included.
A wiring harness to simplify wiring to the Y carriage. Cables cut to length and pre-crimped.
Aluminum parts including the Bed, Stepper Mounts, Idler Plates, and X-carriages. (Still sourced from 713maker & Mandala whenever possible)
Various options for hotnends including E3dv6, Mosquito, or no hotend. (so you can “bring your own”)
Options for an extruder or a Bondtech BMG, or no extruder (so you can “bring your own”)
The bulk of the parts will look much as they do today - right off the BOM, and the printed parts done in Atomic filament (CF PETG for the structural parts).
Pricing is expected to fall between $1300 - $1700, and has not been finalized.
The timeframe for kits has not been finalized, but we're hoping within the next 1 - 2 months for the initial batch.
Project R3d will provide hardware support, J. Steve White & myself will continue to provide build support & continue with R&D to keep making the RailCore better. 713Maker & Mandala Roseworks will continue to be partners, without them we wouldn't be as far as we are.

Next steps are putting together a forum (we’ll move off of SeeMeCNC’s) to offer support & info (we’ll keep the Facebook group alive too) and work on touching up the documentation. The initial batch of 10 kits will be coming in the next few weeks, and will be used to test out the process, catch any issues, etc.

We’re looking for feedback from the community - what do you want in a kit? What questions do you have?

We’re looking forward to the partnership with Project R3d, and to see the RailCore II be made accessible to a wider audience!

Tony Akens
J. Steve White
Joe Podgorski - Project R3d

So, here's how I'm iterating through auto-tramming to level a RailCore. This can be cleaned up once we have variables, but even still, it's very cool (and confirmed working)!

First, to simplify, I moved my "G32" commands for probing the bed into a macro called "bedlevel". So I can use that like a function. (Feature request: can we send arguments to macros? Then they really would be functions!)

;bedlevel
;Call from auto-level Routine in bed.g

;Run initial 4 point leveling routine
G30 P0 X15 Y45 Z-99999
G30 P1 X15 Y275 Z-99999
;G30 P2 X275 Y150 Z-99999 S3
G30 P2 X275 Y275 Z-99999
G30 P3 X275 Y45 Z-99999 S3

Now that those commands are there, the following can go in your bed.g
The goal is to level across the bed to a deviation of < 0.01, and then do another round, and have that round within 0.005 of the previous. If not, it repeats.

M561                         ; clear any existing bed transform
; If the printer hasn't been homed, home it
if !move.axes[0].homed || !move.axes[1].homed || !move.axes[2].homed
  G28

;Move up 7.5mm in Z to clear the bed  
G1 Z7.5

;Run an initial auto-tramming
M98 P"/macros/bedlevel"

while true
  if iterations = 5
    abort "Too many auto calibration attempts"
  if move.initialDeviation.deviation < 0.01 
    if move.calibrationDeviation.deviation < move.initialDeviation.deviation + 0.005
      if move.calibrationDeviation.deviation > move.initialDeviation.deviation - 0.005
        break
  echo "Repeating calibration because initial deviation (" ^ move.initialDeviation.deviation ^ "mm) must be < 0.01"
  echo "and (" ^ move.calibrationDeviation.deviation ^ "mm) must be within 0.005 of initialDeviation"

  M98 P"/macros/bedlevel"

echo "Auto calibration successful, deviation", move.calibrationDeviation.deviation ^ "mm"
echo "Auto calibration successful, initialDeviation", move.initialDeviation.deviation ^ "mm"  
    
G28 Z

G1 X0 Y0 F24000

Since M204 can be changed for travel or printing moves, RRF is obviously making a distinction, likely based upon if a move is only in X/Y or if it adds an E value. So I'm wondering if M220 can also be applied only to printing moves, and not travel moves? Most times I just want to slow my print to allow for better cooling, but not slow my travel moves (and retractions, or firmware retractions anyway).

Similar results may be possible by other means, if so, I'm open to suggestions!

I did lots of testing on the railcore with various leadscrew couplers. (Two brands of spring style, two brands of rigid, two brands of the 3 part oldham couplers with the red plastic, and one brand of double disk diaphragm couplers).

I tested using my straightest leadscrews & some that were far less straight, in varying configurations. I used both printed and aluminum yokes (that tie our bed to the leadscrew & Z linear rails)

I found the following:

Spring Style - loudest. Cause Z artifacts on rapid z-hop, least consistent Z probes.
Rigid couplers - Worst transmitted artificats if you have a bent leadscrew. Also hard to align due to most of them having the grubs opposite each other.
Oldham - Best of the "common" couplers, quiet with the least artifacts transmitted. Cheap ones separate easily.
Double Disk - Overkill for common 3d printing use. Comparable print quality to the oldham couplers.

I now recommend folks go with good oldham couplers. Zyltech is a good source for them.

Hope this helps!

Edit: Oh, my test print is a spiral vase cylinder, only 30mm in diamater, at least half the height of the bed. Couplers transmitting wobble will show up as a wave pattern with the same period as your leadscrews, in my case 4mm.

Second edit: I've been told misumi sells even nicer oldham couplers, but I have not spent the $ to try them. Part # MCO15-5-8

Did some digging and turned up this:

https://www.ruland.com/resources/technical-articles/technical-article-servo-coupling

Indeed, I was using the wrong term for the ones from Zyltech. I'll leave my error to avoid confusion. (also, helpful article)

We're "officially" considering the Standard builds deprecated, in favor of the ZL models (250ZL, 300ZL, 300ZLT). I've marked the Build Guides & BOM's to reflect that, as well as updated the table on kraegar.com. I'll be updating thingiverse accordingly and re-organizing the files in line with this change.

The standard builds will remain published (fusion files, guides, BOM) as they are now, but I won't be making a continued effort to keep the links and information in them up to date.

This is being done because the vast majority of the interest in the RailCore is now geared towards the ZL, and it will save a lot of time to just focus on the documentation and BOM's for those models, as well as to plan future updates with only needing to worry about those designs.

So, I power my pi off of my duet3 currently, and it's troubling that when I reboot the pi there's a long delay while it boots before the hotend fan turns on. I know I can set the pi to be externally powered, but still, there will be that chance of a reboot while my hotend is at temp. What is the best option for dealing with this so we don't get heat creep during reboots?

The halo files will be released once they've been tested on a 300zl, and confirmed to work. Then I'll clean up a lot of cruft from the design, and publish it. Probably within a week or so of testing, depending on my work schedule.

Board: Duet 3
Firmware: RepRapFirmware for Duet 3 v0.5
Printer: RailCore IIZL (3 independent leadscrews)

Probing the bed and auto-tramming, the system never converges. It appears to over correct and vary the amount of tilt between two leadscrews. bed.g is 4 points and worked with RRF 2.x. on the same printer.

The relevant bits of config.g:

; Axis and motor configuration
M569 P0 S0 ; Drive 0 goes backwards X / Rear
M569 P1 S0 ; Drive 1 goes backwards Y / Front
M569 P2 S1 ; Drive 2 goes forwards Z Front Left
M569 P3 S1 ; Drive 3 goes forwards Z Rear Left
M569 P4 S1 ; Drive 4 goes forwards Z Right
M569 P5 S1 ; Extruder
M667 S1 ; corexy mode

M584 X0 Y1 Z2:3:4 E5 ; Map X to driver 0, Y to driver 1, Z to drivers 2,3,4. E to driver 5

;Leadscrew locations
M671 X-10:-10:283 Y22.5:227.5:125 S7.5 ; locations to pivot points, as measured

;BLTouch
M558 P9 C"io8.in" H5 R1 F50 T6000 A5 S0.02 B1
M950 S0 C"io8.out"
G31 X2 Y42 Z2.64 P25 ;

Bed.g:
M561
G30 P0 X10 Y43 Z-99999
G30 P1 X10 Y228 Z-99999
G30 P2 X195 Y228 Z-99999
G30 P3 X195 Y43 Z-99999 S3

Results:
9/9/2019, 3:12:10 PM Leadscrew adjustments made: -1.884 0.116 0.002, points used 4, deviation before 1.043 after 0.011
9/9/2019, 3:13:40 PM Leadscrew adjustments made: -1.844 0.153 -1.819, points used 4, deviation before 1.468 after 0.012
9/9/2019, 3:15:50 PM Leadscrew adjustments made: -1.887 0.114 -0.045, points used 4, deviation before 1.048 after 0.011

I tried going to 3 points in bed.g, and it gives similar results.

I did notice that the first adjustment always says a negative number, but when it gets to the point where it applies the adjustments, I can visibly see the 3rd (right) lead turn but not the first (front left). No adjustment to that leadscrew actually happens. I'm not sure on the second, it may be that correction is just too small to detect.

In case it will help anyone else out, now that things are working and I'm printing, this is my current RRF / Duet3 configuration:

G21						;Work in millimetres
G90						;Send absolute coordinates...
M83						;...but relative extruder moves

; Axis and motor configuration
M569 P0 S0					;Drive 0 X / Rear
M569 P1 S0					;Drive 1 Y / Front
M569 P2 S1					;Drive 2 Z Front Left
M569 P3 S1					;Drive 3 Z Rear Left
M569 P4 S1					;Drive 4 Z Right
M569 P5 S1					;Drive 5 Extruder
M667 S1						;corexy mode

M584 X0 Y1 Z2:3:4 E5			; Map X to drive 0 Y to drive 1, Z to drives 2, 3, 4, and E to drive 5
;Leadscrew locations
M671 X-10:-10:283  Y22.5:227.5:125 S7.5		;X -10, -10, 315

M350 X16 Y16 Z16 E16 I1				;set 16x microstepping for axes with interpolation
M906 X1400 Y1400 Z1200 E800 I60			;Set motor currents (mA)
M201 X2000 Y2000 Z100 E1500			;Accelerations (mm/s^2)
M203 X24000 Y24000 Z900 E3600			;Maximum speeds (mm/min) was Z1800 tr8*4
M566 X1000 Y1000 Z100 E1500			;Maximum jerk speeds mm/minute E60 Z60
M208 X240 Y240 Z230				;set axis maxima and high homing switch positions (adjust to suit your machine)
M208 X0 Y0 Z0 S1				;set axis minima and low homing switch positions (adjust to make X=0 and Y=0 the edges of the bed)
M92 X200 Y200 Z1600 E819.5			;steps/mm

; End Stops
M574 X1 S0 P"io3.in"				;Map the X endstop to io3.in
M574 Y1 S0 P"io1.in"				;May the Y endstop to io1.in

; Thermistors
M308 S0 P"temp0" Y"thermistor" A"bed_heat" T100000 B4240 H0 L0 		;Bed thermistor - duet 3, connected to temp0

M308 S1 P"temp1" Y"thermistor" A"e0_heat" T100000 B4725 C7.06e-8 H0 L0	;duet3 e3d
;M308 S1 P"temp1" Y"thermistor" A"e0_heat" T500000 B4723 C1.196220e-7	;duet3 slice

;Define Heaters
M950 H0 C"out0" T0				;Bed heater is on out0
M950 H1 C"out1" T1				;Hotend heater is on out1

M307 H0 A90.0 C700.0 D10.0 S1.00 B1 		;Keenovo duet 3 configuration
M307 H1 A548.8 C298.6 D4.6 S1.00 B0 		;Hotend  duet 3 configuration

M570 S360					;Hot end may be a little slow to heat up so allow it 180 seconds
M143 S285					;Set max hotend temperature			

; Fans
M950 F0 C"out4"					;Hotend fan on "out4" connector
M106 P0 S255 H1 T50 				;enable thermostatic mode for hotend fan
M950 F1 C"out5"					;Layer fan on "out5" connector
M106 P1 S0 					;Layer Fan

; Tool definitions
M563 P0 D0 H1 F1                       		;Define tool 0
G10 P0 S0 R0                        		;Set tool 0 operating and standby temperatures

;BLTouch
M558 P9 C"io8.in" H5 R1 F50 T6000 A5 S0.02 B1	;define the bltouch input on io8.in
M950 S0 C"io8.out"				;define the bltouch servo on io8.out
G31 X2 Y42 Z1.95 P25 ; 				;set the offsets for the bltouch

T0						;select first hot end

@Danal said in No output from G32 on DSF 1.2.4 / DWC 2.07:

Yay!! I'm still new with 3 motor beds, and it really helps to see the output. Yay!!

I strongly recommend using a script to auto level until it's under a set value, with a Z home at the end. I've been doing that with one of my printers, and it's been awesome. The other day I had a bit of filament stuck right where my probe hits one spot, and so it couldn't level correctly. It failed to level under my set value, so I went to check and found the filament. Might have saved me a bed surface!

@chrishamm said in No output from G32 on DSF 1.2.4 / DWC 2.07:

Glad it's working now. The issue with G32 not showing any output should be fixed in DSF 1.3.1, too.

Great news. I'll have to stop printing face shields long enough to upgrade and test!

Tried in chrome just to verify (I usually use Firefox)

@Danal Man, I'm stumped.

I had this reported by a user. I was running DWC 2.0.5 and DSF 1.2.3, and was getting output just fine. So we started troubleshooting. When I updated DSF to 1.2.4 (which upgraded DWC to 2.0.7) I "lost" the output on the console. Doesn't matter how I run it - I can hit the button in DWC, run G32 manually, or even run M98 P"bed.g" - I get no output for the adjustments made.

Duet Web Control 2.0.7
Board: Duet 3 MB6HC (MB6HC)
DSF Version: 1.2.4.0
Firmware: RepRapFirmware for Duet 3 MB6HC v0.6 or 1.0 3.01-RC1 (2020-02-08b3)

Just tried it, no change.

Upgraded from DSF 1.2.3 to 1.2.4 (which upgraded DWC from 2.05 to 2.07 as well), and running my bed.g no longer gives any output in DWC.

RRF 3.0 on a duet3

I have a config for a RailCore II / Duet 3 / SBC that's compatible with 3.0 or 3.01 here:
https://www.dropbox.com/sh/pg0ugu5qunokjc9/AAD8PkPqVGPp-yWV5Cug3_Usa?dl=0

Some sample conditional gcode examples here: https://www.dropbox.com/sh/gb8v16bgmyzq78t/AABgqjcDaqf4cLirguvjDlFfa?dl=0

Been printing steadily and haven't seen any issues to report yet. Still tinkering with conditional gcode

I couldn't get abs to work either, so just nested the if statements. Ugly, but I figured it was something I was doing wrong. Also testing on a duet2.

@deckingman I wouldn't worry too much just yet...

Now when variables arrive, then we're talking!