Advanced Search

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