Zenbot/Gecko/LinuxCNC?

I would just ignore the updates as this won't be a permanent installation. It was working when the ISO was created so it still work without the intervening updates.

Following the instructions on the thread, its says "disable the 2.7 version" after booting the ISO. I see no way to do this with Synaptic Package Manager. I see a number of LinuxCNC packages, but "disabling" does not seem to be something I can do with them. And from my previous Linux experiences (admittedly months old at this point), that sounded like a foreign term.

jandyman wrote: Following the instructions on the thread, its says "disable the 2.7 version" after booting the ISO. I see no way to do this with Synaptic Package Manager. I see a number of LinuxCNC packages, but "disabling" does not seem to be something I can do with them. And from my previous Linux experiences (admittedly months old at this point), that sounded like a foreign term.

In the post on the previous page where I said "Lets Start again", I said

"On this version, the dependency issue will not be a problem and Gmoccapy will work fine."

So if you followed the instructions on that post and used the release iso on the Linux web site I linked to, gmocappy should work without you touching anything at all at this point. Have you tried?

Just did. Had some problems in a VM, so I tried the laptop. The good news is that the ISO booted properly, though it did seem to be complaining about not finding an ethernet card. Also I was able to bring up Gmoccapy without the gst module error. I was able to jog around and sucessfully zero the axes independently. The X/Y/Z display is sensible, unlike Axis.

The bad news is the the graphics had scaling issues on my screen (1920 x 1080). Buttons overlapped. Text was rendered in obviously the wrong size in places. The keyboard jog didn't work, but based on the error in the terminal window, that is probably a setting. I tried open up the settings dialog, but it wanted some access code.

So we're closer to a good Gmoccapy demo, frustratingly close in that we are still not there. Also I'm curious how would do auto touch off based on a probe in -Z, -X, +X, -Y, and +Y directions, with the touch off plate or bit diameter built into the process.

The gmocappy docs are here.
linuxcnc.org/docs/html/gui/gmoccapy.html

The default password for the settings page is 123 as shown on the instructions page above.
Sounds like full screen view is enabled by default. You can change this in settings. I have disabled the password.
Just reduce the size of the window for now. old school 4:3 monitors seem best but I do use a larger 16:9 monitor probably 1920 x 1080. I am certain any screen display issue has been fixed in the later versions as I've had no problems with scaling. Everything is too spread out for my taste though. A 4:3 monitor suits it better. I think that was the standard for it when it was released for the version you are running.

Note that being touch screen based, it can use a seperate onscreen keyboard as described in the introduction. These are seperate programs. I use onboard but that may be distro specific.

I don't use this for milling but I think the tool table would be how you set the tool diameter. Read up on macros in the instructions as I think you could create one that does your probing in gcode.

Hi,

I really appreciate all the help. It's late, so maybe I'll feel different in the morning. But at this point, it really seems like my friend and my instincts were exactly right. LinuxCNC is fantastic if you are building your own CNC machine and want to deliver it as a package with machine control software. Then all this up front time investment is worth it. Or if you are doing something really custom. Or if you just hate Windows so much that you can't tolerate the idea of using it. I hate Windows too, but I've already put a bit of time into this (more so because of my unfamiliarity), and at this point it logically makes sense to spend more money (about $150 more) and get UCCNC and an add-on screenset for $25 and tolerate Windows and be done with it.

I don't understand why if 2.8 existed in 2016 (based on the thread about updating to it), that there isn't an ISO for it that just works. And why the graphics in Gmoccapy are so screwy WRT to scaling, I just don't understand. Regardless of the settings. I wasn't running it full screen. Maybe they are fixed in 2.8 but I can't know by just finding and ISO and running it.

And I haven't even gotten to thinking about configuring actual HW. Which seems like will be easier on 2.8, based on your comments about a machine like mine that has two x motors.

In case you think my difficulties are because I'm not tech savvy, I'll point out that I've been an embedded systems designer and DSP guy for about 35 years now. And I've done paid programming projects on Linux, cross developing from both Windows and MacOS. I'm competent in many many programming languages, including extensive assembly coding and chip design in VHDL.

