@dc42
C'est une pince relativement grand, environ 50mm de diamètre.
Je vais tacher de faire ces meusures

Posts made by Esteban
-
RE: Low heating element current
-
RE: Low heating element current
@achrn
Non je n’ai changer aucun autre paramètre.
Pour ma pince, c'est une pince professionnel mais je ne trouve pas ses caractéristiques.
Je vais tacher de voir en contactant directement mon lit momentanément a l’alimentation pour vérifier mes résultats.
Et de modifier mon Gcode -
RE: Information on the distribution of calculations on Duet cards
Thank you very much for all your answers, they help me a lot to understand the various functions.
So far I'm still on 3.5 but I'm going to switch to 3.6 with the installation of the new cards.
When I talk about “error correction”, I'm talking about holding in position. I didn't know if it was the 1XD that took care of this or if it was the boxes of the different external controller kits. But now I know.
Indeed, on a CL-42-T controller I dismantled, I couldn't find much electronics, which is where this question came from.
On the other hand, one last question: for very complex machines with a large number of axes, would it be more “efficient” to have a main 6XD and then add 1XDs and another 6XD in daughter mode? -
RE: Low heating element current
@infiniteloop
No, everything has always gone smoothly. But if I max out at 6.8 * 24 = +/-160W and 1.7 * 24 = +/-40W, could that explain why there's no voltage drop? -
Information on the distribution of calculations on Duet cards
Hello everyone,
I'm going to add 3 new boards to one of my machines.
- 3HC
- 2 x 1XD
And I'm in dire need of information that I can't seem to find or understand.
I'm trying to find out how (in a rather basic way) data is shared and processed in a Duet environment with expansion boards.
-
My first question arose from the fact that my machine, equipped with a single Duet 3 Mini 5+ card, shows artifacts when turning at “high speed”. I've carried out numerous speed and acceleration tests, and yet (without exceeding the mechanical limits of my printer) at high speed, it still lets gohsting appear in combined/complex movements such as bends, exceeding 120mm/s. So I wanted to know if it's possible to saturate the Cortex M4? And if so, does it simplify calculations for the various movements? In my case, there are two X and Y motors set at 400 steps/mm for a speed of more or less 120 to 150 mm/s for a slicer part with Cura, which has a motion resolution setting of 0.01mm.
-
My second question is whether there's a way / a calculation to know if the calculations required of the processor by GCode are too complicated or not?
-
In the case of expansion board connections, a 3HC, which board will perform PWM, motors and temperature monitoring calculations? In a certain logic, each board only performs the calculations for its own sub-components (except for the main board, which also reads the code and compiles the information received by the CAN to display it on the screen)?
-
SBC mode can help relieve the main board of certain calculations?
-
My machine will soon have two servomotors in a loop connected to a 1XD daughter board, and I'm wondering if there might be a slight latency between the two 1XD boards (the X-axis and the Y-axis)? Especially in combined movements ...
-
Finally, I can't quite figure out who sends the correction command to the motor in the event of an error between the 1XD and the integrated box (for example, with a Cl-42-T box or much more powerful industrial boxes).
Many thanks for helping me out on this front.
-
RE: Low heating element current
@jay_s_uk said in Low heating element current:
maybe the rating of the bed and the hotend heater?
For the trays, no, it's a 320W. As for the hotend, I confess I haven't tested it with more powerful heaters, but I'm pretty sure I have a 60W (Chinese, but normally not the cheapest of all).
-
Temperature sensor integrated into 3HC and 1XD boards
Hello everyone,
I'm going to install three new boards on one of my machines.- 3HC
- 2 x 1XD
Just as a precaution, I'm interested in monitoring the temperature of my boards, but I can't find out if these two different types of board have an integrated temperature sensor like the Mini 5+.
Is this the case?
What are the commands to attach to my config.g if this is the case?
Thanks in advance for your help! -
Low heating element current
Hello everyone,
I'm experiencing a slight problem with the output current of my bed and hotend. Nothing alarming in the sense that they work and to my knowledge have always worked like that, but in the need to heat my machine much faster, I checked my amperages:
- For the hotend = ~1.75A but connect to “out 1”.
- For the bed = ~6.85A but connect to “out 0”.
*to the current clamp
My board is a Duet 3 Mini 5+, so I should be able to get 15Afor the board and 5A for the hotend. However, this is not the case. There's no limitation on my power supply (LRS-350-24 MeanWell), whether the elements are switched on separately or not, the values remain approximately the same.
Where could the limitation come from? I don't have PWM limitation for my M307 controllers.
M950 H0 C"out1" T0 ; create heater #0 M143 H0 P0 T0 C0 S285 A0 ; configure heater monitor #0 for heater #0 M307 H0 R2.43 D5.5 E1.35 K0.56 B0 ; configure model of heater #0 M950 H1 C"out0" T1 ; create heater #1 M143 H1 P0 T1 C0 S115 A0 ; configure heater monitor #0 for heater #1 M307 H1 R2.43 D5.5 E1.35 K0.56 B1 ; configure model of heater #1
-
RE: Driver overvoltage and stall
@dc42
Thank you for your reply,
On my M122 order I don't get any error on my drivers. So I looked at other motors and also the continuity of my lines and everything seems correct. On the other hand, what seems strange to me is that I only had one motor connected to my Mini 2 expansion card and neither of the two drivers is working. When I damage a driver, for example by making one of my axes move too fast, should I only damage one driver? -
RE: Driver overvoltage and stall
@Esteban
Can installing an end-of-course max stop prevent this kind of problem or will the movement be proiritory on the stop? If not, will the stops remain active when the M564 S1H0 command is sent? -
Driver overvoltage and stall
Hello,
I've just encountered a problem on my Duet 3 mini 5+ motherboard. Unfortunately, the direction of my Y axis was reversed during standard homing. This inversion caused the platter to physically stop against the machine's chassi and the stepper motor to stall for a few seconds (the time it took for me to cut the power supply).
After powering up again, my Y axis only vibrated without really moving forward. I know that this is often a bad sign, but on principle I reinstalled all the programs and updates without succeeding in solving my problem.So I have two questions:
Can stalling for a few seconds destroy a driver?I'd also like to know what the best solution is for protecting my drivers (Duet 3 mini 5+ -> TCM2209). I think there's already some protection in the chip, but it's often too weak.
Could adding a zener diode (in one direction for phases A+ and B+ and in the other direction for phases A- and B-) be a solution?
If so, is the output voltage of the drivers 5V or V_in?Thanks in advance for your help
-
RE: Untimely stop and reversal of movement, SZP sensor reading error
Okay, so accessibility depends jointly on the G31 and M208 command?
Concerning my M122, I'm afraid I won't be able to run it after a print stop, because my drivers aren't working due to the failure...
But when I run it on unload, this is what I get, along with my configuration : -
Untimely stop and reversal of movement, SZP sensor reading error
Hello everyone,
I have some little problems with my motherboard, a 3 mini 5+ Ethernet.
My very first problem came this morning. I had already launched last night, a long print, which worked very well, but this morning my printer was switched on, except that it was in its initiation state, with no print status, all the heating elements were cold, and no gcode line backup... (After checking, no power failure at home)
I restarted another print. After a few hours, the printer stopped and also without any backup (although it was well configured in config.g and in any case there was no power failure whatsoever).
On the spot, I tried to execute a "resurrection" but my Y axis vibrated instead of moving, even though the nozzle wasn't blocked by the print.
I took a closer look at my power supply, but it turned out to be stable and functional.
I restarted my machine again with a Y axis that reversed direction...
Another attempt, and again vibrations, with no movement of the Y axis.
I have a mini 2 extension card, and I was able to try the same motor on other drivers. It worked perfectly.Now for some additional information: on cura as on others, I've set a motion resolution of 0.05mm at a speed of 60mm/s. Can these interruptions be due to processor overload? Could these interruptions be due to processor overload? With an even lower resolution I had jerky movements but no lag whatsoever and a functional impression.
Then, on my mini 2 card, none of the drivers are working now. Should I buy another one, or will the problem come from the main card?Second question:
When I scan with the SZP on my last scan line, I get an error telling me that the points have been skipped, and of course telling me the coordinates. Having scanned 400 points, I tried to reduce the mesh size by using a 25 mm square spacing. I tried to reduce the scanning speed to a very slow speed, but still obtained the same error. However, the scan on the rest of the board works fine with your correct data. I've tried to update everything again, but without success. What could be the cause?Thank you in advance for any answers you may be able to give me.
Translated with deepl.
-
Position Z0 impossible avec une sonde SZP
Hello everyone,
I'm having a problem with my homing. I have a switch to set the Z0 (in locurence at home, it triggers when the nozzle is about 1.5 mm from my platen, see homeall.g). Now, when my machine knows the position of its axis, it should be perfectly normal to send a G1 Z0 to bring the nozzle into contact with the platen... However, this is not possible.My machine refuses to lower the axis below 0.6 mm. Finally, when I start printing, the nozzle remains +/- 0.6 mm from my platen, even when I adjust the ‘baby steps’ from the control screen. (My machine sends me an error message saying that this point is out of bounds).
However, my probe does its calibration and a scan of the plate before each print with levelling for the double Z axis, and everything goes very well (apart from an error message from my console telling me that quite a few points could not be reached: see photo). I'm also curious to know what went wrong (same error with much slower speeds).
So I'm sending you my configuration files here:
bed.g
config.g
config-override.g
homeall.g
homez.g
Thanks you -
Cofiguration SZP
Hello everyone,
I could really use some help reconfiguring my SZP probe. Currently, when I mesh the bed, I only get heights of 0, i.e. a perfectly flat plate.
I'm making my configuration files available to you.
bed.g
config.g
homeall.g
homez.gMy probe is 12.7 mm from the base of my nozzle (Z) and 35 mm in Y (the values are already configured).
What's more, I don't have a second Z probe; the homing is done with a limit switch on the Z axis. When it's triggered, the nozzle is 1.45 mm from the bed.Similarly, the M558.2 control also has the right values.
Thank you for any help you can give me.
-
RE: SZP probe sends me extreme temperatures
@droftarts No, they're not... Which is something I'm going to do very soon.
Thank you for your feedback, I will contact support
-
RE: SZP probe sends me extreme temperatures
@dc42
Here's the answer:
M308 S10
Sensor 10 (Bobine SPZ) type Thermistor using pin (120.temp0,coiltemp), last error ok, reading 244.1, T:10000.0 B:3425.0 C:1.68e-7 R:2200.0 L:0 H:0What's more, I've tried it on a second identical motherboard and the problem is identical.
Could it be the CAN port termination resistor ?
-
SZP probe sends me extreme temperatures
Hello to everyone on the forum.
I have a big problem with my SZP probe. I received it a few days ago and have been testing it. It has worked very well so far. Strangely enough, I've just switched my machine back on this morning and I can see on the Duet Web Control that my sensor is at over 200°C. (the nozzle was cold, it was the first switch on of the day).
I very quickly switched it off (you never know if it could be a short circuit or a real temperature reached) and used a laser thermometer to check if the coil or the board could be hot, but nothing.
I checked all the cables. Whether it was the CAN, the 5V power supply, and of course the FFC ribbon cable. All were OK and I did conductivity tests with my electronic tester and there again everything was fine.
So I turned my machine back on. It still showed me very high temperatures. I then looked at the values that my coil could send me and they were correct ~8000. (when I lower and raise the assembly I have values that change with consistency).
So I thought it might still work and tried a mesh...
And here's the result:So either I've got a particularly flat chainring and axle alignment, and I'm very lucky! Or I have another problem to which I don't have the answer.
I've taken the time to review my configuration files and update all my various components to the same version. But the result is still the same.
So I'm asking for a little help ...
I'm attaching my configuration files:bed.g
config.g
heightmap.csv
M122.txtWhen I communicating with my SZP probe, it detects well and displays a very probable value, both on the Panel Duet and on the web.
I would also like to point out that when I first started using my machine, it took a few probe readings by itself, with movement on the Z axes. Unfortunately it no longer does this.
My red indicator LED works and does not flicker, but my green LED no longer lights up either at rest or when I try to communicate with the SZP.
Thank you in advance for your feedback.
-
RE: Z endstop qui se déclanche lors du balayage avec le SZP
@Esteban
Problem solved!It really wasn't a big deal, I just had two probes to configure and my Z axis end stop was one of them (I had left the basic Reprap configuration). And when probing, each probe could be individually triggered and mislead the probing by scanning the bed.
So I'm giving you the corrected configuration for those who have this problem.