Posts made by tmreith

@jay_s_uk
Worked great! Thanks for the suggestion.

Hello,
I am looking for the best method to upgrade from 3.4.5 to 3.4.6 without forcing an update to the latest stable release. (currently 3.5.3)

The standard Pi terminal method will jump to the latest stable or beta version depending on the duet3d.list file.

deb https://pkg.duet3d.com/ stable armv7

sudo apt update && sudo apt upgrade

SOLVED - used conditional gcode to control print zone. Reverted back to sensor attached to heater source. This provides a more stable control for the heater.
The conditional gcode reads multiple zone sensors to determine the adjustment needed to drive the heater.
Thanks for reviewing the post.

@dc42 said in PID Tuning for Unconventional Heater:

Are you saying that the distance between the reflector plate and the bed varies, and also that you are performing initial bed heating with the radiant heater turned on?

Yes, the reflector plate moves toward/away from the build plate. Yet, stays constant with the active extrusion plane. I have provided an image below.

There is very minimal air flow in the chamber and the sensor readings are stable.

The challenge is, as the reflector plate increments upward or towards the build plate, the relationship between the build plate and reflector plate changes. Also note that the build plate also acts as a reflector of some sort too.

The PID control properly request a blip of energy to bring the environment to the target temperature. There is a slight overshoot at this initial request. The PID control will pause and allow the environment temperature to drop towards the target temperature. This is all working great!

However, as we get closer to the set temp, the PID control will have small blips of energy requests for a "soft landing". This works great for traditional heating sources. In our case, the reflector plate emits high energy pulses of IR and radiant heat, so each time the PID control blips for a soft landing, the environment jumps 5-10c. Thus, slowing the recovery time.

An ideal behavior, would be that the PID control would allow the temperature to drop slightly below the target and reduce the amount of blips to allow the environment to stabilize more quickly.

Hello,
I have a high-temp (very high-temp) printer that uses a (reflector plate) directional IR/radiant heater that directs heat towards the active print. I use a zone RTD temperature sensor to monitor the active Z plane. In addition, there is a high-heat build plate that is set to 180-200°C.

The challenge is that when the active reflector plate gets closer to the build plate, the current PID (settings below) cause the temperature to overshoot and are slow to fall to the set temperature. I am not having heater faults, however the temperature overshoots 10-20°C.

Any suggestions of how to manually fine tune the current settings to be more stable and maintain temperature closer to the set temp +/- 3°C are welcomed.

I have referenced the Tuning the heater temperature control for help and it is close, but not close enough.

M307 H2
Heater 2: heating rate 0.763, cooling rate 0.453, dead time 7.50, max PWM 1.00, mode PID
Predicted max temperature rise 147°C
PID parameters: heating P31.2 I0.832 D163.8, steady P31.2 I1.632 D163.8

SOLVED - Cable
The cable used was a traditional RJ11 phone extension cable. The ends are not the same, which created the confusion of the wires being associated with L & H.
I've switched to a twisted pair cable and all is working as designed.
Thanks for the input and time, as I worked through this speed-bump.
For reference see the pics and notice the flipping of the cable.

@dc42 Yes, the cable is a standard RJ11 phone cable - flat RED/GREEN inner 2 with YELLOW/BLACK outer. Also purchased from Filastruder.

@droftarts The 1LC is version 1.3 and the 6HC is version 1.02. Both components were purchased through Filastruder in the USA.

I have spent two days trying to understand why I had to reverse the wiring of the CAN-FD cable from the 6HC board to the 1LC board. If I follow the posted instructions the 1LC does not connect. Has anyone else seen this behavior?

The 1LC has been soldered to enable the termination 120R circuit. I am currently connected via CAN1_H to CAN_L and CAN1_L to CAN_H - see pics below.

Any comments or suggestions are welcomed.

The following post mentions a similar behavior:
https://forum.duet3d.com/topic/23871/wiring-diagram-between-duet3-6hc-and-1lc

See attached images below.

@chrishamm SOLVED - Thanks
M400 did the trick.

Is there some form of "look ahead" with the Duet control interpreting the Gcode? I am using global variables to set values based on conditional events that occur in specific points within the gcode. For example after a specific layer is completed and a desired temperature is set.

However, I notice the variable is set before the linear motion has occurred. Is there a way to wait until a linear motion has completed before setting a variable?

For example - HAAS machine tools use G103 - see below

HAAS G103) Example Video

@T3P3Tony Works great! Thanks for the suggestions.

@dc42 Thanks David.
Would the global variable value be visible within the JSON response?

Hello,
The machine status returns the following based on the current machine state.

status: I=idle, P=printing from SD card, S=stopped (i.e. needs a reset), C=running config file (i.e starting up), A=paused, D=pausing, R=resuming from a pause, B=busy (e.g. running a macro), F=performing firmware update

Is there a method to provide a custom state based on a MCODE? or can we change the status to a different state using a MCODE?

I am pulling data from a JSON request and when the code steps through subsequent MACROS, I'd like to be able to identify based on the MACRO running. The "P" status is too generic to know what is running.

@chrishamm Yes, microSD card damaged and was in forced ready-only mode. I replaced with a new microSD A1 and back to normal. Thanks!

@T3P3Tony Yes, running SBC

Hello,
After updating system files and or adding new gcode files, the system recognizes the changes or additions. However, after rebooting the system, the file system reverts to an older date. Note, I have 4 machines with the identical setup, but I am only seeing this behavior on the one machine. Possible file corruption???

Currently running:
Board: Duet 3 MB6HC (MB6HC)
DSF Version: 3.3.0
Firmware: RepRapFirmware for Duet 3 MB6HC 3.3 (2021-06-15)

@tmreith
Works on a Duet 2 Wifi running 3.4.1.

Added the following to the last line in gcode file.

; num_layers: 64

@phaedrux
I added the following to the end of the gcode file, and there was no effect.

; num_layers=64

I looked at the source code for FileInfoParser.cpp and it definitely has a routine to parse "num_layers" keyword. I am not sure why the DWC doesn't seem to see the value.

I have another machine running 3.4.1, so I'll give it a try on that machine over the weekend.

@phaedrux
unfortunately not. The machines are validated to 3.3 and would require a re-validation effort if I updated the firmware.

Is there a layer count keyword that is still being used in the g-code? I can insert what ever DWC needs to establish a value vs trying to calculate from a Z height and the layer height value.