UV Axes on a Delta printer homing errors
-
I have added extra U&V axes to my delta machine, however I am getting unexpected behavior during setup in DWC. When I connect to the Duet Ethernet I get the standard message the XYZUV have not been homed. Running the G28 command homes the delta towers as always, but then a javascript error occurs and the system disconnects.
The confusing part to me is when I reconnect, the system loads into DWC with the message "XYZUV axes have not been homed" but the UV axes are no longer listed under the "additional axes" header. Sometimes they are listed, and sometimes they are not. I currently have simple homeu.g and homev.g files:
"homeu.g"
G92 U0If I understand correctly, this should set the U (or V) axis position as 0, so it thinks it is home. I do not yet have any end stops set up. I'm still trying to replicate the errors I am getting repeatably. Am I fundamentally misunderstanding something about homing?
G28 seems to behave differently in a delta printer than a cartesian printer, so homing may not be supported in this way?
-
I'm now realizing these axes might be expecting some kind of end stop data, or at least there should be something in config.g about their end stop setup (no endstops for now). That's what I'm going to try first.
-
If necessary you can use G92 commands in homedelta.g to pretend that the U and V axes have been homed.
I'll look into the JavaScript errors.
-
This is the console error I am seeing. This isn't something I know anything about, unfortunately.
My homedelta.g is:
; Homing file for RepRapFirmware on Mini Kossel
G91 ; use relative positioning
;******* Change F250 in the following line to F2500 when you are finished commissioning
;******* Change 320 in the following to a higher value if your Kossel has taller towers
G1 S1 X320 Y320 Z320 F1500 ; move all carriages up 320mm, stopping at the endstops
G1 S2 X-3 Y-3 Z-3 ; move all carriages down 3mm
G1 S1 X6 Y6 Z6 F250 ; move carriages slowly up 6mm, stopping at the endstops
G1 Z-5 F2000 ; down a few mm so that we can centre the head
G92 U0
G92 V0
G90 ; back to absolute positioning
G1 X0 Y0 F2000 ; centre the head and set a reasonable feed rate -
Currently, you need to put the G92 U0 and G92 V0 commands before the G1 Z-5 command. I'll change it in the next release so that you can do XYZ moves with just the main towers homed.
The Javascript error that refers to oem.json is normal and harmless, but I can't reproduce the others.
-
I have sorted out the errors associated with Git, but I am still getting the language.xml error (in addition to the oem.json eror) , which is a file in DWC core. Is this an error I should be worried about? I am currently using Chrome.
Still getting "Uncaught TypeError: Cannot read property 'length' of undefined interface.js:167 " error when I run G28, even after moving the G92 U0 and G92 V0 commands to before the G1 Z-5.
Interestingly enough though, when I reconnect the printer after the initial disconnect DWC correctly assumes all axes have homed successfully and no longer prompts me to home them before movement.
-
Are you using firmware 1.19.2 and DWC 1.19 ?
-
Ah ha. Here's another new development. If I run either G28 U or G28 V the whole delta tower homes and then the ""Uncaught TypeError" occurs and the system disconnects. It's my understanding that G28 U should not run the homedelta.g file, but it appears that it is.
Just saw your previous post. I'm checking that now.
-
Thanks for the report. Using 1.20alpha7 I don't get any DWC error when I try to home U and V, but it does home everything. The fix to home just U and/or V will be in the 1.20beta1 release, due out tomorrow.
-
I was not on 1.19 as it turns out. And DWC was outdated as well. I have been attempting to update, but now I can no longer connect through the ethernet port. It was so long ago that I set this up the first time. I can't remember how to determine my printer's IP address.
edit: I am connected over USB and running M552 returns "Network is enabled, configured IP address: 0.0.0.0, actual IP address: 0.0.0.0" I have status lights blinking, so that's a good sign at least.
-
If the actual IP address is showing as all zeros, this means that your router has not assigned the Duet an IP address.
-
I must being doing something wrong in the 1.19 upgrade. It's a Duet Ethernet, so it must be slightly different than these instructions https://duet3d.com/wiki/Upgrading_to_DuetWiFiFirmware_1.19. I'm starting from an SD card with a new www folder containing the unzipped contents of DWC and the sys folder containing DuetEthernetFirmware.bin, DuetWebControl.bin (Not sure if this needs to be here), iap4e.bin, iap.bin, and various .g files from before. The rest of the folders are unmodified. Do I need DuetWifiFirmware.bin or the server firmware?
-
I got it! I went through all the files and just made sure they were updated again, and double checked my network settings were correct:
M552 P0.0.0.0 ; Use DHCP = 0
M554 P0.0.0.0 ; Gateway
M553 P255.255.255.0 ; NetmaskHere's where things were a bit strange though. I had the MAC set in config.g to be:
M540: P0xBE:0xEF:0xDE:0xAD:0xFE:0xED ; MAC Address
which I believe was the default. When I used M540 over the USB connection it returned a different MAC addrss than the one I specified. Not sure where that came from, but I changed my MAC to match the one returned by M540, and now DHCP correctly assigns an IP address.Interesting problem not at all related to the original topic of this thread, but it might be useful to someone. Now back to the original topic tomorrow. I think these upgrades may have fixed it though. I haven't had any disconnects yet.
-
I'm glad you got it working. On the Duet Ethernet you don't normally need to specify a MAC address in config.g. it only needs to be specified if you have multiple Duet 06 or 085 boards on the same network.
-
Thanks for your help! I'm sure I'll be back with more questions later.
-
The 1.20beta version that I released a couple of days ago should fix your U and V homing issues.
