(SOLVED) BUG REPORT: Gmocappy Homing buttons in joint mode in Master

@rodw,

I just pushed gmoccapy 2.3.0, with has much better support for ganty configs. Would you please test with real hardware?

Norbert

I will give it a go this week. I still have not got a complete table but hope to within a week. I'm now running Dewey Garretts External offset branch to try his PID based THC module.

Norbert,

I have tested this on my hardware with steppers on all axes. There is one issue with homing I noticed.
With a joint axis machine correctly configured with the identical negative value for HOMING_SEQUENCE (I used -1) everything works OK. Home all works and individual axes can be homed so I will give you a qualified pass.

With the axes configured incorrectly with a positive value for HOMING_SEQUENCE (I used 1), the MDI and run gcode buttons remain disabled if all axes are homed individually. Once Home All is pressed, the buttons are enabled. It appears this is recognised by the Axis GUI which prints an error message about misconfigured axes in the terminal window.

And yes, I had correcting the HOMING_SEQUENCE was on my to do list. I just did it sooner.....

Norbert,

What does this error mean?
I get this when jogging without homing the machine which is what the comments in your source code say I should expect.

Often then I hit a limit switch because the machine does not know where it is I guess.

Should jogging be disabled until the machine is homed?

Hallo rodw,

first thanks for testing!

With the axes configured incorrectly with a positive value for HOMING_SEQUENCE (I used 1), the MDI and run gcode buttons remain disabled if all axes are homed individually. Once Home All is pressed, the buttons are enabled. It appears this is recognised by the Axis GUI which prints an error message about misconfigured axes in the terminal window.

This behavior is correct!, If you use as homing sequence a positive value, it just tells the homing order for home_all, so if you home i.e. Y in a XYYZ config, only Y0 will be homed, not Y1, so one joint is not homed, that is why you are not allowed to enter MDI or Auto mode. It will be very difficult to find from the GUI side all possible config errors, so I must expect a correct config in first place.

I will check, if I can check for double letters and the correct homing sequence, being negative, and otherwise disable the corresponding homing button. But I need to find time first I want to go skiing

Norbert

Norbert,

What does this error mean?

wrong motion mode, change to the correct one


I get this when jogging without homing the machine which is what the comments in your source code say I should expect.

Often then I hit a limit switch because the machine does not know where it is I guess.

Should jogging be disabled until the machine is homed?

LinuxCNC support two motion modes for jogging, one is jogging a Joint, the other is jogging an axis. You are trying to jog a joint, being a pair of two joints. If not homed, it is not possible to jog an axis.

I consider this as a bug! I must see, if I can handle that one from GUI side, otherwise, I will disable the jogging button for the double axis-letters. Like above, I need to find time

Norbert

The error is displayed if any axis is jogged before it is home, not just the joint axis.
The error is not informative, maybe "Wrong motion mode (jogging before homing), home all axes and try again."

Norbert, reporting this here to avoid hijacking another thread.

Sorry, but my LInux machine hung and its getting late. To test this,
If I home my machine and trigger a limit switch, the error message is printed in the terminal window, not in a gui window. I am sure previously it printed in an error window.

It also printed after that what appeared to be a latency error quoting a few timing numbers (but I am not getting any while operating). THis could have been caused by the printf statement as I know that is a very slow operation. I don't believe I've seen the latency date printed before.


Then some time aftewards, this message appeared.


Note that I'm running dewey's external offset branch but I am sure it was rebased to master after your last round of updates. I'm also pretty sure this was happening in master last time I tried it.

Have you modified the screen, it looks very strange.
The error is caused by gremlin.
How can i eproduce that?

Norbert

Norbert, I think the screen became corrupted after the gremlin error.. My screen is based on the plasma sim