Topics created by e4d

@Festivejelly currently the G17/G18/G19 commands wait for all queued motion to stop before they are executed. So if they occur frequently in your file, that could cause the movement to be jerky. Your first file does have a G19 command just before each G2 or G3 command, so I think that explains it.

I think the reason why RRF waits for movement to stop before executing these commands is so that if power failure occurs, RRF is able to write a G17/18/19 command that is correct for the movement commands that will be executed if the job is resurrected. So I can't unconditionally remove that call to wait for motion to stop. However, I could remove that call in the case where the selected plane is not changed, which should help with your example.

@chrishamm it works well on my machines, thank you again for your time on my issue

@gloomyandy thanks. The reason is almost certainly insufficient RAM and flash memory on Duet 2. The MQTT support requires significant amounts of both.

I have updated the M586.4 documentation.

@e4d If you mounted the electronics in a metal box, can you confirm that the enclosure is properly grounded (GND)? You can stop DCS on the RockPi and check via gpiotools (gpioread AFAIR) if the input signal is correctly read once you hook up that line to GND and +3.3V respectively.

I think that you can send gcode commands from the ESP32 to the Duet to execute. Via HTTP or serial connection. I guess that this allows you to send gcode such as setting global variables that your conditional code can access. Others may know more details.

@e4d Please post your config.g and the response to M122. An overview picture of your machine would be helpful too, as well as the bed.g you are using. Because it looks to me like you have a tramming problem in the X axis (linear rods not parallel), and the dip in the Y axis is probably caused by the weight of the X gantry. It looks like you're using a pretty thick, solid piece of aluminium for the bed, which is likely to be pretty flat, so the deviation in the bed is likely to be something else.

What kind of probe are you using? If the probe is offset from the nozzle, and the tool head is heavy, a twist in the axis due to the weight of the tool may cause an over- or under-reading by the probe. A small twist in the axis can cause a big deviation in probed height.

Ian

@e4d another possibility is that the large number of http clients is causing RRF to run out of output buffers. On the 6HC we have enough spare RAM to increase the number of buffers.

@e4d I can see that the M42 command might get held up if you are doing a G2 or G3 move, or a long linear move and you have segmentation enabled. I think I need to change the logic so that when M42 is executed by the daemon, and the daemon hasn't commanded any movement since it last waited for movement to stop, the command is executed immediately without any attempt to sync it to the movement commands already queued.

Meanwhile, you may be able to get this working by putting one of the parameters in { } for example M41 P{13} S1. This will make the parser think that there is an expression to be evaluated, and in current firmware it will not attempt to sync the command with motion.

@e4d I suspect that one of the sensors may have a short circuit between the wire that is connected to VSSA and something else, such as adjacent metalwork.

@e4d PID is great for tight temperature control when you have enough heater power to change the temperature quickly, which you apparently don't have. Bang-bang control should be able to maintain the temperature within a few degrees and that's usually fine for printing plastic.

@e4d said in Problem with Duet3D Magnetic filament sensor:

measured sensitivity 2609.32mm/rev

This is one hundred times less sensitive than expected.

I suspect that the rotation-part is not able to rotate smoothly.

Try pushing a piece of filament through the sensor and watch the back of the shaft that has the magnet on it and see if it rotates smoothly.

Sometimes it takes a little adjusting of the thickness of the case to get the magnet-to-sensor distance right.

Also, your agc of 58 is quite low which indicates the magnet is very close to the sensor. Take it apart and look for scratches on the top of the sensor to make sure they are not touching. If so, just add some paper shims in the case and try again.

@e4d The way it is working is as intended (at least it is how it is coded and documented). So I'm afraid that your understanding does not match the current implementation (though arguably the way you expect it to work would perhaps be better).

From the docs:

The requested PWM value (S parameter) is scaled to be between 0 and X parameter value, and rounded up to the minimum

and from the code:

reqVal = (val <= 0.0) ? 0.0 : max<float>(val * maxVal, minVal); // scale the requested PWM by the maximum, enforce the minimum

https://github.com/Duet3D/DuetWebControl/blob/master/src/components/panels/FanPanel.vue#L64

So basically it takes the requested value (0.0...1.0) and scales that by the maximum set value, it then compares that with the minimum set value and uses the larger of the two.

I'm not totally sure why the current implementation is the way it is, there may be a good reason. Perhaps @dc42 would like to comment.

@e4d rename the daemon.g file and then you should be able to edit it

@e4d if you have "temperature rising too slowly" during a print that means there has been a substantial temperature drop during the print. The most likely cause is sudden additional cooling from the print cooling fan caused by the geometry of the print. A silicone sock may fix that.

@e4d if you upgrade to 3.4RC2 then it should not restore the position.

@jay_s_uk I had success with your proposition, thank you !

@mintytrebor thank you for your answer, it works great now

@e4d

You would need to measure the actual position of the shaft and the commanded position of the shaft to see the lack of torque during microstepping.

From the Faulhaber site:

What Does It Mean? The consequence is that if the load torque plus the motor’s friction and detent torque is greater than the incremental torque of a microstep, successive microsteps will have to be realized until the accumulated torque exceeds the load torque plus the motor’s friction and detent torque. Simply stated, taking a microstep does not mean the motor will actually move. In summary, although Microstepping gives the designer more resolution, improved accuracy is not realized. Reduction in mechanical and electromagnetically induced noise is, however, a real benefit.

