Good morning, @dc42,
Thank you for your response. Why do you recommend the use of an NPN sensor? I understand that I still need to place a resistor as shown in this diagram, correct?
Regards,
Good morning, @dc42,
Thank you for your response. Why do you recommend the use of an NPN sensor? I understand that I still need to place a resistor as shown in this diagram, correct?
Regards,
Good morning @dc42,
I have a question regarding the wiring of a normally closed PNP capacitive sensor that I intend to use for material detection in my headstock. This sensor will operate at 24V, and after reviewing the documentation, it recommends using a voltage divider with a 2.2K resistor (R2) and a 10K resistor (R1). However, I am using the Duet 3 Mainboard 6HC and Duet 3 Mainboard 3HC, which specify that sensor inputs are tolerant up to 30V. My question is whether I can avoid using these resistors and connect the sensor directly to my Duet.
Considering that my headstock has electronics designed by me, the 24V powering my sensor would come from V_FUSE. The ground terminal (GND) would be connected to the IO_# inputs, and the signal would be connected to io#.in.
I appreciate any guidance you can provide on this matter.
Best regards,
Good morning @dc42,
After receiving your response and gaining a better understanding of the workings of Heater3, I have decided to remove this section from my circuit. Since Heater3 does not function as GND, I deemed it unnecessary. However, the outcome remains unchanged. Based on its behavior, when I activate and deactivate Heater3, the brightness of my LEDs simply diminishes. I'm beginning to think that either the 3V is insufficient, or the 0V doesn't manage to turn off my transistor.
I look forward to your response.
Best regards,
Aitor
Good morning @dc42,
The total consumption of my LED strips is approximately 0.11A or 2.6W.
Best regards,
Aitor.
Good morning @dc42,
I forgot to attach this other part of the circuit, in which it can be observed that LEDLINK should act as GND when the transistor is in operation. V_FAN represents 24V, which I obtain from the outputs designated as 'always on fans'.
I haven't calculated the consumption yet, but it will be very small. I can check it and then tell you, but it involves two segments of LED strip, with 3 LEDs each segment, so the consumption cannot be very high. It's a LED strip similar to the one in this link, but it's 24V.
Good morning @nikscha,
For this reason, I used HEATER_3 as if it were a controllable GND. I understood that, when activated, it would behave as GND and, when deactivated, it would act as an open circuit.
Perhaps @dc42 or another administrator can confirm whether this is correct or not.
Best regards.
Good morning everyone,
I have run out of controllable outputs on my Duet2 WiFi, so I've prepared an additional electronic circuit to connect to the 50-pin expansion port. My intention was to use a transistor to power a small LED strip. To activate and deactivate this transistor, I have used the heater_3 pin from the expansion port, as well as the 3.3V from the same port, as shown in the attached diagram.
However, I find that the system is not working as expected. The transistor always lets through a voltage, fluctuating between 20V when deactivated and 24V when activated.
I've configured the system as follows:
M950 F2 C"!exp.heater3" Q500 ; Create fan pin
M106 P2 C"LED" S255 ; Set fan configuration
What could I be doing wrong? Does heater_3 behave like a switch?
Note: The diagram shows a 1K resistor, but I have also tried with a 220-ohm one, which was the value I got from an initial calculation. The circuit behavior is the same in both cases.
Best regards,
Aitor
Hello @Phaedrux,
In both scenarios, the printers are interrupted mid-print. In one of them, it repeatedly disconnects from DWC, despite being the closest to the Wi-Fi access point.
Here I leave you the config.g , but unless someone has modified something that I have not noticed, these config.g are identical in many other machines, so I would rule this out. These printers are always running and are never turned off. These past few days, we have been testing by turning them off after each print, and, so far, the problem does not seem to have repeated itself. Still, I cannot affirm this with total certainty. What I am really interested in knowing is if you can identify any apparent cause in the M122 command.
As for the G-code files, the problem has occurred with those generated in both Simplify and SuperSlicer, and with different G-codes and profiles. But I would also rule this out, as we have thoroughly tested this part.
What I would like to determine is whether it's time to replace these electronic systems with new ones, or if they can still be salvaged. They are more than three years old and one of them has had a broken component for over a year, but this behavior has only recently emerged.
I look forward to your comments.
Best regards,
Aitor
Good morning everyone,
I'm having issues with two of my printers that incorporate Duet2 WiFi electronics, both operating on version 3.4.5 in standalone mode. During printing, they tend to stop unexpectedly. It doesn't seem to be a power supply issue and I've tried reinstalling the firmware several times without success.
In particular, Printer_5 experiences numerous disconnections, as reflected in the web interface. This is curious, since it appears to have a better WiFi signal. Is it possible that these interruptions are due to the computer we are using in this case? Does anyone know how I can solve this?
As for the interruptions during printing, could you give me some guidance on what I should do or if you detect anything strange in the files that I have provided?
console (Printer_3_31.5.2023).txt
console (Printer_5_6.6.2023).txt
console (Printer_5_19.6.2023).txt
I look forward to your comments.
Best regards,
Aitor
Hello @dc42,
I apologize for the delay, this printer has been inaccessible and only today I've been able to have it at my disposal. Next, I provide you with my config.g . If you notice anything strange or incorrect, please do not hesitate to tell me. As soon as I have the printer operational, I will carry out the rest of the tests you have requested.
On the other hand, in an initial test I installed version beta4 and M84 still does not activate the motor brakes. The emergency stop, both from the PanelDue and the WebControl interface, also do not activate the motor brake in time.
Best regards,
Aitor
Hello @dc42,
In reference to the first point:
M115 B0
FIRMWARE_NAME: RepRapFirmware for Duet 3 MB6HC FIRMWARE_VERSION: 3.5.0-beta.3 ELECTRONICS: Duet 3 MB6HC v1.02 or later FIRMWARE_DATE: 2023-04-14 11:28:15
M115 B1
Duet EXP3HC rev 1.02 or later firmware version 3.5.0-beta.3 (2023-04-13 18:42:24)
M115 B2
Duet EXP3HC rev 1.02 or later firmware version 3.5.0-beta.3 (2023-04-13 18:42:24)
In reference to the second point:
My Z-axis manages both the Y-axis and the X-axis, meaning that the bed remains stationary and does not move. The complete kinematics are based on spindles. For the Z-axis, all four motors are equipped with brakes to prevent them from falling. Normally, they do not completely collapse, but they may tilt towards the heavier side depending on the position of the Y-axis, which disrupts the linearity of the Z-axis.
If you have any additional questions, please feel free to reach out to me. Furthermore, if you require any videos or photos, I would be glad to provide them privately.
Best regards,
Aitor
Re: [3.5.0-beta.3] Problems found with this version
Good morning @dc42,
I wanted to ask if you had the opportunity to review or note a problem I am having with the motor brakes in this beta version. In short, the motor brakes do not activate when I execute M84, which causes my Z axis to fall.
I am using the Duet6HC electronics with two Duet3HC expansions.
On the other hand, during printing, something quite strange happens. At the end of the first layer, the motor brakes are heard and the second layer does not begin in the expected place. This behavior is especially odd since, in principle, the motors should not disable at any point. I have reviewed my G-code and I do not see any unusual commands. I want to emphasize that the brakes are not heard in the following layers and they do not seem to get locked, as the print continues normally, except for the mentioned jump.
In addition, I want to point out that I am using mesh compensation and "baby steps". The only difference compared to other prints where I did not notice this jump is that now my "baby step" value is positive.
If you need more information or need me to clarify any point or perform any additional testing, do not hesitate to tell me.
Best regards,
Aitor
Good morning, @droftarts.
I'm going to try using a shielded cable to solve the problem I'm having. However, it will take me a while to do it. I'm also considering adding a small delay before executing the "deploymentprobe.g" command to make sure that the X and Y motors are completely stopped before starting the operation, since I believe they are the only ones that can generate this noise.
I will keep you informed about the results of the tests.
Best regards,
Good morning @Phaedrux and @droftarts,
@Phaedrux, if I don't use the P0 parameter, the BL-touch doesn't compensate for the distance between the nozzle and the BL-touch and takes the value of the point where it is located. Although I understand that it serves me the same if I use G30 without additional parameters, I will perform the test even though I think I have also tried it before.
The error appears during the G29 process, usually because for some reason, the "M280 P0 S10" trigger is not activated, and the BL-touch goes into an alarm state, showing the mentioned error. My height is 8mm since at some point, I have a 4mm difference, so keeping it at 5mm, the BL-touch was triggered as the piston came out.
G32
Error: in file macro: M280: Probe already triggered before probing move started
I'm not sure I understand your question:
How long are we talking? What does it run alongside?
But my cable will be around 5-6 meters long.
@droftarts, I have tried with M280 P0 S10, S11, S12, and at first, it seemed that even with S12, it worked well since I managed to perform a 15x15 mapping with S12. But it is about performing desperate tests since I don't know what the reason for the failure is, and with such a long cable, I performed these tests to see if it improved, and it seemed to have improved at first, but it failed again. Today, I will try to downgrade to version 3.4.5 to make sure it's not a version issue.
Thank you for your responses. If there is anything that is not clear or if you require additional information, please do not hesitate to ask.
Best regards, Aitor
Good morning,
I'm using BL-touch on my printer, but it's repeatedly unable to complete the calibration process, while in other instances it can. I'm not sure what could be causing this issue. I'm on version 3.5.0-beta3.
Here's the configuration of my BL-touch v3.1 in config.g:
; Z Probe
M950 S0 C"io7.out"
M558 P9 C"io7.in" H8 F120 T6000 R0.5 A5
M557 P15:15 X{0,move.axes[0].max} Y{0,move.axes[1].max}
G31 X40 Y0 Z2.7 P25
deployprobe.g file:
M280 P0 S11
retractprobe.g file:
M280 P0 S90
bed.g file:
; bed.g
; Call to realise automatic bed compensation via G32
if state.status != "processing"
if state.status != "paused"
G29 S2 ; Disable mesh bed compensation
G28 ; Home all
M561 ; Set Identity Transform
G0 X0 Y0 Z20
G30 P0 X0 Y0 Z-99999
G29 ; Mesh bed probe
M400 ; Wait for current moves to finish
This is the message that shows up every time, and BL-touch is unable to exit the alarm state with M280 P0 S160 or S60. What am I doing wrong? "M280: Probe already triggered at start of probing move"
In case it's relevant, my print area is 1500x1500x1500 millimeters, so the cable is quite long. Although it has been able to perform a 15x15 mapping in some instances, there are times when it's impossible to do even a 5x5 without the error occurring.
If there's anything that is not clear or if you need more information, please do not hesitate to ask for it.
Best regards, Aitor
Good morning @droftarts,
I apologize for any mistakes I made in mentioning the electronics I was using during the tests. I thought it was important to include that information in the thread title, as I didn't intend to describe the problem. However, I have created a new thread with a more general title as I have more information to add and I find it difficult to express myself in English. Additionally, I sometimes struggle to select the correct categories.
Thank you for your understanding.
Best regards,
Aitor
Good morning @DC42,
Currently, I am using stepper motors with brakes that have been configured as follows:
M569.7 P0.2 S100 C"out3"
However, I have noticed that the brake does not activate when executing the M84 command. This is different from what happened in version 3.4.0 of the firmware. Additionally, I have also observed that the brake does not activate immediately when using the emergency stop on the DWC control panel. It is possible that both situations are related.
If you need more information or if my explanation is unclear, please do not hesitate to ask.
Regards,
Aitor
Good morning @DC42,
Currently, I am using stepper motors with brakes that have been configured as follows:
M569.7 P0.2 S100 C"out3"
However, I have noticed that the brake does not activate when executing the M84 command. This is different from what happened in version 3.4.0 of the firmware. Additionally, I have also observed that the brake does not activate immediately when using the emergency stop on the DWC control panel. It is possible that both situations are related.
If you need more information or if my explanation is unclear, please do not hesitate to ask.
Regards,
Aitor
Sorry, @mfs12. I haven't found any information about it in the Gcode dictionary (M291) section.
In my initial tests, I used the web interface and then tried to perform the same tests on PanelDue. However, I found that it didn't work because I wasn't using quotation marks to enter the text. Then, when I used them, the M291 command started working correctly.
My suggestion is that, in the case of requesting M291 S7, PanelDue automatically adds the necessary quotation marks to enter the text. In my opinion, this would improve its usability and be more intuitive for users. What do you think?
@dc42, maybe I'm not explaining myself well or not understanding correctly. I'm attaching a series of images where it shows that when running the code below, in DWC I can send text without using quotation marks.
M291 S7 R"S7" P"Solicitar un valor de cadena. L es el número mínimo de caracteres (predeterminado 1), H es el número máximo de caracteres (L2 H50)" L2 H50
M400
M291 S2 R"Respuesta input" P{input}
M400
However, if I use the same code in PanelDue, it doesn't work correctly if I don't use the quotation marks (In order for it to work, I have to write "hello" in Panel Due, unlike DWC which allows me to not use quotes and write hello, for the code to execute correctly.). Could you clarify if this is an expected behavior or if there is any problem with my configuration? I would appreciate any help you can provide.
Good morning @dc42,
I understand what you're saying. That's why I tried adding quotes before writing, but I noticed that in the case of Duet Web Control it wasn't necessary, as I understand that it adds them automatically. I think it would be very helpful and make it easier to use if PanelDue worked the same way, adding quotes internally.
Best regards, Aitor