Posts made by louvanna

Thank you for all communications.
The printer is well on its way to return to an active role in creative projects.

Thank you for the replies.
Firmware updates 3.3 & 3.5.3 without issue.
The older config.g file requires modernization.
Two lines are updated to give a error/warning free startup.
File, config.g is enclosed per a request.

Lou

Progress:
Start:
9/26/2024, 9:36:22 AM M115
FIRMWARE_NAME: RepRapFirmware for Duet 2 WiFi/Ethernet FIRMWARE_VERSION: 3.2.2 ELECTRONICS: Duet WiFi 1.02 or later FIRMWARE_DATE: 2021-02-11

Upload and install 3.3: -- success
9/26/2024, 9:43:29 AM M115
FIRMWARE_NAME: RepRapFirmware for Duet 2 WiFi/Ethernet FIRMWARE_VERSION: 3.3 ELECTRONICS: Duet WiFi 1.02 or later FIRMWARE_DATE: 2021-06-15 21:45:03

Upload and install 3.5.3: success with errors
9/26/2024, 9:53:41 AM M115
FIRMWARE_NAME: RepRapFirmware for Duet 2 WiFi/Ethernet FIRMWARE_VERSION: 3.5.3 ELECTRONICS: Duet WiFi 1.02 or later FIRMWARE_DATE: 2024-09-18 11:25:32

With errors to be addressed:
9/26/2024, 9:52:12 AM Failed to load DWC plugin Height Map
Plugin Height Map not found ( a remnant of recent bed calibration attempt )
9/26/2024, 9:52:13 AM Error in start-up file macro line 7: No PS_ON port defined

The start-up file listed in the console is ambiguous. My take was the config.g file and after running M98 to confirm my interpretation of my ATX power-supply needs a port definition.

9/26/2024, 10:09:13 AM M98 P"config.g"
Error: No PS_ON port defined
HTTP is enabled on port 80
FTP is disabled
TELNET is disabled
Tool 1: offsets X0.000 Y0.000 Z0.000
Error: Attempt to move motors when VIN is not in range

lineno 7: old and new
M81 ; send ATX off, allows DWC to show button
M81 C"pson" ; allocate the PS_ON pin to power control but leave power off

I will also attempt to find all other power supply maco commands and exploit the new functionality available in 3.5 firmware.

This progress leads to two successive errors each due to power-supply not 'ON' for the last line, T0.

9/26/2024, 10:22:27 AM Error: in file macro line 15: G1: insufficient axes homed
9/26/2024, 10:22:25 AM Warning: Tool 0 was not driven because its heater temperatures were not high enough or it has a heater fault.config.g

Commenting out the 'T0' tool selection clears these error/warnings.
Now to determine of this initial 'T0' convenience is needed elsewhere.

I have pulled out a known good working delta printer from the closet, and dusted it off. I will be adding modernizations ( suggestions welcome ).
It has a Duet 2, w/ v3.2.2 firmware, and WiFi v1.25.
The Panel Due is v1.24
No SBC.
I typically had used DWC to interact with this printer.

My questions are these,

1. latest stable version to target for an install.
2. upgrade path, full jump in version or steps,
3. sequence of upgrades , duet, wifi, and panel.

Your guidance is kindly requested.

@dc42 You understand correctly, yes my bed heater is spiral and DC-12V
The thermostat switching causes a change in current, on/off, which is dB/dt. This then induces a voltage in the strain conductor. That spiral heater has also been modelled, and analysed for the stimulus in my simulations. A labyrinth heater conductor would have less magnetic flux, but still potentially enough to trip the strain threshold. Gladly, amend this work to a main-line bed heater, etc.

I will email the document from my other workstation, when I log-in next day.

The strain gauge in the Duet3D smart effector is susceptible to changes in magnetic flux, dB/dt. Specifically, the bed heater under thermostatic control, and I suspect to a lesser extent the local hotend heater. ( This is not the magnetic ball susceptibility due to Hall-effect on various electronic devices. )

The lack of magnetic immunity causes programming of the bed levelling and compensation routines to halt thermostatic control of the both a heated bed, as well as the hot-end. While the bed is probed, these devices are in the off-state. This then causes the temperature to drift, cooling. I have not quantified the dimensional shift imparted by this thermal transient. I have however wished to overcome the delay required to re-heat the devices in the overall multi-step routine.

I have analysed and simulated the necessary update(s) to the SE, which were pulled from the Github. I have generated a report/presentation on the needed, minor updates to achieve a greatly improved magnetic immunity. This forum is possibly not the correct place for such a document.

I would like to deliver to the designers of the SE this report such that its findings might be incorporated in the next revision of the SE. I have applied best practices for strain gauge as well as my knowledge of magnetic susceptibility to achieve a much improved device.

