Topics created by JayT

@JayT :

Can you confirm that you obtained those prints using firmware 3.6.0-rc.3 ? Does the centre frequency of the ringing reported by the accelerometer and closed loop plugin agree with what you measure? Measure the period of ringing in mm on the print (ignoring the ringing closest to the edge) and divide that into your speed of 60mm/sec to get the ringing frequency. Can you post a print taken with IS disabled so that we can see what different IS is making? There is a checkbox in the IS plugin called "measure over the whole move" or something like that. I believe you have that checked. What does the plot produced by the IS plugin look like oi you un-check that box and take a measurement?

@droftarts @dc42 :

I further checked the setup & realize that the PT1000 sensor is 30mm in length with 4mm diameter. But the Biqu extruder slot for hotend & sensor is of 15mm.
This means half the sensor is outside sensor slot & not in contact with hotend.

Shouldn't this affect the PID learning & heater behaviour?

@droftarts :
I see this is happening only with 1/2 versions of cura generated Gcode. If I use latest Cura version gcode, I don't see this problem much. However, I will see if stopping the log , helps anyway.
Also, I do see that this problem does not appear in previous versions of RRF. May be something is changed w.r.t certain gcode interpretation.

@Phaedrux : Please mark this as solved.

@o_lampe :

Right. In that case you can resolve this thread.
Thanks.

@JayT
I first had plain bearings that were changed to linear ball bearings. But install branded bearings here. I once had cheap bearings for Z that worked very badly. You notice it when you move the separated bearing by hand. They have an uneven, choppy running. Especially when changing direction.
Which cannot be checked when installed:
Put the bearing on the rod and tilt it until it starts running on its own.
Then tilt the rod to the other direction.
On the subject of tilting or distortion of the axle:
Push the axis to one end and check whether the axis comes to rest on both sides at the same time.
Push alternately on one side or the other.

@Phaedrux :
I will probe and check on diff XYpoints.

Can you tell me how much variation in the min & max reading after probing is acceptable to avoid creating gaps or tightening effect, if axes are all true & there isn't any tilt or skew?

IF i currently limit the amount of correction in M671 - S parameter, then what it should be to avoid creating gaps/tightening effect?

@JayT changing the M109 command to M104 followed by M116 is a workaround for the bug. The fix to the RRF source code removes the need for the workaround.

@jayt said in DUET3 any pin to detect poweroff and aid Zbraking?:

@engikeneer @Phaedrux : Both of yours answers are contradictory
Can you check if you have these settings in place?

I misread your question. @engikeneer is correct.

@rjenkinsgb : Thank you. Fixing a diode as suggested worked well.

This thread can be marked as solved!

@phaedrux :
I have rooted the issue and its not a problem with the firmware version 3.4beta3. X motor stopped and seemed like some over current issue . I have replaced some cables and will confirm if that is indeed the root cause.

@owend :
Thank you for the reference. looks like a good base for me.

@Phaedrux : thanks, I missed the global var example earlier. Now I see how its read.
You can close the thread as solved, As I understand how to read object model variables and where to look for the available variables.

@jayt Not entirely:

Correct Use echo >/sys/password.g "M551 P""new password""" instead. In strings, double-quotes " must be expressed as "" Only if you're logged in If you use proper escaping, yes:

PasswdRESET.g:

M551 P{param.S} echo >/sys/password.g "M551 P""" ^ param.S ^ """"

Then invoke it via M98 P"PasswdRESET.g" S"myNewPassword".

@jayt Please keep DWC and RRF in Sync.

and update to the latest beta!

@JayT, check function "CreateScreensaverPopup" in src/UI/UserInterface.cpp. Good luck

@dc42 ok great.

Thanks. you can close the thread as resolved.

@gloomyandy : yes that was the error in 2 lines. 2 were ok.
Thank you 🙂

@jay_s_uk : ok got it. you can mark this thread as Solved.
Thank you again!

If the galvo requires an analog input, once option would be to use a SAMMYC21 to receive CAN movement commands, and have the step ISR just update a motor position variable instead of generating steps. Then a separate RTOS task could read the step counts and generate commands to send to a 16-bit SPI DAC to drive the galvo input.

@JayT : Problem resolved, we just swapped the internal cables (to make sure it's 1-1 connection). i.e. CANH to CANH. The LED blinked right on power up in sync with MB6HC. This thread can be closed. thanks.

@dc42 :

Thank you for the support so far.
we were able to run impulse motors with 1XD boards & run upto 100mm/s travel speed. No issues with the print after upgrade to the firmware as suggested. As observed: the earlier nema 23 motors were working better with external drivers than with the on-board drivers. I believe its because of the smart drivers that compensate for the back emf.(hope so).

This thread can be closed as Resolved.