@ander Can you send M98 P"config.g"
and post the response from the console?
I've updated your post with the files, as it will make it easier to help you.
Ian
@ander Can you send M98 P"config.g"
and post the response from the console?
I've updated your post with the files, as it will make it easier to help you.
Ian
@Inlinebrother I doubt you will find a step-by-step guide to updating your FFCP, though other people have done it, see the results of this search: https://forum.duet3d.com/search?term=flashforge&in=titles
To update, gather as much information about the printer settings as you can before disassembly. For a guide to what's needed, see https://docs.duet3d.com/User_manual/Overview/Adapting
Then follow the 'How to guides' in the main wiki menu to connect up the board to the components of the printer. There is also the series of guides which cover installing a Duet 3 Mini 5+ in and Ender 3 Pro which may help, here https://docs.duet3d.com/en/How_to_guides/Getting_started
Unfortunately, we have no experience with 3rd party clone boards like the FYSETC Big Dipper, or what connectors they use. This forum is generally for Duet3D hardware and RepRapFirmware support officially, though you are free to post here and you may get some generous user who is prepared to help.
Ian
@paolozampini1973 Any reason you don't want to update Cura? The current version is 5.7.1. As far as I know the 'Duet RepRapFirmware integration' plugin works, though I haven't tried it as I mostly use PrusaSlicer. You can get old versions of the plugin from: https://github.com/Kriechi/Cura-DuetRRFPlugin/
Ian
@Proschi78 said in DIY IDEX, Mini5+, Roto Toolboard and CAN-Bus Issues:
@droftarts said in DIY IDEX, Mini5+, Roto Toolboard and CAN-Bus Issues:
leave the CAN bypass jumpers for Tool 1 on the TDB in place, which will loop the CAN bus on to...
I thought that unused ports kept the jumper ?
Yes, they do, I didn't say to remove them. Tool 0 and Tool 1 are stubs, so they keep their jumpers too, so all bypass jumpers stay in place. Then the TDB can provide the termination. See this diagram I did for the thread here: https://forum.duet3d.com/post/339187
Ian
@ander please post your config.g and config-override.g, as text (and ideally code) rather than pictures.
Ian
@WOPR73 Regarding your wiring, it is fine... for now. It's set up like this:
(Note: diagram for illustrative purposes only to show how CAN bus connects, pinout on boards may not be correct)
As you can see, the Tool Distribution Board isn't doing much. It will work, but as I said before here https://forum.duet3d.com/post/338611, you won't be able to add any more toolboards connected to the Tool Distribution Board, as currently the CAN bus ends at the Scanning Z Probe. To enable the other Tool # outputs on the TDB, you need to:
With the above, the 1LC and SZP connected to 'Tool 0' on the TDB are wired as a 'stub' off the main CAN bus. This means the maximum length of the whole 'stub' (from TDB to 1LC to SZP) needs to be 1m maximum. It's okay to have the 1LC and SZP on the same stub. To maximise the length between the 1LC and the TDB, keep the wires between 1LC and SZP as short as possible. You could end up with something like this:
When you add further tools, you can either wire them as 1m-long 'stubs' like Tool 0 (eg the Roto toolboard on Tool 2), or run the CAN bus to the toolboard and back, like the standard 1LC wiring (eg the 1LC on Tool 1), which can then be a much longer length. Note that the combined total of all stubs should be less that 5m.
Ian
@WOPR73 on the wiki page, on the main menu in blue on the left hand side, have you seen the “How to guides"? These should guide you through connecting most peripherals to the mainboard. Connecting to toolboards is largely the same. It also guides you through configuration, commissioning and tuning.
The nature of the Duet ecosystem creates many unique and varied implementations. It’s impossible to document every single permutation. There is a huge amount of documentation for connecting and configuring devices, I think you haven’t explored the wiki pages. See https://docs.duet3d.com/en/User_manual/Connecting_hardware
Links for all the Duet boards hardware pages are here: https://docs.duet3d.com/en/Duet3D_hardware/Duet_3_family
Those pages have details on connecting and configuration that is specific to each board, while more general connections are linked to other pages, to avoid too much duplication of text. It would be nice to be able to have all information for your setup on one page, but it would be a very long page! The configtool also has links to specific wiki page for each section.
Thanks, I’ll check what firmware files the config tool provides. -> Yes, the firmware version bundled appears to be 3.5.0-rc.3, not 3.5.1. This should be rectified today. -> Fixed now. You may need to clear your browsers 'Cached Web Content' and redownload the config.zip file to get the updated version.
The configuration files it generates work with all versions of 3.5 (beta, release candidate and release), and will mostly work with older versions back to RRF 3.0, though there have been changes over time. There's also the 'legacy' version for older versions.
While you absolutely should use the same version of RRF on mainboard and toolboards, and we recommend using the same version of DWC and RRF, there's a bit more leeway with the version of DWC. The incompatibility notice is more to remind you to update it.
Are you actually running in SBC mode, with the Raspberry Pi? You should follow the instructions here: https://docs.duet3d.com/User_manual/Machine_configuration/SBC_setup
Updating: https://docs.duet3d.com/User_manual/Machine_configuration/SBC_setup#update-firmware
If running in standalone mode, updating firmware and DWC is covered here: https://docs.duet3d.com/User_manual/RepRapFirmware/Updating_firmware#usual-procedure
Thanks, I’ll check why the QR code isn’t working; probably just the link is incorrect. -> fixed now.
Ian
@trulm I've been meaning to draw some diagrams for this page https://docs.duet3d.com/en/User_manual/Machine_configuration/CAN_connection but there really are a lot of different, and equally valid, ways to wire CAN.
For connecting the Roto toolboards to the Tool Distribution Board (TDB), you can wire them as stubs straight from that. See the wiring diagram here: https://docs.duet3d.com/Duet3D_hardware/Duet_3_family/Duet_3_Tool_Distribution_Board#wiring-diagram
Plug the Mini 5+ into the TDB CAN IN RJ11 port. You'll need to make up a cable to connect the Mini 5+ 2-pin KK CAN connector to an RJ11 plug.
The CAN bus uses differential wiring, which means you need to connect each CAN_H pin to the CAN_H pin on the the next board, and each CAN_L pin to the CAN_L pin on the next board.
To wire the TDB with stubs, start with the Tool 0 output. Connect wires from CAN_H and CAN_L to CAN_H and CAN_L on the first Roto. This is now a 'stub' on the CAN bus; the CAN bus won't continue on from the toolboard. The wires to this toolboard should be under 1m long. Leave the CAN bypass jumpers for Tool 0 on the TDB in place; these will connect the CAN bus on to...
The Tool 1 output on the TDB. Again, connect wires from CAN_H and CAN_L to CAN_H and CAN_L on the second Roto. Again, this is a 'stub'. Each stub should be under 1m long, and the total length of stubs on the CAN bus shouldn't be more than 5m. Again, leave the CAN bypass jumpers for Tool 1 on the TDB in place, which will loop the CAN bus on to...
Termination. Don't fit the termination jumpers on the Roto toolboards. Fit the termination jumper on the TDB.
A @gloomyandy says, you'll need to set up each Roto board one at a time, to set the CAN address of each one. The advantage of the above wiring scheme is that you can just disconnect each toolboard from the TDB, you don't need to change any other wiring.
Ian
@Aurimas said in Filament error on extruder 0: sensorError:
why would it run sometimes for hours and hours on the same printer and then throw an error every 15min?
If I knew that, I'd just tell you what to fix!
Ian
@omtek said in 3.5.1 - 'Error: Pop(): stack underflow on Aux':
Is it worth trying out the new Bookworm image for troubleshooting now that it appears the error is specific to SBC mode?
You can certainly give it a go, if you want! As it seems to be related to SBC mode, I'll ask @chrishamm to look at this.
Ian
@omtek is there anyway you could setup in standalone mode (no RPi/SBC) and test if you have the same behaviour? That might help point out if it’s a firmware issue, or DSF. Is there anything else unique about your setup?
Ian
@GeneRisi Great, thanks for testing. @rechrtb please can you update the documentation here, and show a config.g example? https://github.com/Duet3D/MQTT-WPA2-Enterprise-Demo
Maybe explain the daemon.g workaround? As I expect the fix won't be released before RRF 3.5.2, so for all those on earlier versions.
Ian
@Adamrobot said in Issue with Diagonal Movement of Printhead After Firmware Update:
M308 S1 P"e0temp" Y"thermistor" A"T0" T100000 B4725 C7.06e-8 ; Set thermistor
M950 H1 C"e0heat" T1 ; Extruder 0 heater
M143 H1 S420 ; Set temperature limit for heater 1 to 300C
Your config.g has the H1 temperature sensor (M308 S1 line) defined as a thermistor.
When you change it to a PT1000, I expect it resets the M143 (not M147) temperature limit to the default.
Change the M308 line in config.g.
Ian
@Jords27 CAN_0 is currently not enabled in the standard firmware; you would need to compile your own firmware to do that. Support has been added (but not enabled as standard) for plain CAN (not CAN-FD) on CAN_0, and has been used in machines with custom firmware, ie Hangprinter, where it's used to communicate with ODrive motor drivers to configure them.
I asked @dc42 if it is possible to:
CAN is a linear bus system, using differential wiring (ie one wire is High, the other LOW, which makes it more resistant to interference), so apart from the devices at the ends (one of which is the Duet main board) each device needs CAN wires from the previous device and CAN wires to the next device.
Most Duet Expansion boards have two connections with 4 wires to make the wiring easy; pre-made RJ11 cables can be sourced easily, and there's space on the boards for both connectors. It also future-proofs the boards in the eventuality that CAN_0 is used, as it carries this bus too, to where ever you need it.
Toolboards like the Roto are usually at the end of the bus, so it's less important that they loop on to the next board, and the bus can be terminated on this toolboard. However, if you need to loop on to another board, you can have short 'stubs' attached to the CAN bus. The stub length should be limited to 1m.
Ian
@AndMaz Which Duet board, WiFi or Ethernet? If you could do an M122 while it's happening, and another when it's fine, there maybe some information in the Network diagnostics that might be useful.
Ian
@Aurimas said in Filament error on extruder 0: sensorError:
From the M122 B121 report:
Bootloader ID: SAMC21 bootloader version 2.4 (2021-12-10)
Bootloader v2.4 is an older version, though there's not much that changes between versions. However, it might be worth seeing if updating this helps. This is easy to do, see https://docs.duet3d.com/en/User_manual/RepRapFirmware/Updating_bootloader
Files are here: https://github.com/Duet3D/Duet3Bootloader/releases/tag/2.8
Never used RAM 2108, free system stack 17 words
I don't think the issue is caused by running out of memory. It doesn't say it has. I'll ask @dc42 if this is particularly low. What is connected to the 1LC?
Driver 0: pos 100779577, 400.0 steps/mm,standstill, SG min 2, read errors 0, write errors 0, ifcnt 55, reads 22960, writes 0, timeouts 0, DMA errors 0, CC errors 0, steps req 0 done 0
Moves scheduled 713681, completed 713681, in progress 0, hiccups 0, step errors 0, maxPrep 0, maxOverdue 0, maxInc 0, mcErrs 0, gcmErrs 0
Peak sync jitter -1/9, peak Rx sync delay 193, resyncs 0/0, no step interrupt scheduled
Hiccups don't seem to have caused this error, as there are none reported, so I think @dc42's concern about this seems less relevant. What sort of speeds do you usually run at that may have produced the hiccups before? Is it a large nozzle and high layer height, printing very fast?
=== Filament sensors ===
Interrupt 4 to 9us, poll 8 to 1184us
Driver 0: pos 13916.25, errs: frame 236 parity 0 ovrun 0 pol 0 ovdue 0
Again, this shows frame errors, which @dc42 attributes to interference. Could you check wire, crimps and connectors, and possibly refresh the wiring, between the filament sensor and 1LC?
I don't quite understand the Filament sensors section of the M122 report. You only have one filament sensor defined in config.g, and it is connected to the 1LC, correct? Do you have two extruder defined? Could you post the config.g for this machine?
Ian
@GeneRisi could you post the commands that work for you? Is this in config.g, or using the daemon.g workaround?
Ian
@omtek how is the PanelDue wired to the Duet, ribbon cable or 4-wire cable? Is it particularly long?
You also have the PanelDue serial comms speed set higher than we normally suggest. From your config:
M575 P1 S1 B115200
Try M575 P1 S1 B57600
I suggest checking the wiring, crimps and connectors for good connections, and make sure they are not running close to motor or heater wires, which could be sources of interference.
Ian
@Simone I've updated the calibration macro again, so this time it actually works correctly! @OwenD was kind enough to point out the error in my maths, which gave NaN results in some circumstances, and checked that it now gives correct answers. See https://docs.duet3d.com/en/User_manual/Tuning/Orthogonal_axis_compensation#calculate-the-skew-factor
Ian