Bug? Crash when running stock Gecko configs with gmoccapy

Just a quick (quickish?) bug report. This isn't anything I need resolved - it's just something I stumbled across by accident that Rodw mentioned might be of interest over here (although the actual bug turned out to be far narrower than it initially looked, and I'm not sure how much is gmoccapy's problem).

I was playing with some of the stock configs on 2.9 (2.9.0-pre0.770.0.ga48d613fb, to be painfully specific) and discovered that - as the title may have hinted - taking the stock by_interface->parport->gecko->Gecko_540B4 (or *B3) config into stepconf and switching it from axis to gmoccapy while "Include custom PyVCP GUI panel", "Spindle speed display", and "Include connections to HAL" are selected (with no other changes) will crash with the following error (full report attached) when linuxcnc tries to start up:

Going back into stepconf and toggling the GUI from gmoccapy back to axis will again allow it to start as expected.

I tried to check whether it would happen with other stock configs, but found that - at least under by_interface->parport - most of the others either wouldn't run at all (for various reasons), or wouldn't produce .stepconf files to modify. So I don't know whether the problem is systemic, a fluke of the Gecko setup, symptomatic of something broken in this particular build, or just because I was clicking a combination of buttons that were never meant to be combined in the first place.

If there's anything else I be of help on, just ask - but, again, this isn't anything I actually have any need for.

-Bats

hi
open up your
custom_postgui.hal
in the mashine Folder with a editor
there is a line
net xxxxxxxxxxxxxxxxxxxx pyvcp.spindle-speed
make it
# net xxxxxxxxxxxxxxxxxxxx pyvcp.spindle-speed

in the INI
[DISPLAY]
look if there is
PYVCP =
DELETE IT
and you are fine
GMOCCAPY DOES NOT ALLOW EXTERNAL SIDE Panels

GMOCCAPY DOES NOT ALLOW EXTERNAL SIDE Panels

That is not exactly correct!

gmoccapy does allow side panels as well as user pannels etc, but not pyVCP panel! please use gladeVCP panel for your needs.
The mentioned pyVCP panel is not needed with gmoccaps, as the GUI brings the requiered elements from stock.

Norbert

Some of the problem here (IIRC) is stepconf will check to see if there is a XML file already - if there is it doesn't overwrite it - I thought it would ask you but maybe that's pncconf.
The reason is if someone adds custom HAL code then reruns stepconf, we don't want them to lose their code.
We could add a hash code check to see if they emitted it, I suppose....

newbynobi wrote: gmoccapy does allow side panels as well as user pannels etc, but not pyVCP panel! please use gladeVCP panel for your needs.
The mentioned pyVCP panel is not needed with gmoccaps, as the GUI brings the requiered elements from stock.

So that would fall solidly under "buttons nature never intended to be clicked together".

Sounds like something that probably should've been blocked by stepconf in the first place. But I guess some bugs never need to be fixed because there's just no one stupid enough to ever actually trigger them... (until now! *dramatic chord*)


-Bats
Because better foolproofing requires a better fool!

Naaw - it's just configuration programs don;t get a lot of testing until users use them.
Developers tend not to use the programs.

Chris

Bats wrote: -Bats
Because better foolproofing requires a better fool!

LOL
I do remember another one i read somewhere:
Nothing is fool proof to a talented fool!

cmorley wrote: Some of the problem here (IIRC) is stepconf will check to see if there is a XML file already - if there is it doesn't overwrite it - I thought it would ask you but maybe that's pncconf.

It looks like it does ask, at least under some circumstances (unless I'm looking at a different operation). Selecting "Blank program" when modifying a config with the spindle speed panel already present from a prior run gives an "Ok to replace existing custom pyvcp panel file?" popup (which then renames it to custompanel_backup.xml).

The reason is if someone adds custom HAL code then reruns stepconf, we don't want them to lose their code.

...which would probably increase the number of obscenities howled at a cold and uncaring sky by a non-trivial amount - although the various "If you make changes to this file, they will be overwritten when you run stepconf again" warnings have left me afraid to run it on anything I've manually modified anyhow.

My initial thinking (which is, of course, where many of my best mistakes get their start) was that checking "Use Gmoccapy Screen" could just disable the "Include custom PyVCP Gui panel" checkbox & all its suboptions - which would solve my accidental use case and keep people from breaking a stock config by adding new panels known to be incompatible, but wouldn't do anything for the (presumably significant?) number of people working from less stock-y configs.

Unfortunately I don't think I understand enough of any of the nuts & bolts to suggest a more generalized solution.


-Bats
(ok, to be fair, I may not understand enough of the basics either)