Topics created by sonderzug

Thank both of you;

@droftarts good call about the iap4e.bin, this fixed my problem.
It seems a bit counterintuitive that to upgrade to 3.0, the iap.bin from 2.05.1 is needed, and the same goes for the update from 3.0 to 3.3 - this might be worth mentioning in the firmware update section in the docs where the different jumps in firmware version are described. It does mention to not just rename a file (😇) but it says that each version comes with the matching file, which seems a bit twisted.

best regards, Niklas

@sonderzug Hi I have the same cr touch and LC board, wiring is correct but it shows Error: "G30: Probe was not triggered during probing move." Can you send me full configuration?

@sonderzug said in please check/fix my daemon.g, it seems to cause software reset:

reason: OutOfMemory,

Your last reset was actually out of memory. I don't see anything obviously wrong with your gcode. It is probably worth updating to the latest version 3.4.5 (you are currently running 3.4.1) to see if that resolves the issue.

thank you, I've been able to buy a replacement in short term and will make use of your replacement offer afterwards.

best, Niklas

@sonderzug et al

We have been considering a SAME70 CAN-FD control board designed to use CAN-FD expansion for most functions for a long time now, but need to consider the total stock of these processors available to use before adding another product that uses them.

If we did it Pi hat is one form factor that could be used but may not be optimal.

@sonderzug
Ah! I see. Thank you very much.

@gallaghersart from what I understand now, it can be handled in daemon.g, maybe in a submacro for better structure.

You'd have to make extensive use of variables. The macro could be something like this (mockup):

determine RGB values for each individual "light" (=group of LEDs), much like @zapta 's example, according to your specification. Store in variables (e.g. "R_group1, U_group1, B_group1, R_group2 ...")

send M150 string at the end of the macro:

M150 R{R_group1} U{B_group1} B{B_group1} S{[number of LEDs in first group]} P{P_group1} F1 M150 R{R_group2} U{B_group2} B{B_group2} S{[number of LEDs in second group]} P{P_group2} F1 M150 R{R_group3} U{B_group3} B{B_group3} S{[number of LEDs in third group]} P{P_group3} F0

this way, all RGB values for the whole strip would be send at once, which was what my initial confusion was about.

If this macro is called regularly in daemon.g, it should all be quite smooth.

another thing is "blinking"; this would be more difficult. It could be done with a variable for brightness that is changed in each iteration of daemon.g, e.g.

P_group1 = 255 (initialised once at start, e.g. in config.g) P_group2 ... P_sign = 1

then in daemon.g:

if {P_group1} == 0 || {P_group1} == 255 P_sign = -P_sign if {P_group1} < 255 && {P_group1} > 0 P_group1 = P_group1 + (P_sign*5)

this way in each iteration of daemon.g, the brightness value is changed. the speed of blinking is dependent on how often daemon.g is called (I understand that this can be adjusted) and the value added in the last operation (e.g. 5)

note: not tested, just what I imagine could work.
I think there has been a request for a more elaborate way of handling LED colours before. Until then, we'd have to work like this.

best, Niklas

@dc42 said in Some questions about firmware retraction on a toolchanger:

Yes. But would you ever do T0 G10 followed by T1 G10 without an intervening G11?

I could foresee a scenario where that might occur. A purge macro might consist of a G10 retraction, a non-print move to a "bucket" followed by a G11, then an extrusion, then another G10 to end the purge - probably followed by a nozzle wipe for which a G11 would be undesirable. One might run that as part of a pre-print routine but also after selecting a tool. If the pre-print purge ended with (say) T5 - G10 but the first command in the gcode file was T0 which instigated the tool change macro, then one would get another G10 without an intervening G11.

Hello Gentlemen,

I've had the chance today to play around with my setup today.
In regard to my questions above, I can report the following:

