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,
@dc42 Thanks David.
As a starting point, it seems quite feasible with the clues you provide.
In fact, we were thinking of treating the measurement obtained by the laser as a differential with respect to a known ZMax which is always the same (SMC LESYH16 axes with encoder). With this measurement, we know the distance of the Z axis without the need to create a new type of probe.
But that solves only a part of the possible range. The problem is that we also have to measure the printing tip with respect to that surface and that it also has an offset, so the use of a point laser is not going to solve the problem. We are going to have to think about implementing at least two, one oriented downwards in the Z gantry, and another upwards/sideways to know the distance of the tips. The printheads are interchangeable and several types and shapes.
This is quite complex, and the hardware required is no longer limited to some €470 sensors, but implementing laser profilometers is going to be a major cost apart from software development and RRF.
We will try to do something and see what we can find out. Thank you very much.
We found a "cheap" version from Micro-Epsilon, 470€, that could be a easy approach to non-contact sensing for Z and bed. Let's see what we are able to achieve.
https://www.micro-epsilon.com/distance-sensors/laser-sensors/optoncdt-1220/
@timschneider Those operating at a distance of about 30-50 mm with accuracies of less than 0.05mm are priced at about 3-5K€. Mostly designed for PLC environments. We have some experience using RS485, but not much experience with Modbus.
We are convincing the customer to buy a unit that we can use to develop and test this solution, but where we don't quite see the integration is in Duet3D, how to use a certain measurement to get the Z to the right height.
Now we use a zMax endstop (an encoder position) and set the distance to zMin of Z with respect to a retractable probe. We need to be able to remove all physical contact to make home and to calculate the surface of Zmin. That's why we are thinking about the profilometer, and also to be able to make more complex and precise topographies, to ‘3D-dodge’ certain objects in the printing area.
I believe that until we are able to test these lasers directly, we will not be able to draw conclusions about their integration and usefulness.
Thank you for your input.
@droftarts Thank you for your interest.
https://www.keyence.com/products/measure/laser-2d/lj-x8000/specs/
It could be something similar to these two profilometers. We are, at the same time, looking for similar cheaper options, because these are exorbitantly expensive.
Our intention would be to be able to set all Z offsets, home Z and bed topography with this kind of non-contact, solid-state solution.
Additionally, to use it for print quality control.
It will be an industrial AM use, so it is far away from consumer solutions, hence it compensates an important economic effort for both HW and SW development.
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.
@chrishamm Thanks Chris and @oliof We use in SBC mode, and making the files read-only has given us problems (I can't remember now exactly what the error was).
I think we are going to have to opt for a customised DWC, something we didn't count on in our gant tree.
However, we do need to allow access to the console to see events and errors in order to provide user support, so cannot be fully armoured. Also calls to object model to get some variable values; it's not going to be a straightforward thing.
If users are not able to see or copy the software we have programmed, that should be enough.
In any case, any IT guy with the desire to obtain this data at any cost would not have too much difficulty.
Thanks for your advice
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.
Hello to all,
Is there any way to restrict the DWC user from accessing the system menu? We need to shield the configuration files from modification and/or viewing the content of these files. At least with a simple password.
On end-user machines, there are things they should not touch, and some things, not even see.
Have you thought about implementing some kind of access permission, that prevents to see or modify the content of this tab?
Thanks!
@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,
@oliof Good point, we will testing with two images, one from scratch Raspbian and other taken from Duet3D repository. But that only will show the performance in SBC mode. We get a big difference in performance in standalone mode with exactly the same configuration. We need SBC mode as we run other services and dependencies apart from DFS and DWC.
@o_lampe We are running it in a official Raspberry PI 4 B 8Gb and a SD card (Sandisk 64gb class 10 100Mb/s). The start-up is not the problem, it is the time difference in the execution of configurations, loops, macros and variables between SBC and Standalone.
@chrishamm In 3.4.5 stable it takes 11 seconds to load our configuration files in SBC mode. The same config in standalone mode takes 2 seconds.
And, in 3.5 beta3 it takes 5 seconds to load the same configuration in SBC mode. In standalone 3.5beta3, the same 2 seconds that it takes in the 3.4.5 stable in standalone mode. It's 3.5beta3 without using arrays, exactly the same code.
If we use arrays in 3.5beta3, it improves even more the performance in any of the modes due to the logical optimization of the code. But it still wins in runtime standalone vs SBC.