Welcome! Log In Create A New Profile

Advanced

DM542T Unusual Behaviour - Updated

Posted by Chips 
DM542T Unusual Behaviour - Updated
August 11, 2020 08:49AM
Hi,
I have built my own 3d machine
Due to resonance at certain speeds i wanted to change from TB6600 drivers to DM542T drivers for the X/Y axes.
With the TB6600 drivers everything was working as expected (except for resonance at the specific speeds).
With the DM542T on the X axis (only have one DM542T driver at the moment), it works exactly as expected when the micro stepping is set to 800 (4).
When i say exactly as expected, i mean that the axis moves normally, and if i move, from the front panel, after homing, i can move it away from hp, back and forth, and when i return it to the hp, it will exactly (0.1mm) trigger the hp sensor. So home = hp sensor on, move 0.1mm = hp sensor off, whizz it around at various front panel dictated movements and return to hp which is activated when i move the last step of 0.1mm to 0 position.
But, when i change the micro stepping to 400 (2), it will work exactly as expected only if i do 1 click at a time, of the front panel encoder, to move it 1x 10mm, 1x 1mm, or 1 x 0.1mm. If i rotate the encoder so that it will move say 6 x 1mm in one movement, then it will miss steps. This problem happens both ways (ie "fast" click movements left and right). Again with single rotary clicks it is good.
I have tried reducing the speed it moves from the front panel, reducing the accerleration, have tried min and max motor currents on the DM542T - all without success.
I am thinking that because it works reliably at 800 (micro step 4) it cannot be anything except a weird DM542T problem ???
This problem also happens from Pronterface, if i do not wait for the move to be completed after each click of the gui.
The Marlin bugifx 2.0 settings are for a TB6600, but the spec sheet says that it is 2.5uS min pulse for the DM542T, and it is working at micro step 4 ???
What have i missed ?

UPDATE : When i said "miss steps" this was wrong, what actually happens is that with multiple rotary clicks (turn the knob quickly so that it does the all of the clicks as one single motion), it will move more than that requested !!
I have tested and measured :

for 10mm per click:
"fast" clicks to position 100mm moves the axis to 100 + 0.9mm
"fast" clicks to position 220mm moves the axis to 220 + 2.1mm

for 1mm per click:
"fast" clicks to position 15mm moves the axis to 15 + 1.4mm
"fast" clicks to position 17mm moves the axis to 17 + 1.6mm
"fast" clicks to position 25mm moves the axis to 25 + 2.4mm

for 0.1mm per click:
"fast" clicks to position 2mm moves the axis to 2 + 1.9mm
"fast" clicks to position 1.6mm moves the axis to 1.6 + 1.5mm

These measurement values are very repeatable every time.

There does seem to be a pattern with the excess movement amount - [(no. of clicks) - 1] x 0.1 mm.

Hence when i do a fast rotary click movement from the front panel it goes further than requested, and if i then return it to position 0, one click at a time, it will reach 0 without activating the hp sensor.

It will do the same from Pronterface, by clicking the gui button to move several times in quick succession (same as rotary encoder). Do one click at a time gives correct movement.

It appears that G code movements from Pronterface work ok.

This problem only happens with DM542T - TB6600 is ok.

It is not an axis problem, as identicle results are achieved on a separate axis.

I have tried 2 separate DM542T drivers both are the same.

DM542T set to 800 (microstep 4) works perfectly.

DM542T set to 400 (microstep 2) exhibits the problem.

So, i conclude it is a DM542T weird problem with microstep 2 (have not tested any other micro step settings on the DM542T other than 2 and 4), only with "fast" clicks of the front panel rotary encoder (or fast presses of the Printerface button), such that the axis goes to the selected position in one movement.

Does anyone with more intimate knowledge of Marlin bugfix 2.x have any ideas as to why this behaviour might happen - what is the difference between fast rotary clicks and single click motions - could it be a s/w bug ?? The extra movement is linked to how many "fast" clicks of the rotary encoder are done.

I would like to use microstep 2, but would also like the axis to operate in an expected way from the front panel and Pronterface.

Edited 2 time(s). Last edit at 08/12/2020 05:33AM by Chips.
Sorry, only registered users may post in this forum.

Click here to login