Posts made by CR3D

undefined

Thanks to all!

undefined

I want to setup a Scanning Tool for our printers but can not find a wiring schematic in the documentation

Can you tell me how to connect pls?

Thank you in advance

undefined

@oliof

atm we tested the new BETA 3 Firmware and it runs...

I hope there will we a stable version soon

undefined

Hello Community, hi @dc42,

we have a setup with two duet 3 mini 5+ connected via CAN. The Z-axis and the extruder 0 are connected to board 1. After a print height of approx. 5mm, the extruder and the Z-axis no longer move and are without power. This is repeatable and has now occurred at least 5 times in a row.
M122 and M122 B1 deliver the following output and write errors on board 1:

M122
=== Diagnostics ===
RepRapFirmware for Duet 3 Mini 5+ version 3.4.5 (2022-11-30 19:41:16) running on Duet 3 Mini5plus WiFi (SBC mode)
Board ID: 519ZB-DP6KL-K65J0-409NA-LUW1Z-HBBTZ
Used output buffers: 1 of 40 (32 max)
=== RTOS ===
Static ram: 103652
Dynamic ram: 101084 of which 0 recycled
Never used RAM 33304, free system stack 118 words
Tasks: SBC(ready,2.0%,472) HEAT(notifyWait,0.0%,340) Move(notifyWait,2.0%,261) CanReceiv(notifyWait,0.0%,774) CanSender(notifyWait,0.1%,326) CanClock(delaying,0.0%,341) TMC(notifyWait,0.7%,72) MAIN(running,94.3%,557) IDLE(ready,0.1%,30) AIN(delaying,0.8%,263), total 100.0%
Owned mutexes: HTTP(MAIN)
=== Platform ===
Last reset 00:38:52 ago, cause: software
Last software reset at 2023-05-25 13:39, reason: User, GCodes spinning, available RAM 33304, slot 2
Software reset code 0x0003 HFSR 0x00000000 CFSR 0x00000000 ICSR 0x00000000 BFAR 0xe000ed38 SP 0x00000000 Task SBC Freestk 0 n/a
Error status: 0x00
MCU revision 3, ADC conversions started 2332209, completed 2332209, timed out 0, errs 0
Step timer max interval 1491
MCU temperature: min 40.1, current 52.1, max 53.8
Supply voltage: min 23.3, current 23.8, max 23.9, under voltage events: 0, over voltage events: 0, power good: yes
Heap OK, handles allocated/used 99/14, heap memory allocated/used/recyclable 2048/704/518, gc cycles 0
Events: 1 queued, 1 completed
Driver 0: ok, SG min 0, read errors 0, write errors 1, ifcnt 58, reads 57121, writes 15, timeouts 0, DMA errors 0, CC errors 0
Driver 1: standstill, SG min 0, read errors 0, write errors 1, ifcnt 56, reads 57122, writes 14, timeouts 0, DMA errors 0, CC errors 0
Driver 2: ok, SG min 0, read errors 0, write errors 1, ifcnt 58, reads 57120, writes 15, timeouts 0, DMA errors 0, CC errors 0
Driver 3: ok, SG min 0, read errors 0, write errors 1, ifcnt 58, reads 57120, writes 15, timeouts 0, DMA errors 0, CC errors 0
Driver 4: standstill, SG min 0, read errors 0, write errors 1, ifcnt 39, reads 57127, writes 9, timeouts 0, DMA errors 0, CC errors 0
Driver 5: not present
Driver 6: not present
Date/time: 2023-05-25 16:17:33
Cache data hit count 3750291069
Slowest loop: 322.10ms; fastest: 0.07ms
=== Storage ===
Free file entries: 10
SD card 0 not detected, interface speed: 0.0MBytes/sec
SD card longest read time 0.0ms, write time 0.0ms, max retries 0
=== Move ===
DMs created 83, segments created 34, maxWait 244257ms, bed compensation in use: mesh, comp offset 0.000
=== MainDDARing ===
Scheduled moves 67394, completed 67354, hiccups 0, stepErrors 0, LaErrors 0, Underruns [0, 0, 0], CDDA state 3
=== AuxDDARing ===
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, chamber heaters -1 -1 -1 -1, ordering errs 0
Heater 0 is on, I-accum = 0.1
Heater 1 is on, I-accum = 0.5
=== GCodes ===
Segments left: 1
Movement lock held by null
HTTP* is doing "M122" in state(s) 0
Telnet* is doing "G1 X172.184006 Y131.311996 E0.004710" 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 86930, received 24010, lost 0, boc 0
Longest wait 1ms for reply type 6018, peak Tx sync delay 39349, free buffers 18 (min 4), ts 11661/11657/0
Tx timeouts 12,0,3,0,0,2 last cancelled message type 4514 dest 127
=== SBC interface ===
Transfer state: 5, failed transfers: 0, checksum errors: 0
RX/TX seq numbers: 27356/27356
SPI underruns 0, overruns 0
State: 5, disconnects: 0, timeouts: 0 total, 0 by SBC, IAP RAM available 0x0f190
Buffer RX/TX: 2904/120-4056, open files: 0
=== Duet Control Server ===
Duet Control Server v3.4.5
Telnet:
Buffered code: G1 X172.184 Y131.312 E0.00471
Buffered code: G1 X171.829 Y132.154 E0.02771
Buffered code: G1 X171.375 Y133.084 E0.03137
Buffered code: G1 X171.135 Y133.515 E0.01494
Buffered code: G1 X171.228 Y134.203 E0.02104
Buffered code: G1 X171.258 Y134.365 E0.00501
Buffered code: G1 X171.414 Y135.046 E0.02117
Buffered code: G1 X171.435 Y135.123 E0.00243
Buffered code: G1 X171.605 Y135.673 E0.01745
Buffered code: G1 X171.468 Y135.882 E0.00759
Buffered code: G1 X170.826 Y136.716 E0.03187
Buffered code: G1 X170.488 Y137.159 E0.0169
Buffered code: G1 X170.277 Y137.387 E0.00944
Buffered code: G1 X170.163 Y137.517 E0.00523
Buffered code: G1 X170.066 Y137.611 E0.0041
Buffered code: G1 X169.771 Y137.862 E0.01173
Buffered code: G1 X169.673 Y137.943 E0.00386
Buffered code: G1 X169.259 Y138.25 E0.01562
Buffered code: G1 X169.201 Y138.291 E0.00215
Buffered code: G1 X168.839 Y138.53 E0.01314
Buffered code: G1 X168.725 Y138.6 E0.00407
Buffered code: G1 X168.065 Y138.985 E0.02315
Buffered code: G1 X167.865 Y139.09 E0.00684
Buffered code: G1 X167.16 Y139.444 E0.02392
Buffered code: G1 X166.676 Y139.66 E0.01608
Buffered code: G1 X166.114 Y139.903 E0.01854
Buffered code: G1 X164.964 Y140.336 E0.03726
Buffered code: G1 X164.899 Y140.363 E0.00213
==> 1344 bytes
Code buffer space: 2784
Configured SPI speed: 8000000Hz, TfrRdy pin glitches: 0
Full transfers per second: 39.88, max time between full transfers: 93.5ms, max pin wait times: 60.7ms/8.8ms
Codes per second: 30.57
Maximum length of RX/TX data transfers: 8120/1128

