Advanced Search

What version of lubuxcnc are you using?
Are you using the screen button the start the program running?

Also see the linuxcnc python module.
linuxcnc.org/docs/devel/html/config/pyth...inuxcnc_command_code

look for:
display_msg(string)
error_msg(string)

Ok can you run linuxcnc in a terminal and post the output.
Also what version of linuxcnc are you using?

Thank you for your answer. Wish you good luck

Hey PWC,

Thanks for the info. I'll see if those changes are already in Pathpilot and if not I'll figure out how to implement them.

Did you have a chance to look at creating the .bin file for the Tormach? If you need any info from the control, just let me know

Here's a pic of the .hal file if it's helpful 

I am cross posting this from the Lazarus forum as well.  If there is any light that can be put on the subject it will be very much appreciated.

I have inherited an old but essential app that connected from lazarus to LinuxCNC through PythonForLazarus.  The older version has been running on python 2.7 for many years.  Owing to the need to software upgrade I am trying to reconfigure to newer installation.  So I am at this point:-

- I can use CLI to connect to linuxCNC and have no problems. 

- Demo Python packages from LinuxCNC run with no problem.

- A test application set up in lazarus using python4lazarus as per the video on Youtube by Al As works exactly as expected.

So it seem that the configurations from both sides are correct, however as soon as I enter the python command "import linuxcnc" I get the PyExc_ValueError.  (I do not get any error for this in the CLI)

OS Debian12  installed from linuxCNC's live distro with PreemptRT.
Lazarus 3.4 and FPC 3.2  as installed with fpcupdeluxe.
Python 3.11 ( required for linuxCNC?)

I did an environment comparison between the CLI and Python4Lazarus setups.  The results show only that Python4Lazarus did not have the Pythonpath set.  I added that to the Pythonengine property, but to no avail. ( I attempted a few other methods as well)

  PythonEngine1.PythonPath := '/usr/lib/python3/dist-packages';

I have spent two day solid fighting with this. I am not an experienced programmer so I have probably overlooked something obvious. (please be patient) I have trawled the forums and run all the AI's dry.   I urgently need assistance:(

Changes in the hostmot2 driver to recognize the PCI ID code (5925 vs 5125)
I f you had the Pathpilot source, it would be easy  to change.

Here are the changes to the LinuxCNC driver:

github.com/LinuxCNC/linuxcnc/commit/c84a...c4da26fee531569f07a2

Would you happen to know what changes in LinuxCNC 2.9.2 were required to support the 5i25T?

I was faffing around with Linux a bit and managed to get a wifi driver working (hurrah) and then I thought to myself, why isn't PathPilot recognizing the 5i25T if it's supposed to appear to the OS as a "5i25". You were right PCW that it has a different PCI ID and path pilot will not normally recognize the card. 

PathPilot's card decision logic is in a python file shoved in a bunch of folders. It figures out if there's a 5i25 installed by matching the PCI ID for the 5i25 with the output of lspci. If that python file doesn't find PCI ID (I think this is right, recalling it by memory) 2362:5125 it falls back to checking the ethernet connection. Simply changing the logic to look for 2362:5925 (PCI ID of the 5i25T) instead allows Pathpilot to move forwards to booting. 

The next problem I run into is that I believe the HOSTMOT2 PCI driver is supposed to flash the card installed with the firmware provided by Tormach. I didn't find mesaflash installed on the system so I assume the driver handles the flashing process itself. I know that mesaflash requires you to specify the T when flashing the card or it just returns "card not found" and hopefully it's the same with the driver. Going to dig through more files to see if I can find where it's being referenced

It seems like if you modify the setup python file for the card you could pretty much have it recognize any Mesa card as the logic isn't that complex. I could probably write up a little guide on how I changed the python files to recognize a different Mesa card than supported if you think that would be helpful? I don't see a lot of information on the guts of PathPilot in the forum.
 

You rock!

I noted your comments on Z axis machining and thought I might stick my neck out here.
Your machine looks like it came with the old Philips controller from one of the early photos. They set the axes up differently to what I believe is the current convention. That is with the Y and Z axes swapped. So you might find your servo closing relays in the wrong physical order on the DIN C rail. The convention seems to be X side to side, Y forward and aft, and Z up and down. Certainly Heidenhain uses that on controllers from my TNC 155 up to 400 series. Early Bridgeports used the TNC 155 so they are that convention also.
Rotary axis A, B and C rotate around X, Y, and Z axes respectively. So I code my rotary axis as C, but it is possible to not use that convention by changing a parameter.
 So in the your programming examples you wouldn't change the axes orientation, you simply tell the machine the cutter in in the Y axis by using G18 in the G code.
There is a program showing this in one of the links to my cloud previously. It's the one where it pretends to cut a spiral thread using a cutter in the Y axis and the C rotary table.Rather like a vertical lathe.
The next problem is that on our machines the cutter is usually attached to the Y axis, so it moves that way. The other 2 involve the table moving up and down and sideways.. On the typical Bridgeport of that era, the quill moves the cutter in the Z direction and the table moves back and forward and sideways. And yet you set up the program identically for both!
So the convention is that the DATUM is the work piece. So when you do the familiar right hand rule with your real hand, You place the back of your hand on the work piece whilst standing in front of the machine. And keep it stuck in the same place on the work piece as it moves.
Now look at where the cutter is moving relative to you hand:

If it is moving in the direction  your thumb is pointing then it's moving positive X
If it is moving in the direction your index finger is pointing then it's moving positive Y
If it is moving in the direction your middle finger is pointing then it's moving positive Z

That works for all types of 3 axis machines.I have no idea how they label machines with 5 axes and seemingly infinite rotation axes.

In our case what seems counter intuitive is that for X+ the table will move left and for Z+ the table will move down.

Cheers,
David
 

Where is the ISO and does it boot in Live mode?
All my Ryzen's are gone except a R7 5700U in a laptop with a TDP of 15W including GPU, so should be worst case scenario for testing.

Won't irqaffinity=0 help?

Can i have 20 of those, please?

Here are the pages from my manual on how to disassemble and re-grease the spindle. Mine is NT40 so a bit bigger and with a different pull stud. But I would think much the same. I've added the page on how to adjust the claws. It's very quick and simple. The whole assembly item 2 is fitted when it's all assembled into the spindle, in my case back in the machine. It simply screws in. When the depth dimension is right ( I used the tail end on my dial calipers) you simply tighten the grub item 1. That presses the ball into the coned recess in the stud and expands the thread onto item 2. The hatched portion where item 2 points to are actually longitudinal cuts in the thread.
Your 30 size tool holder will have a different adjustment length I would think. .In the diagram you can see that as the claws are retracted they are jammed closed by the bore of the spindle. That means that it is more likely any rattle is due to damaged or worn claws I think. The claws are the finer cross hatch.
Cheers,
David