Posts made by Alex.cr

@dc42 The binary for the 1LC worked to resolve the issue. Thanks for the fast turn around and I will continue beta.2 testing.

By the way it is a V1.1 version tool board.

I think I may have found a minor issue.
After upgrading to 3.6.0-beta.2 from beta.1, my extruder temperature is very inconsistent. Temps while the machine is just sitting idle will jump around several full degrees and when running a print will jump around about ten full degrees.

I tried turning on heater feedforward to see if it would help but M309 P0 S0.01 had zero effect on the results.

To help troubleshoot I downgraded just the 1LC back to beta.1 and the temp readings went back to being within 1deg. at idle and while up at temp.
Below is a screen shot showing my machine sitting at 180C with beta.1 installed and then uploading beta.2. No other changes made.

My machine is setup as follows.
6HC(SBC)+3HC+1LC+1HCL+1HCL.

So sad to hear about his passing. Thanks for your contribution @deckingman. You will be missed!

@chrishamm
Hoping you or someone else can help me out. I am trying to install the Motion plugin through DWC. I have upgraded to Bookworm (64 bit) and have all of the latest updates and firmware, 3.5.1. I am using a Pi4.

When installing the plugin I am running into an error as seen below. Any ideas?

Everything seems to be working well.

Are there any plans to update the motionwebcamserver plugin to allow it to work with 3.5?

https://github.com/Duet3D/DSF-Plugins/releases

@usinjin

First off, I am no expert with tuning the 1HCLs. That being said I have been using them since they first came out.

I would drop your D value down to D0.1. That will immediately quiet them down, and I found it to have little impact on the performance.

I would also increase your P value. The auto tuning function tried setting my P value down in the 20-ish range like yours and I noticed very poor performance. Just for testing sake I would try a higher number like R100.

The other thing that might help is to post a picture of your tuning graph.

@dc42

Awesome I missed that capability!

@c_ern

While I can't answer all of your questions I have a very similar setup with but with a 1LC V1.2.

1. I believe this is the case. I put a resistor in the wiring because it allowed for more flexibility in the future. May want to wait for others to chime in.
2. I think I was one of the first people to have a version 1.0 1LC on a V2.4 and ran into canbus errors when i ran standard wiring along the cable chain. Others didn't have the same problems I did. I ended up with shielded wiring and ran my Z axis stepper motors outside of the cable chain. That being said I think twisted wires are a minimum requirement for this length of run. You can always twist them yourself.
3. Yes you sure can do this.
4. If you can swing it I would just start with tap (or klicky). The Omron probe was finicky for me and melted several times. I've used the Omron probe, a Chinese version of the Omron, BLtouch, Klicky, and Tap. Klicky and Tap are by far the best.

The tap connects directly to the 1LC; in my case IO2.
Here is my current voron tap config:

;Voron TAP probe setup
M558 P8 C"!20.io2.in" T18000 F150 H5.0 A1 S0.01 B0 R0.0 K0
G31 K0 P25 X0.0 Y0.0 z-0.8

And just for reference here was my Omron config:

;NPN NO switch (stock voron sensor)
M558 P8 C"^0.io5.in" T18000 F600 H5 A3 S0.01 B0 R0.2 K0
G31 K0 P25 X0.0 Y25.0 z2.458					         ; set Z probe trigger value, offset and trigger height,

5. I didn't ground the board separately. Sorry can't help much with this one.
6. Not sure on this one, I need to do this still someday.

Hope this helps.

@Mr-Crispin

Yes the roto tool board comes with a connector pack, similar to the other 1LC boards.
.

@Phaedrux

Just did. Unfortunately no change.

Can confirm this issue as well. I have the same problem on my SBC setup. All boards upgraded to the new firmware but DWC and DSF are hung up on -rc1.

@moth4017

Nice that is a great addition.

@moth4017

Yes you are correct. I missed the _job part.

@moth4017

There might be a more elegant system than I use but here is what I do...

The following line is in the "end g-code" from my slicer.