M122 B1
Diagnostics for board 1:
RepRapFirmware for Duet 3 Mini 5+ version 3.4.5 (2022-11-30 19:41:16) running on Duet 3 Mini5plus WiFi
Last reset 00:17:22 ago, cause: software
Driver 0: position 0, 80.0 steps/mm,, SG min 0, read errors 0, write errors 1, ifcnt 92, reads 54872, writes 9, timeouts 0, DMA errors 0, CC errors 0
Driver 1: position 0, 80.0 steps/mm,, SG min 14, read errors 0, write errors 1, ifcnt 115, reads 54870, writes 11, timeouts 0, DMA errors 0, CC errors 0
Driver 2: position 0, 4000.0 steps/mm,, SG min 0, read errors 0, write errors 1, ifcnt 92, reads 54871, writes 9, timeouts 0, DMA errors 0, CC errors 0
Driver 3: position 0, 80.0 steps/mm,, SG min 2, read errors 0, write errors 1, ifcnt 106, reads 54871, writes 9, timeouts 0, DMA errors 0, CC errors 0
Driver 4: position 0, 80.0 steps/mm,, SG min 0, read errors 0, write errors 1, ifcnt 102, reads 54872, writes 9, timeouts 0, DMA errors 0, CC errors 0
Driver 5: position 0, 80.0 steps/mm,, SG min n/a, read errors 0, write errors 0, ifcnt 0, reads 0, writes 0, timeouts 20, DMA errors 0, CC errors 0, failedOp 0x80
Driver 6: position 0, 80.0 steps/mm,, SG min n/a, read errors 0, write errors 0, ifcnt 0, reads 0, writes 0, timeouts 20, DMA errors 0, CC errors 0, failedOp 0x80
VIN: 23.9V, MCU temperature: min 41.4C, current 41.7C, max 47.0C
Peak sync jitter -400/401, peak Rx sync delay 200, resyncs 0/0, next step interrupt due in 186764851 ticks, enabled

The same setup on another machine is running well!

Thank you in advance

@benecito

undefined

@T3P3Tony

Yes Tony... if you use Z - ??? it works fine of course. This we use mostly.

But in some cases the Z Tooloffset of other Tools then Tool 0 is positive like T1 Z0.85 then there will be a gap like in the picture above.

