New firmware 1.21RC5 available
-
-
I did a super quick check of the various CNC Work/Machine coordinate changes, and all looks good. I will do a more thorough check as time permits.
However… CNCjs, in "Marlin" mode, doesn't understand how to decode the status report, and always shows machine coordinates in both the Machine and Work readouts. Not sure what the best answer is here...
-
Regarding the external drivers. I am still getting random layer shifting in both x and y. I have upgraded to 1.21 RC5 and no change. I am using M569 P5 S1 R1 T10:10:7:2 to create the step and direction signals.
I decided to remove the external drives to see if it was the mechanics of the system and not drive related. I installed traditional steppers on the X and Y axis using the built in drivers and re-ran the 3DBenchy. The results were pretty clear.
While I have a couple other minor issues with cooling to resolve, the print came out much better with no layer shifting. This has been the main problem I've been fighting for weeks. The mechanical side of the printer looks good, I just have something with these external drives that I cannot figure out.
They are 2HSS57 closed loop stepper drives and either something with the step generation or internal position/velocity monitoring loop in the drive is giving a problem. Nothing I did ever seemed to effect any change (inverting signals, changing from rising to falling edge, etc). The only thing that had a small impact was increasing the step signals from 1600 p/rev to 3200 on the drive itself and doubled the steps/mm. This resulted in reduced layer shifting, but it was still there.
Short of replacing all the external closed loop motors/drives with steppers and using the built in drives, I'm not sure really where to go from here.
-
I've installed RC5 and printed a couple of things without any issues. Update from RC4 was OK without requiring rename of the file.
Regards
-
I've also had success with installing RC5 over RC4 and doing a test print on a Kossel Mini delta.
-
Regarding the external drivers. I am still getting random layer shifting in both x and y. I have upgraded to 1.21 RC5 and no change. I am using M569 P5 S1 R1 T10:10:7:2 to create the step and direction signals.
I decided to remove the external drives to see if it was the mechanics of the system and not drive related. I installed traditional steppers on the X and Y axis using the built in drivers and re-ran the 3DBenchy. The results were pretty clear.
While I have a couple other minor issues with cooling to resolve, the print came out much better with no layer shifting. This has been the main problem I've been fighting for weeks. The mechanical side of the printer looks good, I just have something with these external drives that I cannot figure out.
They are 2HSS57 closed loop stepper drives and either something with the step generation or internal position/velocity monitoring loop in the drive is giving a problem. Nothing I did ever seemed to effect any change (inverting signals, changing from rising to falling edge, etc). The only thing that had a small impact was increasing the step signals from 1600 p/rev to 3200 on the drive itself and doubled the steps/mm. This resulted in reduced layer shifting, but it was still there.
Short of replacing all the external closed loop motors/drives with steppers and using the built in drives, I'm not sure really where to go from here.
What is the maximum step pulse rate that the drivers ever receive during printing? If the rate exceeds 25kHz then the firmware switches to double stepping. Ordinary stepper drivers don't notice this, but perhaps closed-loop ones might.
-
PS - @DougJones, please can you try the version at https://www.dropbox.com/s/iq9pzfaugyfei7x/Duet2CombinedFirmware-even.bin?dl=0. This is an experimental build that tries to maintain regular step pulse interval at high speeds, so it may play better with servo drivers. The maximum step rate is reduced by about one third.
-
PS - @DougJones, please can you try the version at https://www.dropbox.com/s/iq9pzfaugyfei7x/Duet2CombinedFirmware-even.bin?dl=0. This is an experimental build that tries to maintain regular step pulse interval at high speeds, so it may play better with servo drivers. The maximum step rate is reduced by about one third.
Any thoughts re: the inconsistent homing mentioned earlier? Using a mini ir-probe with tight tolerances specified, but it's often off quite a bit from the leveling measurements which are always consistent.
-
PS - @DougJones, please can you try the version at https://www.dropbox.com/s/iq9pzfaugyfei7x/Duet2CombinedFirmware-even.bin?dl=0. This is an experimental build that tries to maintain regular step pulse interval at high speeds, so it may play better with servo drivers. The maximum step rate is reduced by about one third.
I have the same layer shifting problem as DougJones. I didn't bring it up since I thought it's caused by my clamp type coupling slipping. It looks like the amplitude of the shifting is reverse proportional to step per mm, my layer shifting is much less noticeable when I increased to 1000 steps/mm. I'll also test the firmware when I get a chance.
-
It's slightly more complicated than normal, because the name of the main firmware binary for the Duet WiFi and Duet Ethernet has changed.
To update a Duet WiFi or Duet Ethernet from RC2 to RC5, rename Duet2CombinedFirmware.bin to either DuetWiFiFirmware.bin or DuetEthernetFirmware.bin according to what your existing firmware and DWC expect. Then upload that file through the Settings->General tab of DWC. …....
I renamed the file Duet2CombinedFirmware.bin to DuetWiFiFirmware.bin when I try to upload from setting page I get an error
-
Is there already a DuetWiFiFirmware.bin file in /sys? if so, try deleting it first.
-
Thanks that was the problem.
David did you get the livestream to work?
-
I've upgraded to 1.21 RC5 firmware and 1.21 RC4 webcontrol
When I press the home all button, i get the following error
G28
Error: G0/G1: Insufficient axes homedI've never gotten this before and the setup as not changed from v1.20. Any idea what's causing this?
Most likely this.
From the release note for RC 3 we have:
"New features:On Cartesian and CoreXY printers, normal movement commands are no longer permitted until the corresponding axes have been homed"
Then we have:
"On Cartesian and CoreXY printers, normal G0 and G1 moves are no longer allowed before the corresponding axes have been homed. In particular, if your homex.g, homey.g and homeall.g files raise Z a little at the start and lower it at the end, you will need to add the S2 parameter to those G1 Z moves. Otherwise the G1 Z move will be refused unless Z has already been homed and the homing macro will be terminated."….
I had this problem after update and like I saw here I added S2 in homex.g, homey,g and homeall.g I was the abe to home X and Y.
When i tried homeimg Z i gato the error Insufficient axes homed so -i added the S2 in homez.g it did home except that while before when it reached the correct height it would stay there while now it raise the head. I
this is my homez.y
G91 ; relative positioning
G1 Z5 F6000 S2 ; lift Z relative to current position
G90 ; absolute positioning
G1 X219 Y190 F6000 ; go to first probe point
G30 ; home Z by probing the bed
any idea as to why its adding a G1 Z12 (that the distance is raises the bed.)Thanks
-
G30 now raises the head to the dive height after probing.
-
In this RC5 i test:
M569 T5 (old config) work perfect,
M569 T2.5:2.5:5:0 (new config) wrong (is supposed than this must work well)
M569 T5:5:5:0 (new config) seem well -
@FBG:
In this RC5 i test:
M569 T5 (old config) work perfect,
M569 T2.5:2.5:5:0 (new config) wrong (is supposed than this must work well)
M569 T5:5:5:0 (new config) seem wellWhat is the specification of your stepper drivers?
-
https://duet3d.com/forum/thread.php?id=4831 -
That diagram doesn't specify the minimum interval between step pulses. What does the datasheet say the maximum step rate is?
-
I've found that when I have tool 0 at say 220 degrees in the Web Control > Tools section and I then use Control All > Turn everything off I cannot turn the hot end heater back on by say entering a new target temperature.
Is that expected behaviour?
-
It's not expected behaviour, at least not by me! I've found that sending a T0 command turns its heater on again.
