@Notepad thanks. For these types of error it's the info in the error message that reported Code 7 that's important, but unfortunately you haven't provided that.
However, I believe I have identified and fixed the cause of Code 7 errors. We expect to release 3.6.0-rc.1 very soon.
@Tech_Sam03 have you tried slightly lower P and slightly higher D?
@Adrian52 thanks for your report. Code 7 step timing errors were the last critical error we needed to fix before 3.6.0-rc.1. Thanks to the feedback from @Aurimas I was able to identify the area of code and the bug that is the probable cause of these errors. The data you posted helps confirm that as the cause. We now hope to release rc.1 early next week.
@GeoffVR6 unfortunately you didn't provide the step timing error message, in particular the error code number in it; so there's nothing I can do. However, we believe that the code 3 errors were fixed in 3.6 beta 3, the code 2 errors were fixed in beta 4, and the code 7 errors are fixed in the forthcoming RC1. We haven't seen any other step timing error codes reported.
@konvalm FYI we have an outstanding ussie regarding this situation:
https://github.com/Duet3D/RepRapFirmware/issues/1082
@Superbrain8 thanks, we created this issue:
https://github.com/Duet3D/RepRapFirmware/issues/1094
It's scheduled to be fixed between 3.6.0-rc.1 and 3.6.0 stable.
@fcwilt are you running in standalone or SBC mode?
@dwuk said in Sovol SV08 Multiple Motion System Upgrade.:
Also when you just use the button's to move the U & V - they don't react instantly - so I am wondering where there is some sort of comms issue in 3.6.0b4 - as I don't notice this in 3.5.4
There are known synchronisation issues in 3.6beta releases including beta 4 when a main board is used in expansion mode. These have now been resolved.
@droftarts @luca-Massimiliano RRF does support additional delta "towers" but not to add extra degrees of freedom to the effector, only for e.g. keeping an extruder drive at the correct height so that a shorter Bowden tube can be used between it and the hot end.
@rbjam83 you can use a 1% resistor, it may just reduce the accuracy a little.
@fcwilt said in Question about scanning Z probe:
I'm getting this warning:
Warning: obsolete object model field sensors.probes^.diveHeight queried
Why does this happen?
Because you have a macro that refers to sensors.probes[N].diveHeight for some N. Use sensors.probes[N].diveHeights[0] instead, or diveHeights[1] if you want the dive height for the second and subsequent probes at the same point.
@fcwilt said in Question about scanning Z probe:
Since the probe is analog, and there is no "on/off" trigger height, what exactly does the G31 Z param do?
If you use the probe with a G30 command and you don't switch it to the experimental touch mode, then it behaves like a regular probe and G31 Z sets the trigger height as usual.
@SANJR what is diconnecting? DWC or something else?
@developeralgo222 for Y axis and white wires use !iox.in
@emi100 you need to reduce V, not increase it. Try V10. It's best to reduce V only in the homing file and then restore it to the default value later in the homing file, because maintaining stealthChop mode at high travel speeds is problematic.
@developeralgo222 if you really want to use 2 Y endstops even though you have just 1 Y motor, then my interpretation of the datasheet you linked to is that you need to use the white wire as the output connected to the iox_in pin (not the black wire), connect both sensors in parallel, and use the ! character at the start of the pin name.
You can activate the endstops manually (i.e. place a piece pf card in the slot) and use the Object Model Browser in DWC to check that activating either endstop changes the state of the endstop in the object mode to triggered.
@Leonard03 thanks; but please keep an eye on it. We've had a couple of Code 7 halt reports recently and I am homing on on the cause, but we could still do with some more reports. 3.6beta4 includes more debug info when these halts occur.
@Aurimas thanks, that's valuable feedback. If it happens again, please post the result of sending M122 B121 too.
@emi100 to avoid the "too fast" error you need to reduce the Tpwmthrs value as suggested by the error message. This parameter is controlled by the V parameter of the M569 command. If you send command M569 P# where # is the driver number then it will report the existing value and the speed that it corresponds to.
@oldschoolPiratename you can send M552 from Pronterface to check whether the network interface is enabled and what IP address it is using.
Have you extracted the DWC zip file from the 2.05.1/1.26.1 release into the /www folder of the SD card?
@thomasvanderwal we'd need to see your complete config.g and homedelta.g files to help. However, firmware 3.0 is very old now and it would be easier for us to help you if you upgrade to 3.5.4 or 3.6.0-beta.4.