We will implement it in the Toolchange macros but I think it is not the finest way... because with our easy toolchange system you can easy insert another tools with different length and then you have to adjust Tooloffset and open the software limit in the Toolchange macro...

Regards Christian

undefined

@T3P3Tony

The right tool (Tool 1) is higher than Tool 0 -> so the title is wrong... it is a positive tool offset...

Tool 0: offsets X0.000 Y0.000 Z0.000 U0.000
Tool 1: offsets X0.000 Y-0.650 Z0.724 U-0.300

@dc42

I also thought of that, but what speaks against allowing it directly in the firmware. If tool 1 was selected and it has a tool offset like this, I think you can open the software limits by this offset in this case?

Regards Christian

undefined

Unfortunately, we are currently encountering an old familiar topic again.

If you need negative values for the tool offsets because this tool is shorter than tool 0, then the bed cannot approach the nozzle of tool 1.

The software limits are set to 0 at Z to prevent any collision at tool 0.

M208 Z0:500

In my opinion, the software limit must be shifted by the negative ToolOffset so that a shorter tool can be used.

Everything else is not a clean solution in my opinion.

@PCR @dc42 what do you think therefore?

Thank you very much!

Regards Christian from @CR3D

undefined

@dc42 Hi David,

I have to join this conversation because through my contact to @Heartleander81 i noticed this effect with "round corners" at some of our machines to.

I think this comes with newer firmware and if you made some changes into PA there would be an issue. But how can we test it that it would be helpfull for you?

one of our customers has now contacted us explicitly about this effect and is looking for a solution. I can't compensate for it by increasing the PA value. We've tested a lot here.

Thank you Regards Christian from @CR3D

undefined

@dc42

I will make a new documaetation with the newest Firmware tomorrow.

The issue with the incorrect height after the tool change was fixed from you!

The only problem is the handling of the tool position (old position of the previous tool) after the toolchange... this is not working.

undefined

@dc42 with updated Toolchange behavior?

undefined

@t3p3tony Thank you for your Answer!

The command was just integrated because it was prescribed in the change log that it should now be used like this.

Basically, we've used it before because it's good to move over the component first and then lower Z when changing tools.

As I said, it just doesn't work anymore since the update!

No Gcode is necessary at all, this also happens if you last had the tool far outside and after the tool change the print head wants to go back to the old position and then crashes.

undefined

@dc42 any idea or better a solution for this?

undefined

@dc42 said in RRF 3.4 Beta 7 | Tool-Offsets Issue:

@cr3d did you read this item from the RRF 3.4 upgrade notes:

After changing tool, RRF no longer moves the new tool head to the coordinates at which the old tool head was at when the Tn command was actioned. In most situations this should not matter, because GCode generators usually generate commands to move to the correct XYZ position after generating a Tn command. Usually, they restore XY before Z. However, Cura does it the other way round, which risks dragging the tool head across the print. Therefore when using Cura, or in any other situations in which you want to restore the old behaviour, we suggest you add command G1 R2 X0 Y0 Z2 Fxxx followed by G1 R2 Z0 Fxxx to the end of your tpost#.g files, if you don't already use those or similar commands.

Sorry @dc42 DC42 that I still have to take up the topic, but what you claim here is simply not the case! The whole topic always worked without any problems before the update and since the update the new tool has moved exactly to the old position! This leads to many collisions and should be restored to the way it was before as soon as possible.

The required command is in tpost.g.

;wait for tool 1 heaters to reach operating temperature
M116 P1 S5

;go to
G1 X328 Y65 F50000 

;unretract
G11

;clean
M98 P"clean1.g"

;PCF fan on
M106 R2

G1 R2 X0 Y0 Z2    ; restore position 2mm above
G1 R2 X0 Y0 Z0    ; restore position

In the pictures you can see the left tool in front of the tool change to X=0mm and the right one in park position.

After the tool change, T1 (because it moves to the old position of T0) crashes into T0.

He also makes unnecessary movements during the print. The principle may work for tool changers, but not for IDEX printers.

It works so far, even if the print head is always somehow in the middle of the print bed before the tool change. But it often happens that this is also in the extreme positions and then there is a crash.

Please help or a solution.

As I said before all the changes, everything was perfect and it worked.

undefined

@dc42 Thank you!

It worked

undefined

Dear Community and @dc42 ,

we have installed a special print head for which we do not tap all four pins of the motor connector. All you have to do is rub off 2 phases and the integrated servo driver of the print head recognizes the speed and position to be driven. The problem here is that we are of course entitled to receive the driver error message. This in turn blocks our console in the long run and thus blocks the host when sending commands via USB. We are currently using firmware 3.4.1.

So my question is, how is it possible to display the message only once and then not further?
Disabling the driver is of course not an option.

Thanks for your help