Maybe I'll feel differently in the morning. But right now my instincts are to cut my losses.

Actually, My bad. One of the developers in a separate post today pointed out that there is not yet a version 2.8. There is version 2.7 and the (sometimes) unstable development branch (master) which will become V 2.8 when it is released. As with any large software project, updates are released to the development branch. I will try and change my terminology. Understandably, there is no canned distribution of the development branch.

One of the features in the development branch is the separation of joints (motors numbered from 0- from the axes (XYZA etc). In the current 2.7 release, these are hard coded with a 1:1 relationship so that X = joint 0, Y = joint 1 etc. Its my understanding that this is a very significant change and has been many years in the making and it only made it to the development branch about 12 months ago having previously lived in an experimental development branch.

This change allows axes to use multiple joints and the homing features simplifies gantry setup. Basically, each side of the gantry moves towards the home switches and the first side there stops until the other catches up. Then they both finish their routine. Separate homing offsets in the ini file allow the final position to be adjusted to square the gantry without adjusting switch position. Thats why many of us use the development branch for gantry machines.

The developers tell us the standard is the axis GUI as everything is tested in it. Gmocappy is fairly new and is developed by one man and until recently was a separate install.

I suspect your test environment has had something to do with your problems. I think also I took you down the wrong path not realising you were running in a virtual machine. I do remember how simple life was when I first installed LinuxCNC as it just worked. But I've never attempted to install it on virtual devices or run from the USB. I've never seen Gmoccapy's screen become corrupt.

Ultimately, you need to be comfortable with the decision you make. At least you concluded not to use Mach3 so in my mind, that is the right decision.

jandyman wrote: at this point it logically makes sense to spend more money (about $150 more) and get UCCNC and an add-on screenset for $25 and tolerate Windows and be done with it.

If you think that UCCNC is what you should use then that is what you should use.

To be honest, it doesn't matter to any of us what you use. I can only imagine that we are trying to validate our own choice by extolling the virtues of LinuxCNC.

Nobody here makes any money from having more users (in fact the more users there are the more free support we all have to offer, so more users is a net cost). Just be aware that this is not necessarily true of people trying to persuade you to use UCCNC or Mach3. Of course users of those alternatives will _also_ be trying to persuade you to join them to help validate their own choice too.

Thanks for the most recent input guys. I think it logically concludes this attempt. I would really have liked it to work. Not primarily because of the money, but because I'd really like to be done with Windows and I do like open source when it works. I'm actually surprised about how close I got. Rodw pointed out that I got led down the wrong path and wasted some time and I think that is right. Actually, I only briefly tried stuff on a VM so that really isn't it. And my laptop is a pretty generic Toshiba a few years old with a standard size screen, so the graphics problems are mysterious.

In the end the showstopper is Axis. It is IMO a pretty bad UI. I know people use it successfully, but it is inferior to the standard screen in both Mach3 and UCCNC. And custom screens are available for both those systems because folks are unjustifiably not satisfied with those screens. I know that new UIs can be created in LinuxCNC, but I don't have the time. Actually, my CNC friend told me that Tormach has their own nice UI on top of LinuxCNC.

He's also the one that warned me that LinuxCNC would be a time sink. And BTW he has no financial interest in UCCNC whatsoever. He just had to get away from Mach3 just like me and ended up with UCCNC. He actually dove further into HAL and UI creation and so forth.

If Gmoccapy didn't have the problems it has, and if it had an interface for x/y/z auto touch off based on a probe, I would keep pursuing LinuxCNC further. But I think I've reached the end of the road. At least I have the satisfaction of having given it my best shot.

Thanks to everyone!! I have nothing but great hopes for the future of LinuxCNC.

Good luck with what ever you choose.

User ingerfaces are personal preference. I actually like Axis myself, but I usually use it with a custom GladeVCP added.
Here is an example of one I use on a few cnc routers in a factory production setting.