@IndeX4D For "Timeout while waiting for transfer ready pin" errors, see https://docs.duet3d.com/en/User_manual/Machine_configuration/SBC_setup#troubleshooting

This error, reported in the DWC console, is usually caused by:

Other wires running too close to the ribbon cable, creating interference. Heater and motor wires can be particularly noisy, route them as far away as possible. Ribbon cable too long, damaged or poorly connected. Check installation of ribbon cable. Ribbon cable should ideally be not longer than 150mm. Signal reflections have been reported by one user. This may have been caused by a ribbon cable that was too long, or damaged.

Ian

@T3P3Tony Your right, I forgot my bias! I tend to lean towards customer interactions when replacing the wires instead of hobbyist/makers. Soldering XT30s is certainly harder than crimping.
If the tiny JST ZHs are replaced with something bigger then it would already be a huge improvement. Crimping such small crimps is both a pain.

How easy would it be to have both a XT30(2+2) header on the distribution board as well as JSTs? Something similar to the 6HC where it has the RJ11 port and the AUX_CAN JST right next to it? It might give a bit of flexibility to which approach a user wants to use.

@chrishamm I solved the problem (so close the topic as solved please). I dont know the causes but this is how it is working now:

.- In config.txt I commented the line

#disable_fw_kms_setup=1

By doing this and rebooting, I can see the raspberry logo at boot but then again all goes white and stays there

So again in config.txt I made the change:
dtoverlay=vc4-kms-v3d to dtoverlay=vc4-fkms-v3d

And these 2 changes solved the problem. Everything in "normal " now, The camera is not working either but it is detected.

On the other printer I checked, and disable_fw_kms_setup=1 is not commented... Documentation says this uses kernel defaults. So my guess is since the difference between both raspi images is the date and I can see a difference on kernel vlaues, there is something internal that makes all this trouble to me.

Either way, it is solved. Thanks for the help

@Rob-Holierhoek What slicer are you using? Slicers have a bad habit of changing the default speed and acceleration limits, and often send values in mm/s while RRF uses mm/min. Also there's usually a switch to set the Gcode flavour to 'RepRapFirmware'. See https://docs.duet3d.com/en/How_to_guides/Calibration#h-7-suggested-slicer-settings

If you still have issues, post a simple gcode file. Also please post your config.g and the response to M122, so we can see which firmware version you are using.

@Rob-Holierhoek said in Duet2 wifi on ender 5:

my question is could it be the update delay for settings is set to 500ms and the update for delay for cache changes 1000ms

I think you're seeing that in the DWC > Settings > General. No, don't change them, they won't speed up the printer, they're the settings for how DWC communicates with the Duet. Not relevant to your issue.

Ian

@deepakvarma Please supply more information, it is impossible to help with this otherwise. See https://forum.duet3d.com/topic/5909/guide-for-posting-requests-for-help

RRF version Which Duet board(s) Post config.g Post M122 output What hardware is causing the problem? (In your case, what probe type? eg BLTouch) Post homez.g as it is related to Z homing. If you pressed 'HOME ALL', also post homeall.g

Ian

@bugpwr Thanks, I've asked @dc42 to have a look, see if he can see what's going on, as I'm not sure how to read the 'move' output.

Ian

@o_lampe My requirement is to utilize the unused axes during printing, with their movement controlled via daemon.g and triggered by a flag. My understanding of multiple motion systems is that the unused axes should be accessible to the other motion system. However, the error I am encountering indicates that the unused axes are still being treated as part of the motion system responsible for the print job.

@Electriceye said in Motor problems on RatRig V-Core 3:

Warning: Driver 0.2 warning: phase B may be disconnected

So...that's not good, looks like 2 drivers may be toast. What a way to start a build.

Before you worry about the drivers being blown, provide photos of the stepper connections on the board and motor side, and of the drivers. The error above may very well be about a wiring issue (either phases not being AA BB, or bad connection).

@HeidiH

Those temperatures need to be set to 0 to read 0.. I they are -273.1 that means they are on the "default" settings.

I see in your config.g there are the commands for setting them:

M568 P1 R0 S0 A0; Set initial tool 1 active and standby temperatures to 0C M568 P2 R0 S0 A0 ; Set initial tool 2 active and standby temperatures to 0C M568 P3 R0 S0 A0 ; Set initial tool 3 active and standby temperatures to 0C

So that should be setting them

Please can you run M98 P"0:/sys/config.g" and see if you get any errors. It could be those commands are not being run due to an error earlier in your config.g

If that's not the issue then try sending them manually from the console to see what happens. I tested that they were valid and worked in my config.g in 3.6beta3 but you are running 3.5.3/

@achrn @SPAX

Please try 3.6Beta3 to confirm if the issues is resolved or not

https://forum.duet3d.com/topic/37289/software-version-3-6-0-beta-3-now-available

@machinemark note that M950 configures an input/output. Querying with M950 shows the configuration, not the state of that input/output. That’s why it doesn’t change.

EDIT: apparently the above isn’t the case, and M950 does show the state of the pin. Make sure you’re grounding/applying 3.3V to the correct pin.

If you need the input to make something happen, eg run a macro, set up triggers on the input. See M581 and M582, and https://docs.duet3d.com/en/User_manual/Tuning/Triggers for examples.
EDIT: ignore this too, checking the OM is probably more straightforward.

Ian

@Cognirit thanks for the kind words!

@droftarts Thanks, is good idea, I will try some test as you say.

Best Regards