A little of my background. My professional career is currently focused on the simulation of electro-magnetics. Currently, I am employed as an engineer in MRI industry, developing next generation medical devices and the MRI system itself, which must be capable of functioning in the highly stressful MRI environment. I have at my disposal very large compute GPU clusters, which were employed in the simulation of a virtual SE.

New bearings arrived from the parts order.

Five of 12 bearings in the three tower skates/carriages had noticeable play. I replaced all 12, as they are not terribly expensive, $0.75 ea. The new height map using the stock "_First Probe" macro which runs both G32 and G29 on a heated bed, resulted in the following heightmap.csv

-120.00,120.10,-120.00,120.10,125.00,20.00,20.00,13,13
0, 0, 0, 0, 0, -0.113, -0.076, -0.008, 0, 0, 0, 0, 0
0, 0, 0, -0.026, -0.036, -0.061, -0.013, 0.009, 0.012, 0.097, 0, 0, 0
0, 0, 0.031, -0.017, -0.072, -0.041, -0.013, 0.015, 0.027, 0.060, 0.123, 0, 0
0, 0.052, 0.029, 0.008, -0.024, -0.039, -0.037, -0.034, -0.039, -0.037, -0.001, 0.094, 0
0, 0.028, -0.040, -0.059, -0.077, -0.067, -0.078, -0.043, -0.029, -0.022, -0.004, 0.028, 0
0.063, 0.028, 0.001, -0.016, -0.044, -0.075, -0.101, -0.096, -0.099, -0.105, -0.103, -0.101, -0.000
-0.016, -0.072, -0.095, -0.083, -0.088, -0.100, -0.111, -0.099, -0.085, -0.102, -0.090, -0.102, -0.088
-0.028, -0.021, -0.022, -0.045, -0.037, -0.079, -0.102, -0.140, -0.138, -0.130, -0.158, -0.185, -0.172
0, -0.104, -0.072, -0.101, -0.078, -0.087, -0.075, -0.097, -0.121, -0.133, -0.137, -0.164, 0
0, -0.089, -0.071, -0.036, -0.036, -0.067, -0.103, -0.116, -0.145, -0.158, -0.182, -0.197, 0
0, 0, -0.071, -0.072, -0.075, -0.046, -0.058, -0.090, -0.088, -0.138, -0.159, 0, 0
0, 0, 0, -0.034, -0.011, -0.010, -0.048, -0.073, -0.075, -0.096, 0, 0, 0
0, 0, 0, 0, 0, 0.011, 0.058, 0.061, 0, 0, 0, 0, 0

The third candidate, belts, were deemed adequately tensioned, and this heightmap suggests that to be a proper conclusion.

This looks to be just a wear-out scenario. The machine had 2500 hours of usage.

Update on axial play in the carrier/skate bearing/wheel.

The axial play is not in the skate/carrier assembly but rather in the bearing itself. Therefore no shimming will be effective. So, waiting for the shipment of parts before any advancements on this aspect of a precision machine.

While I'm waiting for parts. Candidate #2,
Ball joint looseness, is so small it is not measurable. The total linkage of effector,ball,arm,ball,carrier/skate has a change in length <10um under pull/push forces.
Since this is an original kit from 2017, wear could be anticipated. The original effector is now a new SE300 to be compatible with the Duet electronics. It has the AL ball mounts. The rest is original RostockMax3.0 composite arms, original balls at the carrier/skate.
It is doubtful that this small or immeasurable play is a contributor to my problems.

Anyone take issue in my conclusion on candidate #2 ?

First candidate in, 'What is loose?'

The three tower skates have assemblies of four bearing&wheels about the 't-slot' extrusion tower. The there is an axial displacement of approximately 1 mm for one of two wheels nearest the delta arm ball mounts . The lower wheel pair and the third are without play.

I have not yet done the math, but this would look like a change in radius for one of two arms of one tower. The other tower skates are have less movement, but noticeable.

I will be placing a shim washer, temporarily to see how much impact this has on the overall inaccuracy. Replacement/improved parts are on order.

https://reprap.org/wiki/Delta_geometry

Using the G32 ( bed.g) , and G29 from the configurator gave a hint of a non-realistic flatness of the borosilicate glass bed for my delta, RostockMax 3.2 equivalent, Duet 2.0, & SE300. The origin of the machine is a 3.0.

FIRMWARE_NAME: RepRapFirmware for Duet 2 WiFi/Ethernet FIRMWARE_VERSION: 3.2.2 ELECTRONICS: Duet WiFi 1.02 or later FIRMWARE_DATE: 2021-02-11

The stock probing pattern is an out-n-back zig-zag pattern. This then shows the much talked about alternating high and low ridges in the visualization.
Rotating the glass 90 degrees, does not rotate the ridges. This has led me to consider that the glass is fine but start looking for loose parts, belts, joints, etc.

