Posts made by sotpurk

@DrDFlo Hey, could you possibly also share your config file and the speeds at which you print? It would help a ton
I'm having trouble with the extruder since the motor is heating up a lot even while extruding PLA at relatively low speeds so a reference config would help a lot.
Thanks

@DrDFlo I got a bit occupied with another project so it still roughly looks the same, but I've changed the Y and X printed mounts to CNC ones and doing the same for Z.
It's producing decent prints now apart from the entire frame oscillating at heights (which is expected since I'm going to support it externally later on)

Because the gantry is rather heavy, It's a lot of wasted energy to level/mesh the bed so I came up with remapping an actuator that has an end-stop at one end as Z when probing. That way only the actuator moves instead of the entire gantry moving in Z; but the 6HC doesn't allow the motors to remain energized when changing assignments so I'm waiting for a 6xd board to be delivered where I can do this externally. (there's no reseller in my country so importing takes too much time) (https://forum.duet3d.com/topic/31694/keep-motors-energised-when-changing-assignment?_=1680794473398)

Also installing a vacuum loop from the extruder for feeding pellets (the momentary exposure to moisture in the air isn't a big deal since the primary storage is isolated and it's only fed when being printed so no long-term exposure.)

Swapping the current worm gears as well, I was under the impression that worm gears can't be back-driven but seems like that's only the case when certain conditions are met. So have ordered new gearboxes with higher ratios (will use the old ones on another build) but man, imports.

Ideally, the extruder doesn't need to move beyond 120mm/s to achieve its maximum output but I've tested the machine to reliably move at 800mm/s which was scary fast.

Here's my most recent print:

@T3P3Tony @o_lampe
Yes, have ordered new gearboxes(worm) with higher ratios to mitigate this issue.
The problem with the motors de-energizing when changing assignments still remains though.
I messed around with the firmware but couldn't produce any results.
It seems to be a firmware limitation as was said before and to move forward I've ordered a 6XD with drivers so that I can control the enable and power separately; hopefully that should be enough to get the levelling logic working reliably.

@dc42 Setting Z=0, mesh probing, and bed leveling.
I tried the mentioned flow but the motors de-energize when changing assignments which results in lost steps.

@o_lampe Oo that's neat and would solve the issue. Thanks.
I just checked the schematics. All the enable inputs seem to be tied to a single pulled-up line from the MCU.

I'll try this out as soon as I get a chance. Thanks again.

@deckingman I apologize if my description was confusing.
I will fix the gantry falling by replacing the gearboxes so the gantry falling when power is lost isn't an issue.

The problem is only when reassigning the axes while the machine is powered on do the motors lose energy. Now the axis won't fall when that happens even if the motors are not energized, but since it'll be probing the weight is going to be shifting and I would like to have no lost steps.
And since it's an industrial environment I can't rely purely on the worm gears when probing hence it's important that the motors are energized.

TL;DR: What happens when power is lost is not the concern here, but keeping the motors energized while probing is.

@deckingman I'm not using leadscrews, I've made a custom chain + sprocket assembly that the gantry runs up and down on.
There's a 10:1 worm gearbox between the sprocket and motor. I figured a worm gearbox would not be back-driven but I seem to have selected a lower ratio than required. My current solution to that is to switch the sprockets to smaller-diameter ones or switch the gearboxes to a higher ratio.
I'm leaning toward the latter.

Even still assuming the gantry doesn't fall down, I'd like for it to be rock solid in place when the entire actuator-based leveling happens which takes us back to the previous issues.

P.S.: The mounts are only printed to test and will be CNC'd later on.

@Phaedrux It would be very expensive for me to swap the motors or attach brakes to the same. As a last resort, I'd much rather move to external drivers since an enable pin would solve all my issues, but to do that I'd have to buy a 6XD or 4 1XD boards which would result in about the same price so yeah still quite expensive. And either way would result in more points of failure.

And since this is something that possibly could be done in software, I'd much rather do that.

@o_lampe @deckingman The post-processing solution might just work but will need to figure out how variables work here better.
I've tried out the 3-way swap and ran into an issue, I'll walk through the current flow:

1. Home the printer with Z motors assigned to Z
2. Assign all the Z motors to U and do a relative G1 H2 U0.1 move right after to energize the motors.
3. Assign the actuator to Z and probe the bed.

The problems with the current flow are as follows:

1. When doing the G1 H2 U0.1 move after the reassignment to energize the motors there's a slight period where the motors are not energized and the gantry falls just a bit before they are. The falling is a problem, to begin with, but energizing the motors while it's falling would result in massive back emf.
2. Right now I'm without the actuator logic this is what I'm using to level the bed:

G30 P0 X180 Y310 Z-99999 ; probe near a leadscrew fl
G30 P1 X180 Y1160 Z-99999 ; probe near a leadscrew
G30 P2 X1190 Y310 Z-99999 ; probe near a leadscrew 
G30 P3 X1190 Y1160 Z-99999 S4; probe near a leadscrew and calibrate 4 motors

The issue is with the last line, since executing the gantry leveling is automatic at the last line which does not give me a chance to remap the 4 Z motors to Z.
Is there any way to split the execution of the leveling from the last line (S4)

@deckingman That's interesting and I'll certainly give it a try just to mess around, but it's not applicable here because assuming it works it'd move all the motors simultaneously or none at all whereas the purpose is to move 4 motors for Z when printing and otherwise and use an actuator on the extruder for leveling.
So mapping 4 motors for Z and mapping actuator for Z and U probably will result in the entire axis moving with the actuator on any Z command.

This is in reference to the query here: https://forum.duet3d.com/topic/31427/moving-an-actuator-as-a-zprobe-instead-of-the-entire-axis?_=1678019622288

When attempting to implement the aforementioned, on changing the assignment for the z-axis the motors de-energize which results in the gantry (80+ Kgs) falling.
Is there any way to keep the drivers enabled when the motor assignment for the Z axis is changed?
If I were using external drivers this could easily have been done using the enable pin, is there a way to control the enable of the driver and not the axis?

@DrDFlo @o_lampe
"I am upgrading to a 12 mm high-helix lead screw for faster travels at lower RPMs, but I am limited here by the c-beam aluminum extrusion profile"

Why not go with a rack and pinion setup?
I am coincidentally making a very similar printer with the same extruder.
The differences are as follows:

1. Integrated servos instead of steppers for X and Y (Stepperonline iSV-T motors)
2. Using chains and custom sprockets for Z.
3. Modded the MDPH2 with a RTD pt1000 as a failsafe for the terrible grounded thermocouple on the extruder (Probably going to replace that too )
4. the X and Y motors use a 1:5 Planetary gearbox and connect to 1.5 module pinions that travel on racks. There's no backlash, it's smooth and it's really fast.
5. It's bigger.

Hello,
Would it be possible to map an actuator with a stepper as the Z probe with a switch on end rather than only deploying the Z probe and moving the entire Gantry up and down?
My gantry weighs almost 100 Kg so I'd like to minimize the Z motion as much as possible.
I was thinking something along the lines of:

1. Map the actuator as a separate axis and home the actuator zero with an end-stop on the actuator.
2. Move the extruder to the probe point and remap the Z to the actuator.
3. Retract the actuator till another switch or sensor (which is mapped as a Z probe) at the bottom end of it touches the bed and the actuator moves back up again.
4. Remap the Z back to the Z motors.

This seems doable as an alternative, but is there any inbuilt functionality in the Z probing setup that I could use here?

@o_lampe Oh, that's interesting. Could you possibly send some links for the mechanism you're talking about for the bigger machines?

And yes I'm using servos instead of steppers.

@o_lampe Oh, that's an awesome design. I've come across this design while browsing youtube and thought the same earlier; it might have been your video that I probably watched.

Albeit enticing, I wouldn't use this design just yet since the machine I'm building has a print area of X2000mm x Y4000mm x Z2000mm so I'd rather stick to the basics for now. But I'll certainly keep tabs on the design and hopefully build one in the future since the counteracting inertias are very appealing as I usually work with bulky systems (pellet).

@dc42 Thank you for the prompt reply.
Using a 6XD as an expansion would certainly ease up the process and the cost but each of the motors will have at least 4 I/O requirements which would increase the wiring by a considerable amount (around 12 wires per motor instead of 4) overall and defeat the point of using CAN.
I'll consider this as a last resort if using 1XDs throughout doesn't work out.

Two questions though:
Can the 1XD be wired to the thermocouple daughterboards via I/O?

Is there any way to keep a tab on the CAN traffic and CPU time/load and figure out if/where there's a bottleneck?

Hello,
I'm planning on using a 6XD board with 9 x 1XD boards as expansion and 3 x 3HC boards for thermocouple inputs; I've ordered and received most of the parts already so this might be a bit too late to ask.
It's 3 extruders running simultaneously to print the same object thrice.
5 motors for the Z axis
6 motors for the Y axis (one on each end)
3 motors for the X axis

Can the board handle and run all these with decent step rates or would it be better to go with a Linux-based controller?

Hello,
Is it possible to attach thermocouples through the daughterboards or otherwise to the Sammy C21 board or any other board apart from the 3HC?
The requirement is to attach 15 thermocouples and adding 3HC boards is not ideal since extra stepper outputs are not required.