echo >>"history_job.g" state.time^ ",file," ^ job.file.fileName ^ ",elapsed time," ^ job.duration 

This logs the end current time the print finishes and the elapsed time of the print in history.g. I created the file ahead of time in the system file structure and the ending of the print appends the files with lines of code for the successfully finished prints.

@Nordle

If your slicer is configured to use slicer based retraction it will use the updated parameters from the slicer using straight line g code. Specifying retractions with a simple G1 Exxx Fyyy type commands. If you use firmware retraction in the slicer it will send G10 and G11 commands to perform the retraction; RRF will then interpret those and use the parameters from M207.

I can also confirm this is a problem for me as well. I am using a 6HC with SBC. I have to power cycle the whole machine to get it through the issue. Simply rebooting the Pi4 will not solve the problem.

Here is an M122 after reboot.

m122
=== Diagnostics ===
RepRapFirmware for Duet 3 MB6HC version 3.5beta2 (2023-02-08 15:27:50) running on Duet 3 MB6HC v1.0 or earlier (SBC mode)
Board ID: 08DJM-956L2-G43S4-6J1FD-3SJ6T-TB6QH
Used output buffers: 1 of 40 (17 max)
=== RTOS ===
Static ram: 154344
Dynamic ram: 85824 of which 2892 recycled
Never used RAM 99556, free system stack 200 words
Tasks: SBC(ready,0.7%,418) HEAT(notifyWait,0.0%,325) Move(notifyWait,0.0%,342) CanReceiv(notifyWait,0.0%,798) CanSender(notifyWait,0.0%,335) CanClock(delaying,0.0%,340) TMC(notifyWait,6.0%,90) MAIN(running,92.5%,160) IDLE(ready,0.8%,30), total 100.0%
Owned mutexes: HTTP(MAIN)
=== Platform ===
Last reset 00:01:45 ago, cause: power up
Last software reset at 2023-03-10 21:36, reason: User, Gcodes spinning, available RAM 99556, slot 1
Software reset code 0x6003 HFSR 0x00000000 CFSR 0x00000000 ICSR 0x00400000 BFAR 0x00000000 SP 0x00000000 Task SBC Freestk 0 n/a
Error status: 0x00
Step timer max interval 132
MCU temperature: min 23.5, current 24.4, max 37.5
Supply voltage: min 0.2, current 24.0, max 24.1, under voltage events: 0, over voltage events: 0, power good: yes
12V rail voltage: min 0.2, current 12.2, max 12.2, under voltage events: 0
Heap OK, handles allocated/used 99/15, heap memory allocated/used/recyclable 2048/1472/1232, gc cycles 0
Events: 0 queued, 0 completed
Driver 0: standstill, SG min 0, mspos 8, reads 52289, writes 11 timeouts 0
Driver 1: standstill, SG min 0, mspos 8, reads 52289, writes 11 timeouts 0
Driver 2: standstill, SG min 0, mspos 8, reads 52282, writes 18 timeouts 0
Driver 3: standstill, SG min 0, mspos 8, reads 52282, writes 18 timeouts 0
Driver 4: standstill, SG min 0, mspos 8, reads 52282, writes 18 timeouts 0
Driver 5: standstill, SG min 0, mspos 8, reads 52283, writes 18 timeouts 0
Date/time: 2023-03-11 11:47:31
Slowest loop: 2.36ms; fastest: 0.06ms
=== Storage ===
Free file entries: 20
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, segments created 0, maxWait 0ms, bed compensation in use: none, comp offset 0.000
no step interrupt scheduled
=== DDARing 0 ===
Scheduled moves 0, completed 0, hiccups 0, stepErrors 0, LaErrors 0, Underruns [0, 0, 0], CDDA state -1
=== DDARing 1 ===
Scheduled moves 0, completed 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, chamber heaters -1 -1 -1 -1, ordering errs 0
Heater 1 is on, I-accum = 0.0
=== GCodes ===
Movement locks held by null, 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
File2 is idle in state(s) 0
Queue2 is idle in state(s) 0
Q0 segments left 0, axes/extruders owned 0x80000003
Code queue 0 is empty
Q1 segments left 0, axes/extruders owned 0x0000000
Code queue 1 is empty
=== Filament sensors ===
Extruder 0: no data received
=== CAN ===
Messages queued 892, received 4517, lost 0, boc 0
Longest wait 3ms for reply type 6053, peak Tx sync delay 49166, free buffers 50 (min 49), ts 528/400/0
Tx timeouts 0,0,127,0,0,0 last cancelled message type 30 dest 127
=== SBC interface ===
Transfer state: 5, failed transfers: 0, checksum errors: 0
RX/TX seq numbers: 3297/3297
SPI underruns 0, overruns 0
State: 5, disconnects: 0, timeouts: 0 total, 0 by SBC, IAP RAM available 0x26934
Buffer RX/TX: 0/0-0, open files: 0
=== Duet Control Server ===
Duet Control Server version 3.5.0-beta.2 (2023-02-08 11:47:09)
Code buffer space: 4096
Configured SPI speed: 8000000Hz, TfrRdy pin glitches: 0
Full transfers per second: 14.41, max time between full transfers: 286.2ms, max pin wait times: 34.3ms/7.2ms
Codes per second: 0.60
Maximum length of RX/TX data transfers: 4505/804