I wrote a custom G30 macro which has a 10 mm grid. But rather than the out-n-back sequence of probing, I chose to use a square spiral CCW, which changes the pattern to a new artifact.

This probing sequence was to match the observed first layer problems of a large square box, where the turns are over extruded, followed by after turn, a too close to the glass causing back pressure on the extruder, which eventually is released as the height error normalizes.

Repeating the same ( or any ) probing profile many times has a 0.037 mm max deviation from a prior runs for each of the 579 probe points. So the repeatability is excellent, and what ever impact the 'looseness' imparts is consistent.

The map has a strong diagonal component which is the change in direction of the probe sequence. Upon turning, the reported probe height drops for each quadrant of the spiral.

So now for the question.
What are the likely suspects to replace, tighten, etc.?

Number of points: 579 Probing radius: 135 mm Probe area: 573.4 cm² Maximum deviations: -0.548 / 0.676 mm Mean error: 0.007 mm RMS error: 0.172 mm

Was asked to repost this here. ( same title)

3/7/2021, 10:28:48 AM M115
FIRMWARE_NAME: RepRapFirmware for Duet 2 WiFi/Ethernet FIRMWARE_VERSION: 3.2.2 ELECTRONICS: Duet WiFi 1.02 or later FIRMWARE_DATE: 2021-02-11

The result of an heater auto-tune provides a prototype line for inclusion in a config, or use M500 to write into config-override.g.

The message and the written lines are inconsistent. Not sure it matters .

3/7/2021, 9:46:34 AM Auto tuning heater 1 completed after 3 idle and 5 tuning cycles in 347 seconds. This heater needs the following M307 command:
M307 H1 R3.758 C126.5 D7.32 S1.00 V12.2
Send M500 to save this command in config-override.g

The line in the config-override.g is different.

Numerical precisions
inclusion of B0

M307 H1 R3.758 C126.499:126.499 D7.32 S1.00 V12.2 B0

Not being fully aware of the defaults, etc., so I cannot say that this important. This may simply be 'house keeping'.

3/7/2021, 10:28:48 AM M115
FIRMWARE_NAME: RepRapFirmware for Duet 2 WiFi/Ethernet FIRMWARE_VERSION: 3.2.2 ELECTRONICS: Duet WiFi 1.02 or later FIRMWARE_DATE: 2021-02-11

The result of an heater auto-tune provides a prototype line for inclusion in a config, or use M500 to write into config-override.g.

The message and the written lines are inconsistent. Not sure it matters .

3/7/2021, 9:46:34 AM Auto tuning heater 1 completed after 3 idle and 5 tuning cycles in 347 seconds. This heater needs the following M307 command:
M307 H1 R3.758 C126.5 D7.32 S1.00 V12.2
Send M500 to save this command in config-override.g

The line in the config-override.g is different.

1. Numerical precisions
2. inclusion of B0

M307 H1 R3.758 C126.499:126.499 D7.32 S1.00 V12.2 B0

Not being fully aware of the defaults, etc., so I cannot say that this important. This may simply be 'house keeping'.

M80 in config.g to default ON, and the DWC ATX button,
or
M81 in config.g to default OFF and the DWC ATX button.

Firmware now running correctly,
WiFi able to connect, etc.
Back to making config.g via configurator, compatible with 3.2.2.

closed.

Thank you for the URL.
I still have issues with WiFi/network.
The new config.g, etc have been transferred to the SD card an rebooted several times, but ....

Trying to understand what is yet incorrect.
From the terminal, it is apparent that the WiFi is not happy.

M115
FIRMWARE_NAME: RepRapFirmware for Duet 2 WiFi/Ethernet FIRMWARE_VERSION: 3.2.2 ELECTRONICS: Duet WiFi 1.02 or later FIRMWARE_DATE: 2021-02-11
ok
M552 S0
ok
M587
Error: M587: Failed to retrieve network list: another SPI transfer is pending

