Advanced Search

Hi endian,

thanks a lot.
I am using the generic driver.
Yes, the AX5125 is currently at slave 7. I will move it to the first position on the bus as soon as I am back in the shop.

The current active AX PDO entries in ethercat-conf.xml use subIdx="00", not 0x01:
0x0086:00
0x002F:00
0x0087:00
0x0033:00
0x00BD:00

Current active AX config:
generic
configPdos="false"
reduced PDO mapping
dcConf assignActivate="730" sync0Cycle="250000" sync1Cycle="0"
I also exported the AX5125 selected item from TwinCAT and now have the full SoE InitCmd export.

My next steps are:
move the AX5125 to the first position on the bus
change the active PDO subindexes from 00 to 01
move IDN 33072 to the end of the InitCmd list

I am very grateful for your help and also for your converter tool.
At the moment I am also using AI to help me work through this problem. I am not blindly copying what it suggests. I mainly use it to learn how this integration works.
My long-term goal is to add a second AX double motor drive as well, but first I want to get this AX5125 running and understand what I did wrong so I can avoid the same mistakes in the future.
What also makes me curious is that your export/converter result worked much better than my own attempt.
Do you have any idea what I may have done wrong when exporting or preparing the file?

PCW wrote:

Here is the encoder input circuit, you can check if the 26LS32 is faulty by seeing of the
outputs follow the input state. (the outputs are inverted from the TTL input levels)

 

If the pins are correct (3. 5. 13.), there are no movement on the not working channels.
Can I force 5v to this pins (via wire from 5v supply from the stepper pins) to see in hal show will it change or not?

 

If that is the same result for both cards, seems both are OK>
Check wiring and voltage at the Mesa inputs, might be to low to trigger.

PCW wrote:

Also the 26LS32 does not connect to the FPGA directly but rather through U13 (74CBT16211
level shifter) If U13 was damaged (by say a mistake in P1  connections) this could cause an
encoder issue as U13 is shared by the encoder interface and the P1 parallel expansion port.

You can do a quick check of U13 with mesaflash (assuming P1 is unconnected):

mesaflash --device ethernet --address [card-address] --rpo 0x1008

This should respond with: 0001FFFF (the all high open circuit port data for the parallel
expansion port = P1). Damaged U13 I/O pins that connect to P1 will typically be stuck low.

 

To the P1 just connected the axis indexes (1-5 pins - you did the firmware to me) 50-100Om through resistor as you wrote me (5v supply GND to the driver and from the driver back to the P1  through a  100Om resistor)
On the table there wont be a phisical connection to P1, just 5v supply.
Here it is (both has the same respond):
 

Going to try and explain the project in a way that y'all can imagine as I feel like it should not be too difficult to program in linuxcnc but I wanted to hear the community's inputs

project: Regular Taig CNC lathe with the 5c headstock. I have already converted the 5c headstock to a guide-bushing-esque headstock. My plan is simple: add a second linear "Z axis" that holds a servo that spins the stock and can also move forward and back to feed the stock through the guide bushing headstock. This guide bushing 5c headstock is thus unpowered.

My thought: Could I just have this new axis be the official Z axis, and have the native tag Z axis be another regular linear axis where it simply acts as one of the offset parameters when setting tool offsets? So the only movement the regular taig Z axis would do is move when switching to a different tool such as drills or boring bars of various lengths, while the newly added Z axis behind the headstock acts as the primary Z axis.

I have all of the build details down so I don't think that will be a problem, but I want to know if you guys suspect it will be hard to code in linuxcnc. I do have experience setting up regular lathes & 3/4 axis cnc machines.

spumco wrote:

Mods - please marked SOLVED

Done, thank you.

Holy #@)(*-balls!!!

Who would have thought RETAIN_G43 = IGNORE_G43?

G43 works on the same line as Tn M6, as well as on the next line.

More work left to do, of course... but after about 3 years I'm finally making chips on this stupid lathe.

Thank you all!

Mods - please marked SOLVED

what are you using the base-thread for?
10000 seems incredibly small.

if you are using custom kinematics, you might have to build again from source, you may not be able to use my debian packages.

It requires you to be logged into github to get the debs I think.

I'm using the latest available version of LNC 2.9. I regularly update my system, and the LNC version updates automatically. I initially installed it from the official ISO and also the DE.

Sadly, they are not alone. Google, Apple, Facebook, X, Youtube to name just a few who also do the same. Facebook is probably the worst. If you look at their business backend features its whole new world of data exploitation user never see.

Discord's sole reason for existence is selling user data, and apparently getting hacked often.

JT wrote:

Discord seems to be aimed at gamers that like flashy colors.

And LinuxCNC users apparently by the link I shared, also PrintNC have an active forum and its often used for software support. I even run a server for that reason and I have never played a computer game in my life. 

* the post processor file is saved as .txt , not as .cps because .cps cant be uploaded *
** i attached a picture which i used to explain claude ai where where the 4th axis assembly is - it was for the python script and simulation screen that claude should add, but this helps to understand where everything is**
*** another picture shows how it looks when the end mill is  is offset to the workpiece on my machine when starting the g-code

Hi, last week i build my rotary axis assembly and tested it with simple g-codes that are created from a python script that i build with the help of claude.ai . Its for surfacing square/rectangular timber, because i am planning to build some wood tables, etc. and i have a lot of stock material. The python script works perfectly and does what i needed. Its surfacing one side, then turning 90°, again surfacing and next side, until all sides are surfaced. I was really happy and thought that i can create my first solid wood coffee table and machine the first leg on Monday.
Unfortunately this didnt work out well. 