@gloomyandy i tried your suggested steps and here is the result :

Boot duet and sbc Turn on heater from dwc panel The fan don't turn on I turn off the heater wait for the temperature to go under 70°C hit emergency stop turn on heater fan don't turn on emergency stop (heater hot) fan turn on wait for the temperature to go under 70°C fan turn off Turn heater on Fan don't turn on

Here's the output of the M122 command :

=== Diagnostics === RepRapFirmware for Duet 3 MB6HC version 3.3 (2021-06-15 21:45:47) running on Duet 3 MB6HC v1.01 or later (SBC mode) Board ID: 08DJM-956L2-G43S8-6JTD6-3SS6K-KA1AH Used output buffers: 1 of 40 (14 max) === RTOS === Static ram: 150904 Dynamic ram: 62348 of which 0 recycled Never used RAM 140940, free system stack 202 words Tasks: SBC(ready,5.0%,330) HEAT(delaying,0.0%,325) Move(notifyWait,0.0%,302) CanReceiv(notifyWait,0.0%,908) CanSender(notifyWait,0.0%,374) CanClock(delaying,0.0%,339) TMC(notifyWait,7.1%,93) MAIN(running,87.7%,1250) IDLE(ready,0.1%,29), total 100.0% Owned mutexes: HTTP(MAIN) === Platform === Last reset 00:01:43 ago, cause: power up Last software reset at 2021-09-29 11:43, reason: StuckInSpinLoop, GCodes spinning, available RAM 143016, slot 2 Software reset code 0x4083 HFSR 0x00000000 CFSR 0x00000000 ICSR 0x0040080f BFAR 0x00000000 SP 0x2041970c Task IDLE Freestk 43 ok Stack: 00479e85 0047a862 61000000 a5a5a5a5 00479e85 a5a5a5a5 a5a5a5a5 2041ad9c 0000aaea 20432ac4 20424c74 20419728 20424c6c 00000004 2042cda0 2042cda0 20419728 00000000 00000001 20419784 4e49414d 00000000 00000000 00000001 00000001 00eec918 00000000 Error status: 0x00 Step timer max interval 154 MCU temperature: min 35.8, current 36.5, max 47.7 Supply voltage: min 24.3, current 24.4, max 24.4, under voltage events: 0, over voltage events: 0, power good: yes 12V rail voltage: min 12.0, current 12.0, max 12.0, under voltage events: 0 Heap OK, handles allocated/used 0/0, heap memory allocated/used/recyclable 0/0/0, gc cycles 0 Driver 0: position 0, standstill, reads 53339, writes 15 timeouts 0, SG min/max 0/0 Driver 1: position 0, standstill, reads 53339, writes 15 timeouts 0, SG min/max 0/0 Driver 2: position 0, standstill, reads 53339, writes 15 timeouts 0, SG min/max 0/0 Driver 3: position 0, standstill, reads 53340, writes 15 timeouts 0, SG min/max 0/0 Driver 4: position 0, standstill, reads 53340, writes 15 timeouts 0, SG min/max 0/0 Driver 5: position 0, standstill, reads 53341, writes 14 timeouts 0, SG min/max 0/0 Date/time: 2021-09-29 11:52:03 Slowest loop: 0.46ms; fastest: 0.04ms === Storage === Free file entries: 10 SD card 0 not detected, interface speed: 37.5MBytes/sec SD card longest read time 0.0ms, write time 0.0ms, max retries 0 === Move === DMs created 125, maxWait 0ms, bed compensation in use: none, comp offset 0.000 === MainDDARing === Scheduled moves 0, completed moves 0, hiccups 0, stepErrors 0, LaErrors 0, Underruns [0, 0, 0], CDDA state -1 === AuxDDARing === Scheduled moves 0, completed moves 0, hiccups 0, stepErrors 0, LaErrors 0, Underruns [0, 0, 0], CDDA state -1 === Heat === Bed heaters = 0 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1, chamberHeaters = 1 -1 -1 -1 === GCodes === Segments left: 0 Movement lock held by null HTTP* is doing "M122" in state(s) 0 Telnet is idle in state(s) 0 File is idle in state(s) 0 USB is idle in state(s) 0 Aux is idle in state(s) 0 Trigger* is idle in state(s) 0 Queue is idle in state(s) 0 LCD is idle in state(s) 0 SBC is idle in state(s) 0 Daemon is idle in state(s) 0 Aux2 is idle in state(s) 0 Autopause is idle in state(s) 0 Code queue is empty. === CAN === Messages queued 844, received 8, lost 0, longest wait 1ms for reply type 6018, peak Tx sync delay 607, free buffers 49 (min 48), ts 517/516/0 Tx timeouts 0,0,0,0,0,0 === SBC interface === State: 4, failed transfers: 1, checksum errors: 0 Last transfer: 1ms ago RX/TX seq numbers: 2731/2870 SPI underruns 0, overruns 0 Disconnects: 1, timeouts: 0, IAP RAM available 0x2c810 Buffer RX/TX: 0/0-0 === Duet Control Server === Duet Control Server v3.3.0 Code buffer space: 4096 Configured SPI speed: 8000000Hz Full transfers per second: 15.42, max wait times: 4.7ms/0.0ms Codes per second: 0.01 Maximum length of RX/TX data transfers: 3579/64