If you launch LinuxCNC from the command line, you will get a list as the hardware is discovered
which should help with debugging

The timer issue is possibly  that the installed firmware lacks a DPLL timer
(and pncconf always puts DPLL timer boilerplate in the hal file)
 You can work around this by deleting (or commenting out)  any lines that
mention "dpll" in the hal file
 

I know the macros, and I think they are useful. But my goal is something more holistic, closer to the way I’m used to working.I want to create a program, work through it step by step, and be able to go back at any time to change something or reuse individual steps. That’s how I’ve always worked on industrial machines. At work, I actually always wanted to use Heidenhain controls, but in reality I mostly ended up with Siemens. Both are good systems, but they offer a structured, process-oriented way of programming that goes beyond single, isolated macros.As far as I know, LinuxCNC doesn’t really offer something like this out of the box. That’s why I started writing it myself, and I will continue developing it until it reaches a level where I’m satisfied with the result – no matter how long that takes.The existing macros are good, but they usually solve only one small task at a time. For me, that’s not enough. I’m looking for a workflow-oriented solution, not just individual helpers.I’m primarily writing this for myself, because I plan to actually work with it later. I do think other people could benefit from it as well, but that’s just my personal opinion. For that reason, I’ve already made the current state partially functional and public. It is clearly not finished.If there is a better, complete solution available, I’m happy to look at it. If not, I will carry this project through to the end, because in the end I need a tool that fits my way of working.If you know of existing concepts, examples, or similar approaches, feel free to point them out. I’m always open to ideas.

tommylight wrote:

and sometimes with smoke signals...

 

Ouch! been there done that. I'm still amazed a 10mA signal could smoke like that.

BOB is probably grounded by parallel cable to pc. Check with ohm-meter. In that case do not ground BOB additionally. Also any shielded wires connected to BOB must be connected to BOB's frame ground but not to anything else.

Frame ground and DC voltage negative wire frequently not the same and might not be connected together, in that case shields preferably connect to frame ground, not DC-

This is the part I did not figure out for now.

I tried loading the configuration from PnCconf, but LinuxCNC crashed because some timer was not found. I commented out two lines in the .ini file, and LinuxCNC launched, but I do not know where I can see if it found the card.

Should I just try running some G-code?

This is my first time with MESA and LinuxCNC, but I have experience with industrial CNC machines, 3D printers, Linux, software development, and electronics.

zippoffs wrote:

I have only ever experienced issues when the VFD is on.

I tried disconnecting everything from the BOB except for the 24v coming in and the parallel port and USB from the PC (I switched the VFD to manual control). LinuxCNC ran the program with out any trips even though the VFD was running, so the BOB itself can't be the issue. I tried reconnecting one of the stepper driver pulse/direction signal wires (the steppers were completely off) and ran the program again, and it did trip, even though that wire is shielded and grounded.


 

Sounds like effects of a ground loop. You have more than one ground connection from point A to point B at one or more points anywhere on the system. You want exactly one ground circuit from each 'groundable' piece to one single point. It is called single point ground aka star connection. Redundant ground paths create ground loops which powerfully amplify interference effects from the vfd, they behave as you described above.

Potential sources of redundant grounds:
1. shield grounded at both ends
2. motor cord have ground wire
3. additional frame ground to the machine when the motor is already in electrical contact with the machine
4. the machine may be in physical conductive contact with another machine that is also grounded
5. is the machine on a steel workbench that has a grounded outlet?

Interference mitigation can be a bit of an art because of the numerous variables involved. Usually not everything has to be perfect, you can cheat some, but if the BOB is within inches of any AC when there is also a VFD nearby then I say you will have trouble at least randomly.

Does LinuxCNC see the card?
 

Good. EoE has to go.

But you see automata's posts here? Do not be surprised if it still does not work.
Thankfully, automata has kindly posted the solution here.
Please report back how it goes and if there are problems with lcec
I hope automata will guide you to use his solution.

Do you already know Andy's lathe macros?
forum.linuxcnc.org/41-guis/26550-lathe-macros
The graphical interface is fantastic.

Rather than reinventing the wheel, have you considered what it is which you are adding with you macros? Maybe you can coordinate with Andy to make them even more awesome.
Cheers,
Mark

Blocking in the "make yer own" accessories. side arm ISO20 ATC, Stand, stainless chip pan, enclosure... Fun

I just switched to default jumper positions:

Result is still the same:

dmesg and lspci outputs are provided.

That will likely not work, (not meet timing) you must jumper the card for 5I25 mode to use 5I25 firmware (the default)