hazzy - Another touchscreen GUI

Kurt, thanks, I had a play recently with axis. I think that master has been fixed since I reported my homing issue and I no longer need custom code in gmoccapy.py. now that Norbert has resolved the bug I reported. Assuming its resolved, from a usability perspective, you should not offer the user 2 options that do the exact same thing which is what you are doing now. Maybe you should say "Joint 1,3 (Y)" for Joint 1, suppress joint3 display and internally only home 1 joint.

I've got no history with CNC so maybe I have different views. I've created a lot of user interfaces though. If the user has to home all axes before running a program, why let him home each individually? I can only see that might be necessary when setting up the machine but I managed to do this with just the home all button.

Hi
I download the new hazzy code and tested, it run well.
Regarding the Rodw comments, I agree that until the machine is properly set up, there is no reason to have the option for drive joints individually.

thanks

Rod, you make a good point there. I guess the only reason to have individual homing buttons would be if the homing sequence is not defined in the INI file, or, maybe, for something like a SCARA robot. Axis and Gmoccapy have individual homing buttons, but come to think of it, I only use them but once in a blue moon.

If there are going to be joint pos DROs, I would think it should display all the joint present in the machine. But most users probably never will care about the joint positions, so maybe I should make the joint display optional (or just play hidden) if the machine has trivial kinematics.

Pedro, I am glad to hear you got hazzy to run! There are a lot of things that are not functional yet (especial on the file chooser page), but hopefully you can get a feel for what I am trying to do.

Thanks for the input all!
Kurt

Phill, I guess you type faster then I do
I think what you describe is an excellent solution as it would work in all cases, and should make everybody happy. It should also be quite easy to implement. Thank you!

Kurt

kcj wrote:

Phill, I guess you type faster then I do
I think what you describe is an excellent solution as it would work in all cases, and should make everybody happy. It should also be quite easy to implement. Thank you!

Kurt

I agree too. For the record, I never even knew world/joint mode existed until Norbert started asking me questions in relation to the bugs I came up against!

Lets face it, its only something of interest to integrators like us on the forum, the average user won't even want to know about joints!

rodw wrote:

kcj wrote:

Phill, I guess you type faster then I do
I think what you describe is an excellent solution as it would work in all cases, and should make everybody happy. It should also be quite easy to implement. Thank you!

Kurt

I agree too. For the record, I never even knew world/joint mode existed until Norbert started asking me questions in relation to the bugs I came up against!

Lets face it, its only something of interest to integrators like us on the forum, the average user won't even want to know about joints!

Unless they are using ja with a gantry machine. Thats the first thing that pops up when starting linuxcnc

Hallo,

rodw is right, I solved the gmoccapy gantry homing issue. I also need a correct INI config, but I do check within getiniinfo the kins and some more stuff, to display the DRO or JOINTS Pos.

Take care, that till now the jogging problem is not solved. The user of a gantry is still able to jog one joint without homing the machine, I am working on that!

Norbert

newbynobi wrote:

Hallo,

rodw is right, I solved the gmoccapy gantry homing issue. I also need a correct INI config, but I do check within getiniinfo the kins and some more stuff, to display the DRO or JOINTS Pos.

Take care, that till now the jogging problem is not solved. The user of a gantry is still able to jog one joint without homing the machine, I am working on that!

Norbert

Norbert, going off topic for a moment, I'm not totally convinced Gmoccapy has solved everything in relation to the changes in Master. I've had a number of errors in relation to limit switch and following errors (now fixed) that are reported on the command line but do not raise an error dialog window. I think errors like this were previously reported by Axis within the GUI. I'm not sure if its a GUI issue or a LCNC issue. One error I traced back to deep within the LCNC code and it appeared to be making an incorrect assumption as to what was causing the error due to JA changes. "Axis is misconfigured" when it wasn't.