@crazyjane said in [Solved] Duet 2 wifi Java error:
M557 X15:12 Y15:195 S20 ; Define mesh grid
Thanks. Looks like you accidentally set the upper X limit below the lower X limit. I'm guessing that the firmware doesn't do appropriate error handling in this situation. I will test it.
@featheryjam2 said in Homing Issues with CoreXY and two z-axis drivers [SOLVED]:
I may have figured it out. Apparently it does not like when you do G28 X or G28 Y in the homez.g script.
That's correct. You can use M98 Phomex.g and M98 Phomey.g instead if you need to. However, as you are homing Z using a G30 command, you should have the Z endstop position set to "none" in the M574 command, and in that case the firmware will not let you home Z unless X and Y have already been homed.
Yes there was a change that prevented movement of axis before they were homed.
You'll have to either add a command to the config.g to allow those movements by default or you can edit your homing files to allow just those homing moves. Usually it's the z lift before homing x and y.
From the FAQ
I get this error message: "Error: G0/G1: insufficient axes homed" ¶
Recent firmware versions do not allow axes to be moved before they have been homed. The only movements allows are homing moves (G1 moves with S1 or H1 parameter) and individual motor moves (G1 moves with S2 or H2 parameter). So any Z movements that your homing files make before Z is homed should use the S2 parameter. Alternatively, add M564 H0 to config.g to allow axis movement before homing.
@dc42 That's right, I forgot to mention about the #0 /menu issue, thanks for noticing that too! Thanks also for increasing buffer size, this will give even more freedom in menu creation.
Regarding menu button text alignment when a width is specified, both centered and right aligned would make sense for me. Centered would be perfect for text buttons (ex: buttons in top menu bar), right align for array of numbers (ex: temperatures, movements)
To avoid the addition of a new option, right aligned could be triggered by a negative width while centered is the default.
If just one option can be reasonably implemented, centered would have my preference. Personal opinion only for sure, others may have different views
@dc42 I know specifically that the Viki2 uses the ST7565 and I suspect the MKS mini does as well from what I have seen online.
Adafruit has some documentation that may be helpful including a datasheet http://www.ladyada.net/learn/lcd/st7565.html
I have also noticed that Marlin specifically is using the u8glib to interface with these displays. From what I can see online for the MKS mini displays people are using the minipanel configuration and in the Marlin defines that configs as being the ST7565 display.