Newbie migrating a gantry from Mach3 to LinuxCNC

you did not load the coustom postgui hal file
or the other way you did not load the panel to the coustompostgui

its for shure the first as hal trys to find your pyvcp panel but its not present
in DISPLAY section
PYVCP = yourpanel.xml

rodw wrote:

This is about where I run out of time but your error is mentioned here
www.forum.linuxcnc.org/gmoccapy/32186-mo...e-side-panel-problem
this is a bit different but I suspect its a load order thing.

The details are a little different and it looks like there might've been some other issues complicating the picture, but, yeah, based on what I could follow it looks like the same thing's probably happening.

I would post in the gmocappy forum and I think Norbert the gmoccappy author will be along to help.

Will do. I'll see if I can double-check my repro & toss a post over there a bit later.


-Bats

pl7i92 wrote:

you did not load the coustom postgui hal file
or the other way you did not load the panel to the coustompostgui

That's the thing - and the only reason I thought the crash was worth reporting. The only thing I did was to take the stock by_interface->parport->gecko->Gecko_G540B4 config and switch the screen from axis to gmoccapy using stepconf. Switch it back to axis, and it works fine. Do the same thing using the Gecko_G540B3 config (I haven't looked at the files in depth, but it looks like it's supposed to be the same thing without the *B4's extra A axis), and that works fine, too. That made it look to me like there was either a problem with one of the stock configs, or with the way stepconf was handling them.

Well, either that or there was a "No! Stop! Wait! Don't do that, you idiot!" warning that I ignored somewhere along the way, assuming it must be talking about some other idiot.

(and again, this really doesn't apply to my actual setup - it was just something I stumbled across early on while fiddling with various configs)

-Bats

andypugh wrote:

Fixing stepconf but leaving it still stuck in Python2 would feel a bit wrong too.

Oooo... yeah. That would definitely be a little tacky.

This looks like it is part of a file called by your postgui call list.hal. (line 8 of a file called pyvcp_options.hal )
I don't see anything in the [DISPLAY} section of the INI that is loading a pyvcp panel, so it makes sense that this pin does not exist.

I think I may have been posting when I should've been sleeping (again), since I guess I didn't do a very good job of making it clear. The error report is from switching the stock Gecko_G540B4 config from axis to gmoccapy, not from the ini/hal files I posted (which were modified a la joel0407 from Gecko_G540B3). My ini/hal files run without a crash, but are only sending signals to three of the four motors.

As things stand your machine will (probably) use immediate homing at the current position, but until it is homed you won't be able to jog both sides of the gantry simultaneously.

Ok, then it looks like my problem (yet again) comes purely from getting ahead of myself. I'd put off dealing with the home/limit switches because it was getting late and I didn't have the energy to dive into the (embarrassingly) poorly labeled wiring to sort out which pins carried which switches, assuming (wrongly, it seems) that I could test to make sure all the motors were behaving before moving on to homing.

So it looks like I know what I need to do next - thanks for saving me from wasting any more time (oops) on premature troubleshooting.


-Bats

Have I used the word "oops" lately?

With the machine out of commission these past couple months, I hadn't given it much thought, but it turns out the job I was in the middle of when the old motherboard died was...

(wait for it)

Cutting mounts for home/limit switches.

This will make things... interesting. I'm hoping I can hack a couple of the not-quite-right prototypes into temporary service - otherwise I may just try to set up manual homing until I can finish the job.

Guess I could've gone with 2.7 after all.

Oops,
-Bats

In the interest of expediency and/or impatience, I went ahead and temporarily set up for manual homing (HOME_*_VEL=0, HOME_USE_INDEX=NO, HOME_SEQUENCE=0), which seems to be working... not that I've been brave enough to jog any axis more than ~.01" before I sort out how to get everything calibrated (and... err... do something about the pile of random PC guts the machine is currently buried under).

It didn't seem to be related to my prior issue, but I also discovered that I'd mixed up my pins, and the "gantry" was composed of one X motor and one Y motor. Oops. Still, no damage done. Unlike the time I learned that Mach3 treated slaved axis config differently in some modes than others, as it demonstrated by "homing" the two ends of the gantry in opposite directions as fast as the machine would let it.

Still, I think I've got the most intimidating bits or setup out of the way (and think I understand how homing should work once the the switches are re-mounted)... At least until I try to get my Playstation gamepad "pendant" working. Or decide I need a custom UI. Or a spindle encoder. Or lasers.

Thanks again, everyone - I appreciate all the help (and/or patience) in getting to this point.


-Bats