the igus controllers in fact seem to be happy with the "unadultered" output of the EBOB. They have a separate +5V/- input for logic level connection with external controllers such as the Duet, which I connected to the same 5V/3A PSU as the Duet itself. Accordingly I've only connected the S-, D-, and E- pins to the respective inputs of the igus D1. I've gone with the recommended setting of M569 P5 T20:20:10:10 which in turn seems to work fine. I've not tried to go any lower yet (is anyone interested in this experiment?) regarding resolution, I've set the Duet and igus D1 up at 1/32 stepping at the moment. Considering the 20T HTD 3 mm pulleys I am using resulting in ~ 106 steps/mm and at 25 kHz max. step frequency this gives about 235 mm/s in movement speed which is totally acceptable. Moving the one motor I'm experimenting with seems to work even at higher speeds. We will see in the final application how well this works.

thank you again for your support.

Best regards, Niklas

@bearer said in Can't connect Duet Ethernet to company network:

it sure sounds like your admin is saying "I've had my coffe now and it should work"

Perhaps a BOFH?

Hi all,

"next weekend" turned into a few weeks, but with the holidays and everything I only had limited time to work on this project. However, the remodeling is more or less completed.

I announced that I would be ditching the igus linear rails. I did so in favor of used/new old stock THK linear rails that I obtained from ebay. In particular, I bought RSR12 (ZMUU) and RSR9 (WVM - double wide rail) rails, which will help this build achieve a much higher mechanical quality but will also be carried over to future builds (the lenghts allow for a bigger build volume than this has).
The problem with the igus rails was, as mentioned, that I chose the square profile rails which are not tensionable. The round profile drylin W rail has options for setting the tension of the gilder with a screw.

For the new rails, I obviously had to account for the missing structural components of the drylin rails. The easiest and most precise thing for me was to have aluminium sheets lasercut for my purpose. So this is what I did.

I further wanted to eliminate the cheap chinese belt idlers, which I replaced with 608zz bearings on which the backsides of the belt run. Obviously there are no flanges to guide the belt, which is a bigger problem than I anticipated, so I will have to replace some of those with flanged bearings.

I opted for genuine Gates GT3 belt, to eliminate further influence from cheap components. So far the print results are way better than before, regarding the quality aspects that can be traced to the mechanics of the printer.

Pictures:

DSC01247_1.jpg

the x-axis plate has mounting options for the rail, idler, motor and optical endstop. The stepper motor is mounted in a seperate printed part that allows it to be pivoted around the lower mounting hole, allowing to tension the belt.

DSC01261.jpg

This arrangement is copied for the y-axis. The heatbed will be mounted like before.

DSC01246.jpg

assembled and running:

d81130ac-061d-44f0-9599-850f33a2a8a7-image.png

DSC01479.jpg

right now the printer is printing some parts for itself, namely the cooling ducts for hotend and part.

A short glimpse under the hood:

DSC01471_1.jpg

Why the board hasn't been mounted with it's edge facing outward to easily connect the ethernet cord, I can't tell 😄 I didn't deem it too important at the time, unfortunately.

I still have to tidy up the cabling of the hotend as well; the cables are connected with two 8-pin connectors for which I want to design plug housings and strain reliefs as well.

On the topic of the x-axis falling down when the power is taken off the steppers.... yes it will of course, and unfortunately also when the stepper's coils are shorted. I will design a little lever that the x-axis can run over at the z-max end, which will snap into place to keep the x-axis up after power-off; I have a RC servo lying around which I will use to release it automatically.

I'm overall happy with the rebuild and hope I'll be able to use the printer for railway modelling etc. in the future.

Best regards, Niklas

Hi there,

thank you for your detailed reply, and what should I say - it works! Very much appreciated.

I didn't even consider the option of leaving the machine on all the time like you would a TV. I wanted to be able to
a) implement a safe-fail mechanism (as opposed to fail-safe, were I would rule out all possible sources of error), so that the Maestro can switch off the 24V supply in case of thermal runaway etc. This is possible because all power consuments run off the board, even the heatbed.
b) have a means to switch the power off after a longer print job without losing the control over the machine and the ability to check on it from time to time.

I also like your second option, it's quite elegant!

Best regards, Niklas