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.

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

@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

Microdosing of drugs and biochemicals. And other things like inkjet heads, spectrographs in the future ...

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

@dc42 said in Tool Distribution Board improvements:

@Marcossf is the basic requirement to know what tool if any is in each dock, and what its CAN address is?

One way I can imagine doing that is to have a pair of pogo pins on the dock that contact pads on the tool, and to have a resistor on the tool between those pads. Different tools would have different value resistors.

A more sophisticated way would be to put a RFID tag on each tool and have a RFID reader in each dock. The RFID tag would contain not only the CAN address of the tool but other details about its type and capabilities. You can buy RFID reader modules for only a few pounds/dollars/euros now.

That approach is what we now do. It is not difficult.

Imagine a machine has 3 docks, but there are 26 possible tools in different combinations. The part of detecting that tool x is in dock # is the approach we now do (two micro switches on the tool and a combination of pins in the dock that activate a certain logical position combination and the 1LC tool CanID).

If a toolboard were active, it would know the CAN ID of a tool that is on a certain connector on that tool distribution board, or several chained together. This eliminates even those switches, fewer points of failure.

@dc42 Hi David,

Imagine a machine with several docks that can accommodate different tools/printheads. Each tool has an 1LC board into, and it can be different in terms of features from each other, but a unique CAN-ID.

We have a bunch of settings that define the tool itself, and if the Tool Distribution Board were intelligent, we could know in which dock each unique CAN ID is in (by its connector) and in which order it is or what are absent, and take the settings of this current printhead. Making termination unnecesary.
We could even be able to do it hotswap, for example at a pause (monitoring the Can ID daemon and a power supply control circuit board/timer for the 1LC maybe).

Right now, this is the big limitation we see to Duet3D for "non-standard-ultra-nerd" machines with many printheads or tools configured. Another thing is the lack of arrays, which would simplify a lot the variables and the necessary code for this (waiting for 3.5 )

Have everyone a great Christmas holiday.

Hi Duet3D guys,

It would be desirable to have a tool distribution board with CAN ID, and not just a termination / passive distribution board.

The aim would be to be able to detect which 1LC boards are hanging from which Tool Board and its order and to be able to automatically assign e.g. docks to tools, auto-configure present tools, physically switch tools on the fly, etc.

Do you think it is possible?

Best regards,

We would like to install temperature and humidity sensors inside the printer enclosure in the future, and collect this ambient information during printing.

Connecting the temperature and humidity sensors should be relatively straightforward if we use I2C, SPI on any available IO on the board (6XD, 6HC, Mini 5+). We have already seen some implementations in terms of the HW.

But how to generate a humidity and temperature log sync during printing, linked to a specific .Gcode file independent of the slicer used? E.g. such a file printed at given date had these conditions of ambient temperature and humidity.

Any idea or hint?
Thx

@chrishamm @dc42

Testing with a DUET Mini5+ WIFI with this 3.4.2 in standalone configuration, we continue to see random disappearances of the config.g file that were supposedly fixed in this release.

Our wifi network is stable and reliable, we don't see what could be the trigger for this problem except for editing directly in DWC, because it doesn't have a predictable behaviour either.

It is not unsolvable, but somewhat annoying.

@dc42 Fine. We will bought some 2mm lead motors for testing it and benchmarking it.

@dc42 The frequency does not have to be high, it is simply a rheological control of the force needed to extrude/compress a given material.
We use this load cell at the moment with good results:
https://www.galoce.com/products/miniature-button-load-cell/GML679_Button_Force_Sensor_Load_Cell.html

The IO0.in is being used in the syringe empty end detection at this moment, but we could do without it or replace it with the IO3 endstop pins, so both IO0.in and IO0.out would become available.

So physically we could connect the amplifier board the way you suggest but I don't know is whether we will be able to modify the firmware of the 1LC board.

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

@t3p3tony There is attached the ribbon cable from the 6HC to the Raspberry PI, so the pins aren't reachables.

BUT, we need to interface the load cell amplifier to the 1LC board and deliver that sensor dato thru the same FD-Cambus it have, not directly to the 6HC or RPI pins.

I know it's a very uncommon scenario.

I raise this question again, as we still have this need.

Our aim is to be able to set up a load cell to measure the thrust/traction exerted by the plunger of a syringe extruder.

Can you think how to interface it with the 1LC board?