*** the problem is described below the Blue text.
I am trying to make it as short as possible, but also i want to be as precise as possible:
First of all, the rotary axis is mounted in the Y-direction. My CNC router is a Moving-Gantry machine (XYYZ), 2500x1250mm table travel. My first plan was to mount the rotary table parallel to the X-axis so physically parallel to the Gantry, but this would give me only about 900mm of machining capacity and for the stock timber this was not optimal and if i want to build bigger table-tops by gluing together the surfaced/machined timber i thought it will be better to mount it along the Y axis, which is my long axis (2500mm), especially because i had a piece of 3meters of fake hiwin linear rail that i could cut in half and mount the tailstock on it (- which gives me about 1500mm of rotary axis lenght).
This 4th axis assembly is done and working, but generating a g-code that works same as on the Fusion 360 simulation seems to be a huge problem that i tried to fix since yesterday, for almost 20 hours without sucess.
I thought Claude.ai will manage to help me out, but since yesterday i think i have tried everything i could and everything what claude told me. I first had the rotary setup as A-axis, because i thought that it doesnt make a difference and claude told me that Fusion has the A-axis hard coded to be along the X-axis not Y-axis, but in machine configuration its possible to create a machine and add a A-Axis and choose that it will be along the Y-Axis. I did that and had still some problems, so claude told me that it can be tricked, so claude modified my Post processor, but the main problem was still there, so i setup a new Linuxcnc config with B-Axis isntead of A-axis.


Now to the problem/problems:
The End mill in Fusion 360 simulation is horizontally to the workpiece (sometimes tilted at specific operations and settings that i have tried), not from Z-axis direction, but from X-Axis and although i have set the origin correct.
I have choosed Multi-Axis Operation "Rotary Parallel" (Sprial mode or Line mode, but it is same for Rotary Pocket operation) and have set in the Multi-axis tab: "Rotary axis: Setup Y-Axis", but the End mill is physically not in the Center above the workpiece/rotary axis while air-testing the g-code on the maching.

I zero Z in the center of the rotary axis, same for the X axis, and Y-axis zero is on the Chuck side where the 4th axis is mounted. (as the origin in Fusion 360 setup.
So, the X-axis is somehow offset to X30 instead of X0 or close to X0.. I have checked everything  i could, tried different settings to see what happens, e.g.: when using stock to leave axial 10mm it moves the X offest by that 10mm, so e.g. instead of X30 its X40 at the beginning and of course it is always offset. So for example the G-code starts, the rotary axis positions the timber to 133 degree, so almost 45° - which makes one corner of  the rectangular timber to point almost exactly up towards Z axis, but the X-axis does not move in into that corner, like in the Fusion operation sumulation, but is offset by that e.g. 30mm, so the highest point of the timber is the corner, but the end mill wants to cut the tilted flat surface left or right of it. See picture below
Not only is that not like in the simulation, but also its a problem because i dont have much space in Z-axis and that corner touches my Z-axis plate. (i have even cut out a piece, but still had to stop the g-code at some point because it got too cloose while rotating).
Due to the fact that my designed table leg is a pretty complicated form compared to lets say a tapered wood leg, i designed a simple tapered model to test if the problem is my model (which i could not really believe). The problem is same - its not cutting in the center.
BUT i moved the X axis away from the rotary axis and carefully watched what is actually going on when using Rotary Parallel "Spiral mode". 
I explain: Z Axis moves up, Rotary axis starts rotating and simultanously the Z-axis and X-axis are moving in a circle. So, there are like creating a Circle around the work-piece, but the Rotary axis stops at some point after i think full turn, then rotates back to position to start angle and when it rotates back the Z and X-axis circular movement stops, but starts again when the rotary axis rotates for maching.
But, why does the X axis moves and why is it offset by e.g. 30mm?
Shouldnt the X axis be on the center of the rotary axis and just the Y-axis moves parallel/along to Rotary axis while the rotary axis rotates and the Z-axis just moves up and down, depending on the form of the model? I mean, its a spiral operation where the main axis are the Rotary axis, Z-axis for depth and Y-axis for the lenght of the workpiece (timber, 350mm)

I could write and write - but i am already so confused that i am currently trying it again on my pc, without success. I am uploading pictures of the Machine configuration, Operation settings, How my Rotary axis is mounted on the machine, Post-processor and g-codes. 

I really hope someone can help me out or at least point me to the right direction and sorry for the long text.

PS: The last thing claude told me is that i cannot get it to work with the B-axis, even he told me so on today morning. Claude said "lets go back to A axis" and tricking the machine by modifying the post processor and so on.
I cant imagine that its not possible with the B-axis along the Y-axis, but maybe thats true.

You think, maybe it can be the inputs to the main microchip if the 26LS32 works correctly?

It's quite unlikely that the FPGA has been damaged, much more likely that the 26LS32 has been.

Also the 26LS32 does not connect to the FPGA directly but rather through U13 (74CBT16211
level shifter) If U13 was damaged (by say a mistake in P1  connections) this could cause an
encoder issue as U13 is shared by the encoder interface and the P1 parallel expansion port.

You can do a quick check of U13 with mesaflash (assuming P1 is unconnected):

mesaflash --device ethernet --address [card-address] --rpo 0x1008

This should respond with: 0001FFFF (the all high open circuit port data for the parallel
expansion port = P1). Damaged U13 I/O pins that connect to P1 will typically be stuck low.


 

PCW wrote:

In one picture you have the encoder inputs connected, this may affect test results.

Here is the encoder input circuit, you can check if the 26LS32 is faulty by seeing of the
outputs follow the input state. (the outputs are inverted from the TTL input levels)

 

Not really understand, but the result is the same, as it was with the TTL encoder.

Thanks for the hint how to check the 26LS32. Tomorrow I will try.
You think, maybe it can be the inputs to the main microchip if the 26LS32 works correctly?