M115
FIRMWARE_NAME: RepRapFirmware for Duet 2 WiFi/Ethernet FIRMWARE_VERSION: 3.2.2 ELECTRONICS: Duet WiFi 1.02 or later FIRMWARE_DATE: 2021-02-11
ok
M122
=== Diagnostics ===
RepRapFirmware for Duet 2 WiFi/Ethernet version 3.2.2 running on Duet WiFi 1.02 or later
Board ID: 08DGM-9568A-F23SD-6J9DL-3SJ6Q-K9RMH
Used output buffers: 1 of 24 (2 max)
=== RTOS ===
Static ram: 23460
Dynamic ram: 73072 of which 0 recycled
Never used RAM 15548, free system stack 192 words
Tasks: NETWORK(ready,521) HEAT(blocked,308) MAIN(running,471) IDLE(ready,20)
Owned mutexes: USB(MAIN)
=== Platform ===
Last reset 00:00:29 ago, cause: power up
Last software reset time unknown, reason: User, GCodes spinning, available RAM 16760, slot 0
Software reset code 0x0003 HFSR 0x00000000 CFSR 0x00000000 ICSR 0x0043d000 BFAR 0xe000ed38 SP 0x00000000 Task MAIN Freestk 0 n/a
Error status: 0x00
Aux0 errors 0,0,0
MCU temperature: min 25.5, current 27.5, max 27.8
Supply voltage: min 0.0, current 0.1, max 0.1, under voltage events: 0, over voltage events: 0, power good: no
Driver 0: position 130618, ok, SG min/max not available
Driver 1: position 130618, ok, SG min/max not available
Driver 2: position 130618, ok, SG min/max not available
Driver 3: position 0, ok, SG min/max not available
Driver 4: position 0, ok, SG min/max not available
Driver 5: position 0
Driver 6: position 0
Driver 7: position 0
Driver 8: position 0
Driver 9: position 0
Driver 10: position 0
Driver 11: position 0
Date/time: 1970-01-01 00:00:00
Cache data hit count 37113105
Slowest loop: 4.94ms; fastest: 0.15ms
I2C nak errors 0, send timeouts 0, receive timeouts 0, finishTimeouts 0, resets 0
=== Storage ===
Free file entries: 10
SD card 0 detected, interface speed: 20.0MBytes/sec
SD card longest read time 0.9ms, write time 0.0ms, max retries 0
=== Move ===
DMs created 83, 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, chamberHeaters = -1 -1 -1 -1
=== GCodes ===
Segments left: 0
Movement lock held by null
HTTP is idle in state(s) 0
Telnet is idle in state(s) 0
File is idle in state(s) 0
USB is ready with "M122" 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
Daemon is idle in state(s) 0
Autopause is idle in state(s) 0
Code queue is empty.
=== Network ===
Slowest loop: 0.24ms; fastest: 0.00ms
Responder states: HTTP(0) HTTP(0) HTTP(0) HTTP(0) FTP(0) Telnet(0), 0 sessions
HTTP sessions: 0 of 8

• WiFi -
  Network state is starting2
  WiFi module is disabled
  Failed messages: pending 0, notready 0, noresp 0
  Socket states: 0 0 0 0 0 0 0 0
  ok

USB has enumerated, connection established.

For the record:
The ATX mod with external 5V, and such was the culprit.
Both jumpers 5V and E 5V are removed, to allow the USB to function.

I have the last firmware shown via M115 on my terminal, via USB:

FIRMWARE_NAME: RepRapFirmware for Duet 2 WiFi/Ethernet
FIRMWARE_VERSION: 3.2.2
ELECTRONICS: Duet WiFi 1.02 or later
FIRMWARE_DATE: 2021-02-11

I will go looking elsewhere for how to uncover all the incompatibilities moving up to 3.x.x.

Well, now I have a brick.
Uploading them numerically ordered, 2.05, 3.0, 3.2.2, with restart between each was good until 3.2.2.
I no longer have WiFi connection so limited to Panel, and hoping for USB, but ...
Apparently the ATX mod with the external 5V I jumper is incompatible with this state of machine.

The console is a rolling set of messages about various.

Temperature -273 ..
Error attempt to set/report offsets
Error attempt to move motors when Vin ...
Tool 0 not driven, because heater
G0/G1 insufficient homed axes ...
Failed to enable endstops ....
Warning obsolete user of S ......

USB connection is non-responsive to being enumerated.
( not sure if this is the ext 5V mod incompatibility)

A greater warning would have been appreciated.

Thank you, now, got that implemented, on to next tweak.

As they say, 'Read the manual.'
I guess during my quick read, I skipped over that parameter.

BTW, the default states 2 deg but my experience of watching the from my panel display it is 1 degree.

OK, looks like my firmware is prior to some change.

== Diagnostics ===
RepRapFirmware for Duet 2 WiFi/Ethernet version 2.02(RTOS) running on Duet WiFi 1.02 or later
Board ID: 08DGM-9568A-F23SD-6J9DL-3SJ6Q-K9RMH

Duet 2 WiFI board.
Printer is working great. Now, I want to go faster.
Extruder is a 2-into-1 on a delta printer.
Both materials are same temperature setting,
H1 = 200c and 200c-stby.
Cura 4.8.0 slicer.

During change of filament, with M116 involved ( wait ), I notice that the H1 rises above 200C to 203-205, and then H1 will need to wait to <=201C before it will resume. This is 4-9 seconds. This time adds up with hundreds of layers of dual color.

My speculative thought is to use Cura's anticipated tool change, where it coasts the selected tool heat prior to tool change. This would be coupled with H1-stby temperature of a few degrees cooler.

What would the forum suggest as a 'tweak' to be to remove this temperature rise and fall wait period?