In a previous life, I was the admin of a large computer network. One of the best features of the Cisco gear we used was the command "show tech-support". It spits out a huge text file with the entire configuration of the device, along with a number of diagnostic command outputs, error and operation logs, component temperatures, version info, etc.
The file could either be used in-place for diagnostics or sent to Cisco tech support for further analysis, sidestepping a lot of back-and-forth with the support people.
It occurred to me that it would not be that hard to achieve something similar, either implemented in firmware or else done in DWC. That file, uploaded to the forum (perhaps via an automated mechanism direct from DWC?) would provide a huge amount of troubleshooting data very easily.
Even better would be a way to unpack that data into a visualiser/validator tool that showed common issues, potential conflicts, firmware upgrade 'gotchas', etc. Again, this is something we had with Cisco where complex configurations led to difficult-to-spot and subtle issues. I appreciate that this is not trivial to implement but it wouldn't have to happen all at once and, once done, might actually cut down on the time spent troubleshooting, especially with 'new user'-type issues.
@danal I understand. My point is every single test individually is correct. Yet put it all together and it doesn't work.
That is where I'm puzzled. That PT100 has the same resistance as the one in the hotend measured at the board.
The only thing I can think of is perhaps the voltage isn't high enough? Waiting for David to take a look at the post since I can't find anywhere that lists what the voltage should be.
If the drivetrain is designed properly, the load angular inertia seen at the motor (“reflected inertia”) should be between 1x and perhaps 10x the rotor inertia. If you’re outside that range, your motor is either too big or too small. (The rule of thumb for servos is 1-5x but they have closed-loop feedback stability issues to worry about which open-loop steppers do not.) * You get maximum possible low-speed acceleration capacity when the reflected inertia equals the rotor inertia. * If the rotor inertia is greater, it’s putting too much energy into accelerating its own rotor and not enough into the load. If the reflected inertia is greater, a different gearbox / belt / screw ratio would allow the motor to accelerate the load faster.
In practice, we don’t like to add gearboxes due to parts count and backlash, so the reflected inertia will be a lot larger than the rotor inertia. If it’s more than about 10x larger and you don’t want to change the drivetrain ratios, your motor is probably undersized, but that’s just a loose guideline.
@supraguy said in Is head movement defined in mm ?:
@danal yeah, I get that, and basically the OP question was answered by dc42 (Which I also reiterated at the bottom of my post)
Just really, when you tell the printer to move 1mm, what the firmware does instead is say "I'm going to send x number of pulses to the stepper motor driver with the forward direction set."
However... When the printer is told to move 1 unit, it sends many MORE pulses if there were a prior G20 than a prior G21.
I'm not sure about those G4 P200 commands in deployprobe.g and retractprobe.g. I'm not aware of other people using them. So I suggest you remove them and add parameter R0.2 to the M558 command instead..
@typqxq said in Probing failsafe with motor stall:
Sounds like a good idea for Z with the mecanical endswitch.
How about X and Y?
When my optical switch didn't trigger the motors bent the belt.
Bothe steel reinforced and the fibre reinforced ones.
Would lowering the X and Y current while homing help with that maybe?
Yes to reducing motor current while homing - always a good idea IMO. Because homing usually takes place at slow(ish) speeds, you can reduce the current by quite a lot. You can either simply set the motor currents by using M906 or you can set a percentage reduction by using M913. Both will achieve the same result. Put the command at the start of the homing file(s) but don't forget to either put the motor current(s) back to what you normally use, or set the percentage reduction to 100, at the end of the homing file.
I don't bother with additional switches for homing X and Y as they home very close to the minimum travel - about 2mm from a hard stop, so there really isn't room for a second back-up switch without losing some travel. But should a switch fail, then the reduced current will prevent any serious damage.
I do however have additional switches fitted to all the axes maximum travel - set to trigger just before a hard stop. In normal use these aren't needed, as once the machine has been homed, and providing you have set the axes maxima correctly, then the firmware won't allow moves beyond those maxima. However, I often work on the printer and tend to allow axis movement before the homing has been done, so in the event that I do something stupid, the switches will trigger an emergency stop and prevent damage.
To keep the wiring and configuration simple, all the switches are wired in series and normally closed, and connected to a single end stop on the duet. So if any one triggers, then it will initiative the emergency stop. It's generally best practice to wire switches normally closed, then if a wire falls off, it will fail as if the switch has triggered, which is safer than not see the trigger.
@peirof said in Simulation mode:
T0:21.0 /0.0 B:20.1 /0.0
That means that the file you are trying to print contains some M105 commands to report temperatures. They will be reported during actual printing too. Those commands are probably in your start and/or end GCode scripts. You can remove them.
Yes but you also need to limit the number of sides to about twice the hole diameter in mm.
When the nozzle turns a corner the filament likes to take a shortcut and cut the corner, making it rounded. When you have a less corners they are further from the desired circle, so when they get rounded they are still outside it. I found empirically that when the number of sides is twice the diameter the rounded corners just about lie on the circle, so you get the roundest hole that is still the right size.
Since I design exclusively on OpenSCAD it is not problem for me to make all holes with poly_cylinders instead of cylinders. My STL files then print correctly with any slicer and toolchain.
When printing other peoples designs, my old machines that run from my own host and firmware have the ability to detect circles in the g-code and convert them. That enabled me to print thousands of Mendel parts without having to ream all the holes.
I want to give a HUGE shout out to our latest sponsor to join the FK-1 project... Printed Solid has stepped up to supply a PEI sheet! But not just a PEI sheet, a custom laser cut 16"x48" (Just slightly larger than 400x1200mm!) Thank You Printed Solid!
Perhaps he's referring to the one he was talking bout here:
There was advise given in that thread, but I haven't read through it all.
Edit: Oh. There's not much to read, and no followup on what he has or has not tried.
@Mikesplane Please provide some information which might get you started. You were offered some advise in your ole thread that we have no idea what you have and have not done.
@fickert said in Stall homing: Is it less accurate with a 24v supply vs 12v?:
I am not super familiar with EMF but if it isn't using current as its measuring parameter then that is all I was concerned with.
As for the high inductance motors, is there something specific I would need to search for to determine a high inductance motor vs a standard/low inductance motor? I am looking to use a 0.9 degree stepper on my z axis, is there something else I should be shooting for?
Lower current motors have higher inductance. For the Duet WiFi/Ethernet, choose motors with a rated current of at least 1A, preferably a little higher. There are motors available with rated currents of 1.2A and 1.33A.
High inductance motors limit the maximum speed you can use before torque starts to drop off and stall detection stops working, but using 24V power instead of 12V mitigates this.
@siblues said in A few questions regarding switching to Duet:
5V 2-Channel Relay interface board, and each one needs 15-20mA Driver Current
Equipped with high-current relay, AC250V 10A ; DC30V 10A
Standard interface that can be controlled directly by microcontroller (Arduino , 8051, AVR, PIC, DSP, ARM, ARM, MSP430, TTL logic)
Indication LED’s for Relay output status
It activates on low level.
That sounds like a standard relay module with a driver and an optically-isolated input. If it is then it is suitable.
Looks like your connection to Duet3D was lost, please wait while we try to reconnect.