I posted how I handle this problem here:

https://forum.duet3d.com/topic/31641/how-to-set-heaters-temp-from-prusaslicer-in-start-g?_=1677801339355

@gnydick

I would look at the Rat Rig design as a starting point. They have corexy designs that are suited from 500x500.

I think its going to be hard to get 10k without significant ringing with the E3D toolchanger system on a machine that large. But I don't have direct experience trying to get that much accel or the E3D toolchanger. I just know my Voron 350 maxes out on printing accel at 4500 and travel at 6000 to avoid too much ringing.

@jay_s_uk said in How to set heaters temp from prusaslicer in start.g:

@Alex-cr theres no need to create variables like you have to pass information to a start macro.
You can pass things as parameters from the slicer. e.g.

Yes that's another good idea!

@Rodrigue-Richalland

start.g runs before the print file starts. Because of this you can't do exactly what you asked but you can do something close.

I created another file called startprint.g. Inside this file I placed most of what would go in my start Gcode in my slicer. I then set up variables in the start code in prusaslicer to set the variables and call startprint.g at the appropriate time.

Startprint.g:

;slicer variables in set start code
M207 P0 S{global.varRetractAmt} R0.0 F{global.varRetractSpeed} Z{global.varZhop}; firmware retract defaults
M572 D0 S{global.varPressureAdv} ;pressure advance for tool 0
M104 S180
M190 S{global.varBedTemp}
G32 ; home and level gantry 
G10 P0 S{global.varNozzleTemp}  R180;
M116 ; wait for tool temp
M98 P"/macros/print_scripts/nozzle_purge_wipe.g"
G01 X325 Y320 Z5 F12000
M98 P"homez.g"  ; home Z using the home Z file
M291 P"Cycle Start" S1 T30
G29 S1 ; load bed map
G1 X175 Y175 Z10 F20000

The start code in prusa slicer (and similar for my cura/simplify3d) looks like this:

G10 P0 S[temperature]  R180
M140 S[first_layer_bed_temperature]

set global.varPressureAdv = 0.04
set global.varRetractAmt = 0.6
set global.varRetractSpeed = 3600
set global.varZhop = 1.0
set global.varNozzleTemp = [temperature]
set global.varBedTemp = [first_layer_bed_temperature]

M98 P"startprint.g"  ; start code on print

Side note you need to place the G10/M140 or similar commands in your start code for prusaslicer/superslicer or it will try and add them itself and cause all sorts of havoc.

And the last bit of code needed to make this work is in config.g where you delcare the variables.

;presets for slicer variables in start code
global varPressureAdv = 0.04
global varRetractAmt = 0.6
global varRetractSpeed = 3600
global varZhop = 1.0
global varNozzleTemp = 240
global varBedTemp = 105

Hope this makes sense!

Edit: spelling