Posts made 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.

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/

https://www.baumer.com/es/en/product-overview/smart-vision/profile-sensors/ox-blue-laser/oxp200-b02c-004/p/45062

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.

@gloomyandy Thank you, we had have a look to your post. We appreciate.

Still we guess whats the diference in performance with identical configs. No errors, working in both cases and the only difference is the aditional time SBC takes in load the config/macro/whatever.

Unfortunately we can't reveal our configurations and code, but they are complex as they are not running on a standard 3D machine, but the machine is 100% functional.
We are trying to speed up some conditional loops and slow processes by iterations, because of the lack of arrays in a stable version.
Our logic is that with Standalone, due to pure HW power, everything should be slower than in SBC, and the opposite is true.

Hello to all,

We are doing some performance tests and we don't quite understand what happens in the following case:

The same configuration files executed in standalone mode on a Duet3D 6XD board take about 1 second to make it available, but on the SBC (same configuration) take about 15 seconds.

What could be the reason for this huge performance difference? In both cases the functionality is identical, there are no bugs and the only difference is the performance (the time to load macros, variables and settings, which are identical).

The SBC config is runing in a 8Gb Raspberry Pi 4B with an identical SD card as when used in standalone mode.

As we said, both configuration files are identical. How is this possible if the 6XD hardware is inferior to the RPI?

What makes the difference?

Hi @chrishamm

Our config file is not going to clarify anything for you as it makes calls to several other files that it loads from where there are hundreds of variables.

We would have to figure out a way to get an M122 out because when it connects and disconnects it does it often, with no time to see what is going on. I think we have a console log where we can see it, but it never connects stable, not even once. I'll look for it.

With version 3.4.5 it works perfectly.
Sorry I can't give you more clues.

We tested this 3.5 beta 2 in our 6XD + several 1LCs machine in SBC mode, and it gives constant SPI reseting.

Going back to 3.4.5 stable version revert the normal behaviour of the printer.

All firmware on the boards in the beta 2 are been updated, just in case it needs to be same version than mainboard.

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