Topics created by Marcossf

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

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

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

@Marcossf I don't think an active tool distribution board of the sort you envisage is possible without radical changes to the CAN protocols that we use. The CAN bus does not support man-in-the-middle devices, because the ACK but has to be set in real time by the receiving nodes.

We are looking into integrating RFID readers into Duet 3 systems. One possibility is to connect a RFID reader with UART interface to a UART-capable port on the Duet. Another is to connect it to a UART port on a custom expansion board based on a SAMMYC21 or possibly RP2040. If several RFID reads are to be read (e.g. one per tool dock) then RS485-enabled RFID readers could be used.

@Marcossf use daemon.g to write the information to a file when the printer is printing. Should be fairly simple to do. At the moment the only sensor that does humidity is the DHT22. The BME280 is being supported in 3.5

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

YES! That was the problem. I'm sorry for such stupidity 😖

The heighmap file was done right and readed properly at boot. Waiting for a final stable version, hope soon!

Thanks! Have a good weekend.

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

@jay_s_uk OK, thanks Jay.

@marcossf please post your config.g file.

After you run M999 and get those errors on the console, if you then run M98 P"config.g" do you get the same errors again?

@t3p3tony Ok, thanks!

@marcossf Thanks for the note, it will be fixed in the upcoming v3.4-b5.

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

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 🙄

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

@dc42 May could you able to read this entry?

Can you give us some hints about the question asked?

@dc42 OK, understood. If we do a connector reachable for the user when no tool is present in the distribution board, in our case acts as bypass for this tool, not as the resistance terminator.

The distribution board will be leaved with the jumpers fitted as we showed in the last photo and cannot be reachable for the user.

The user will be instructed to put the "blank" connector when weren't tool in the 1 and 2 printhead cables, and follow the cable order if empty printhead from last one to the first one.

But in all the test we did without "terminating", all the times could be able to locate the board of the printheads present. Still testing a lot of things.

May I could not to explain properly. I'm sorry.

@marcossf if you need separate meshes for the three heads, then I suggest you probe the bed three times, storing the height map under different filenames. Then you can load the appropriate height map in the tool change file.

BTW in RRF 3.4 I expect to support remapping of the Z axis per tool (same as we already do for X and Y), so it will be easier to support multiple Z axes.

@dc42 said in Multitool identification:

@marcossf said in Multitool identification:

@dc42 Sounds good!

Do you have a config.g example where these boards array could be inspected?

We thought a macro function or a button in DWC to indicate which printhead and where it is located.

But of course your automated option is superior in terms of usability.
We will try to explore the possibility of integrating this sensorization into the heads. The physical part at least doesn't seem complicated.

I don't have a config.g that does this, however this macro to list connected expansion boards may get you started:

while iterations < #boards if iterations != 0 ; skip the main board echo "Expansion board type",boards[iterations].shortName,"found at CAN address",boards[iterations].canAddress

OK, we will try that. I'm pretty sure that my request for help will not end here. 😊