Topics created by Aitor

Thank you very much, @dc42. I’ll try it out next time. Wishing the whole team a Merry Christmas!

@Aitor said in Issues with Intermittent Stopping of the Z-Axis Motor:

As a workaround, is there any way to make all the independent motors stop upon detection by any endstop sensor?

Only by wiring all 3 normally-closed endstop switches in series.

@droftarts said in Possible object model error:

I'm sorry, but you'll have to ask @chrishamm why it works! I think it changes the data type to a string.

ok 😂

@Aitor you can leave it in place, it won't do any harm.

@Aitor in RRF the PWM can be defined by a floating point value in the range 0.0 to 1.0. See for example https://docs.duet3d.com/en/User_manual/Reference/Gcodes#m42-switch-io-pin.

Good morning @dc42,

I will try it as soon as I can. Next week we will be at a trade show with the new models, so I won't have time to run the tests until after that. However, the issues I am having with version 3.5.1 are likely due to a misconfiguration on my part and are not related to the incident in this post. But since you mentioned it, I'll explain what is happening: with the Duet3 6hc and 3hc electronics installed on three different machines, when I press the emergency stop button from Web Control or from PanelDue, sometimes the reboot doesn't complete correctly, and the 6hc and 3hc don't synchronize. As a result, I see communication errors, such as not being able to move the axes connected to the 3hc or incorrect temperature readings connected to the 3hc. If I power off and on the machine, they synchronize as expected. I have other issues, but I will explain them after I run more tests. In this case, I think it's possible that I don't have stop.g configured correctly, as I have it the same as when I use Duet2.

Best regards,

Good morning @dc42,

Thank you for your response. Regarding blocking daemon.g, it is clear to me that it is not necessary. It was likely a feeling I had due to the behavior I observed, and I decided to block it to be sure, but I have now removed it from my code.

Regarding "stack," it is probably a mistranslation; I mean the movement queue (M596 P0 or P1).

As for your last comment, I just tried it and still have to use M569 P1 because if I don't use it, it does not execute in the desired times. Even using M669 T0.1 S1, the execution response of daemon.g is slow. Here are the details of how I conducted the tests.

Gcode being printed:

; G-Code generated by INDART3D G21 ; Metric values T0 P0 ; Select Tool G28 ; Home all G0 Z900 M400 ; Wait for current moves to finish ; Macro G1 X0 Y0 F3000 G1 X1000 Y1000 G1 X0 Y1000 G1 X1000 Y0 G1 X0 Y0 F3000 G1 X1000 Y1000 G1 X0 Y1000 G1 X1000 Y0 G1 X0 Y0 F3000 G1 X1000 Y1000 G1 X0 Y1000 G1 X1000 Y0 G1 X1000 Y0 G1 X0 Y0 F3000 ; The gcode keeps repeating these commands hundreds more times

daemon.g modified with your instructions:

; M596 P1 if (state.status == "processing") && (sensors.gpIn[1].value == 1) && (global.DaemonActive < state.upTime) M106 P3 S1 set global.TimerPelletsT0 = state.upTime + 6 echo >>"0:/sys/Alimentador Registro" {global.ContPelletsT0} ; Log of number of unsuccessful attempts while state.upTime < global.TimerPelletsT0 ; count off the fill time if sensors.gpIn[1].value == 0 ; Check for pellets M106 P3 S0 G4 P500 ; M400 ; Perform a short wait before checking if sensors.gpIn[1].value == 0 ; Check that it was not a false detection set global.TimerPelletsT0 = state.upTime - 6 M300 S5000 P500 else ; A false detection was detected, continue. M106 P3 S1 G4 S1 ; M400 M106 P3 S0 set global.DaemonActive = state.upTime + 20 ; set the new time to allow compressor refill if sensors.gpIn[1].value == 1 ; is hopper still empty? set global.ContPelletsT0 = global.ContPelletsT0 + 1 else set global.ContPelletsT0 = 1 if global.ContPelletsT0 > 10 set global.ContPelletsT0 = 1 ; M596 P0 M25 M291 R"Material Sensor" P"No Pellets detected" S2 T0

The result I get is the same. Right now, I am testing with an empty system, so sensors.gpIn[1].value is always equal to 1. The issue is that without using the secondary motion queue, it does not respect the 6 seconds, it always takes longer than desired, and it always turns off or on at the end of the complete Gcode lines, despite being fragmented with M669 T0.1 S1.

Best regards,

@Aitor the IO_IN inputs of the Duet already include a pullup resistor.

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.

1696512386675-captura.jpg

I look forward to your response.

Best regards,
Aitor

@Aitor The errors on printer 3 may indicate the SD card is failing, so try replacing that.

For printer 5, it may be the module is failing. Can you try reflashing the wifi firmware or even trying the new wifi beta firmware and see if it has any impact. If the SD card is old there as well, might be worth a change out.

@dc42 That is correct. When shutting down in open-loop mode what happens is: (in this order)

Power off by hand (unplugging power cord) or emergency stop by DWC motors lose currect (lose their holding torque) and gantry moves down. after a slight delay (0.5sec) brakes engage bc of loss of power and stop the gantry from falling further down.

When the gantry weight was still 250kg's the brakes couldnt stop the downward movement and it continued to fall down.
Now we have 2x 100kg's counterweights and the ''weight'' of the gantry is now 50kg's. So now they can stop it when it falls. But that doesnt happen anymore as long as i do the shutdown procedure.

Startup procedure:

At startup it runs the config file wich contains M569 P50.0 S0 D4. (closed-loop without tuning maneuvre so brakes are engaged) after that i manually run a startup macro: M569 P50.0 S0 D0 and run open loop mode.

Shutdown procedure:

Run macro wich only contains 5x M569 P50.0 S0 D4. for all the motors (to engage the brakes again) Power off (unplug the cord)

.
NOTE: When updating the boards to new firmware, the motors lose holding torque AND the brakes are dis-engage. wich makes the gantry fall down too. i dont know if its in open-loop or closed loop when starting the update, but i could replicate this if you like.

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 @HERVE_SMITH and @PHAEDRUX,

I greatly appreciate your response, as it allowed me to solve my problem. The truth is that I was unaware of many of the parameters offered by M569. Thank you again.

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

Thank you @T3P3Tony for your response, it's helpful to know that it will be implemented sooner or later.

Good morning,

Thank you very much @jay_s_uk, the problem is indeed solved.

Best regards

Good morning @CHRISHAMM and @DC42

Thanks for your replies, I'll stop looking then.

Best regards
Aitor

Good morning @DC42,

Thank you very much, you don't know how glad I am to hear it, I'm looking forward to try beta2, I'll be preparing my codes to test it.

It's really wonderful to work with you

Best regards
Aitor

Good morning @dc42, @stephen6309, @maracmb

I'm doing a test with a machine with 4 independent heads, to verify if I can put more heads on the machine.

I look at the link you sent me and I'll check my options.

Thanks