From today, DWC SBC is supported natively in Repetier Server version 1.1.0.
Is the Repetier Server first support for DuetControlServer as connection method. It requires RRF version 3.3 or newer. There's an RPI image (V26) with both systems preinstalled in their website.
Both the DWC and the Repetier Server web environment are maintained simultaneously, accessible through different ports.
I hope you find it interesting.
We have solved the problem of HRP and tool offsets.
The problem was that we made relative and absolute incompatible movements in the homing.
We solve it by moving the probe to the X Y coordinate where the X0 Y0 should be in the homing process and after this, make G92 X0 Y0 where G31 is the probe X0 Y0.
From there, we were able to establish that point as HRP and to be able to establish the offset of the toolheads.
It was silly 
@oliof Yes, its a different frontend that has some usefull things DWC still haven't (user permits and passwords protection, network control, easy usage for unskilled personel, timelapse and extensive reporting, repositories....)
All without loose any of trusty DWC usage.
These days we are going to test the DUET 1XD controller specifically with the OrientalMotor AZM66AK and the AZD-K controller. It is the potentialy simplest option we have found to use real closed loop in the Duet ecosystem.
We need to receive a controller to adapt the control signals from 24V to 5V and viceversa for Go-to-Home (IN) and Alarm (OUT) signals. We are still not sure how to integrate these signals into RRF, but we will put the results in the forum in a few days.
@dc42 Thanks David anb @gloomyandy
In some situations the syringe needs to get 20mm/sec linear speed. I don't know if we can achieve that with a 2mm lead, we would have to give it a try.
We are testing with higher currents (1350mA so far) but still having a few step losses in a batch print.
W e have concluded that the problem we have is due to the density of the material and the back pressure generated at the nozzle (1mm). With more liquefied materials we have no problems.
@dc42 Yes, I understand David. It is something with which we will have to find the balance point.
Ideally, DWC would have all the functionalities that we can have with Repetier Server, which are quite a few. In fact we would like to mantain the standard DWC frontend for tech support, but final customer only need to see what it's relevant for their unskilled task.
We would have to do a totally scratch development to have a fully functional client frontend under your environment, which at this time is not possible due to time and lack of enough human resources. We have urged our developers to learn all this stuff, which is new to all of us, but customers don't want to wait for our learning curve.
We did it for Marlin FW printers and Repetier Server (web and touch UI tailor-made for this type of user).
There are items that I don't even know if it would be possible to get, as authentication and user permissions, network control panel (wifi/cable/domains/IP manual configuration...), print history and reports, white label touchscreen UI customization...that we did in Repetier Server.
We are just starting with RRF and Duet3D; and rise up our knowledge with this very first machine, but we expect to get the expertise to have all the client requests fullfilled in the future with this ecosystem, because it has proven to be more flexible than Marlin at this moment plus the Duet hardware quality.
Meanwhile, we will continue to annoy asking questions that are surely very obvious to all of you. We appreciate your help 
Hi @oliof
I intend to hide or make inaccessible to the user the entire contents of the system folder.
It would be simple if DWC could work with two permission levels, user and administrator. The user can NOT see or change any of the system code.
Another option would be to be able to encrypt the content, but I think that would be more complex.
We are studying the possibility of making a custom DWC frontend from scratch with all our needs, but it is a huge task. Think that we have to apply this to a commercial machine, where the user doesn't even have to know what's behind it.
Microdosing of drugs and biochemicals. And other things like inkjet heads, spectrographs in the future ...
@benecito I had the same problem for a syringe extruder. After having followed the recommendations of the forum, I changed the trigger M581 for the filament sensor M591, in addition to increasing the segmentation of the print buffer.
M669 K0 S100 ;increase fragmentation to 100 segments for second.
M591 D1 P1 C"21.io0.in" S1 ;Trigger pause when "filament" is empty.
With this setting I have been able to make printing pause when the syringe runs out. In a file "filament-error.g" that is executed upon reaching pause, I execute the functions that I need at the time of trigger that endstop.
@chrishamm Thanks Christian, it makes sense. This is not usually a problem for people in general, as waiting a few seconds longer is not a decisive factor, but in some automated processes, gaining seconds is vital for us.
I will discuss with our client whether dealing with you privately and confidentially on this matter could violate the NDAs signed with them.
I don't think there will be a problem. In the end it benefits all of us.
Best,
After receiving a new Oriental Motor Driver, and tested with 1XD homing works as expected.
I can say there is a real Closed Loop system that works with Duet. It isn't cheap at all, but really accurate and robust industrial grade motor and driver for anyone searching a real closed loop system.
There wasn't a config error on Duet config.g when we did M574 X1 S1 P"!40.io0.in" because it worked this time. Maybe a error or fail in the other driver.
Now it stops at exactly the step=0 feedback from the driver and notify RRF the endstop trigger. The connection was directly from pinOUT home signal from the driver io0.in and gnd. No boards, relays or signal level converters in between.
Still wondering how the first time we tested with the other driver didn't worked, but we will investigate it.
Now we need to see how to "M84 disable motors" can trigger the Free move function in the OM driver, but it isn't mandatory to get full working machine.
We are happy 
@fcwilt Interesting. We will check if that situation could been happening with the variables involved in obtain the Z min limit.
Also we changed the surface for other one that we know it has high and low areas to get more info about this behaviour.
@MikeDC @Phaedrux Have a look at the David's answer in our thread about CAN delays with external boards:
@dc42 said:
I have put preliminary firmware that resolves this issue at https://www.dropbox.com/sh/cx760ysonlzzkjd/AACfsVfX4olHipuqmbWut5EKa?dl=0. Please test this firmware with care because I have only tested it using Duet 3 MB6HC + EXP3HC (the Z motor was connected to the EXP3HC).
If you are running your Duet with an attached Raspberry Pi then you must upgrade to RRF 3.4.0beta7 from the package server BEFORE you use these files.
Unfortunately we couldn't test it yet, so it's a good start point to see if this issue is addresed.
Best,
@code7 We sucesfull use Oriental Motor AZD-K series absolute enconder pulse-input type motor driver with a 1XD board.
https://www.orientalmotor.eu/Products/Stepper_motors/Closed_loop_stepper_motor_packages/az_dc/?&filter1=Standard&filter2=60+mm&feld040=0&arid=22968&dwn=artnr
Config example:
;######################### AXIS BOARD DRIVERS DECLARATIONS #########################
M569 P40.0 S1 ; physical drive 40 goes forwards X
M569 P41.0 S0 ; physical drive 41 goes backwards Y1
M569 P42.0 S0 ; physical drive 42 goes backwards Y2
M569 P43.0 S0 ; physical drive 43 goes backwards Z1 (Z)
M569 P44.0 S0 ; physical drive 44 goes backwards Z2 (U)
M569 P45.0 S0 ; physical drive 45 goes backwards Z3 (V)
; ############################## DRIVER PARAMETERS SETTINGS ##############################
M584 X40.0 Y41.0:42.0 Z43.0 U44.0 V45.0 ; axis drive mapping
M350 X1 Y1 V1 Z1 U1 V1 I1 ; configure axis microstepping with interpolation
M92 X150.53 Y150.53 Z100.12 U100.12 V100.12 ; axis steps per mm
M566 X900.00 Y900.00 Z500.00 U500.0 V500.0 ; set maximum instantaneous speed changes (mm/min)
M203 X18000.00 Y18000.00 Z12000.00 U12000.00 V12000.00 ; set maximum speeds (mm/min)
M201 X300.00 Y300.00 Z500.00 U500.00 V500.00 ; set accelerations (mm/s^2)
;################################# AXIS ENDSTOPS #################################
M574 X1 S1 P"!40.io0.in" ; configure active-high endstop for low end on X via pin 40.io0.in
M574 Y1 S1 P"!41.io0.in" ; configure active-high endstop for low end on Y via pin 41.io0.in
M574 Z2 S1 P"!43.io0.in"
M574 U2 S1 P"!44.io0.in" ; configure active-high endstop for high end on U via pin 44.io0.in
M574 V2 S1 P"!45.io0.in" ; configure active-high endstop for high end on V via pin 45.io0.in
1 - Step area defined in the axis as virtual "endstop"
2 - Step and dir signals to motor driver
How possible would it be to interface a laser profilometer (Keyence, Baumer, etc) to Duet3D, to be able to substitute any process Z offset, Z home, heighmaps and other Z measurements.
I mean something with more precision than the "lidar" used by BambuLabs on the Carbon X1E.
I know these sensors are very expensive, but how complicated would it be?
It would be appreciated if anyone has an idea.
@dc42 Hi David
We've tested the 3.4RC+2 files from your Dropbox link in our printer and it worked. This problem is solved.
Currently we have main 6HC with 3.4RC1 fw, DWC 3.4RC1, all boards 1XD and LC1 with 3.4RC1+2. Tested standalone, not in SBC due to global RPI shortage.
For the moment we have not found any other problems with this version.
Any update about the implementation of this topic?
May the 3.4 stable version have this feature?
Thanks!