Advanced Search

main photos of machine here

you can see it was a hybrid machine with handwheels also

that means more gears inside and bad servo tuning and more noise

so i removed all that first thing

just a few things i want to noteThe z axis has been redesigned to use a flexible coupling from a old mazak cnc.  They are much better than the standard rubber type.  So I removed the whole belt reduction setup for that axis  which removed at least 0.05mm backlash.  The X and Y still have 0.1mm backlash.  I might put scales on them later but for my first job on machine X and Y don’t really matter.

 

Dudelbert wrote:

I am still struggling with threading.I have tested it at very low speed (100 RPM) in the hope to see something that helps me find what is wrong. But I cannot really say what I am looking at. The result is repeatable, and at least to me it looks like a constant offset that makes it wrong. I have set the cross-slide angle to 0, so that is not the reason. It is supposed to be an M8.



All these tests point me in the direction of the spindle encoder being OK. Are these tests the wrong way of testing this? What else can it be?

 

Take the below with a grain of salt, of course.

Spindle speed:  there is a bug in LCNC which causes a different start point during spindle synchronized motion if successive passes aren't at the same speed.  Constant surface speed is not OK in multi-pass threading.  Same reason folks have reported trying to do thread repair and lining up on a thread by hand, only to wipe out the threads when the spindle is run because the start point is different.

I don't think this was your problem, as I did a screen-cap of your video looking for the start point on each pass.  Pretty constant start point near as I can tell.

It looks like your thread is cutting mostly on the left (leading) side, which would correlate with the Q value you have set.  But it doesn't appear to be going much deeper each pass.

Like you cut one pass deep, then scrape the left side each successive pass without really going much deeper.  The chips look terrible... instead of a 'wire' each pass, you have scrapings.

 

Maybe run another attempt, but change the Q, E, and L values to 0 (straight in),  make sure I/J/K are diameter values, an R-value of 2.0, and ensure you have the spindle in G97.

This might help troubleshooting by taking out a few variables which may be obscuring machine issues.

EDIT - I jut re-watched the video and it's cutting the RIGHT side, not the left.  Like the "Q" value is backwards or something. The tool is moving at the same pitch each pass, but it's offset to the right slightly each successive pass.  Weird.

Es werden doch verschiedene 7i98 angeboten. Welche genau?

Das 7i98 Bitfile von Baidu funktioniert nur mit der "v1.1", lässt sich aber auch auf eine 7i92 flashen, weil es in Wirklichkeit ein 7i92 Bitfile mit 3 Kanälen ist, statt 2. Die 7i92 zeigt dann 50 Pins an, brickt aber nicht. Trotzdem nicht nachmachen!
Wenn man dieses Bitfile auf eine 7i98 flasht, die dem Original entspricht, brickt die Karte und sollte sich nur per JTAG wieder richten lassen.
Die Pinbelegung ist auf meiner großen 7i98 nicht angeschrieben, ist aber mit gleichen Pins des FPGA verbunden, wie die 7i92 oben in meinem Bild. 3.3V Pin ist der quadratische.

Sowohl die 7i92 oben im Bild, als auch die 7i98 in voller Größe funktionieren mit originalen Bitfiles von Mesa. Die 7i98 "V1.1" funktioniert nicht mit originalen 7i98 Bitfiles, es lassen sich aber, neben den Bitfiles von Baidu 7i92 Bitfiles von Mesa flashen, ohne dass sie brickt. Die funktioniert dann aber in EMC nicht, das dann eine Hostmot2 Fehlermeldung ausspuckt. Die "V1.1" funktioniert also wirklich nur mit chinesischen Bitfiles. Eventuell kann man selbst ein Bitfile machen, ich habe es aber noch nicht probiert, da ich noch keinen PC dafür habe und die AMD Software auf meinem Raspberry nicht laufen wird.

Beim Flashen sollte man bei allen Karten wie folgt vorgehen:

sudo mesaflash --device ethernet --addr 10.10.10.10 --write bitfile.bit --fix --fallback
sudo mesaflash --device ethernet --addr 10.10.10.10 --write bitfile.bit --fallback
sudo mesaflash --device ethernet --addr 10.10.10.10 --reload --fallback 

sudo mesaflash --device ethernet --addr 10.10.10.10 --readhmid  sollte dann die neue Pinbelegung ausspucken. Falls die Karte nicht gefunden wird, funktioniert die Firmware nicht und wird die Karte bricken, wenn man sie in den normalen Bereich flasht. Falls die Firmware nicht funktioniert, trennt man die Karte von der Stromversorgung und verbindet sie wieder, dann läuft sie wieder. Das Bitfile sollte man dann nicht mehr nehmen.

Falls das Flashen funktioniert hat und die korrekte Pinbelegung angezeigt wird, geht man dann weiter wie folgt vor:

sudo mesaflash --device ethernet --addr 10.10.10.10 --write bitfile.bit --fix 
sudo mesaflash --device ethernet --addr 10.10.10.10 --write bitfile.bit 
sudo mesaflash --device ethernet --addr 10.10.10.10 --reload 

Das Bitfile ist dann dauerhaft geschrieben und ist auch nach dem Trennen der Stromversorgung im Flash gespeichert wird also immer automatisch geladen.

Diese Prozedur ist auch in der chinesischen Anleitung so zu finden.

Die kleine 7i98 "V1.1" würde ich nicht noch mal kaufen, da die original Bitfiles von Mesa mit der nicht funktionieren (es sollte aber möglich sein selber welche zu schreiben). Die oben gezeigte 7i92 und die 7i98 in voller Größe entsprechen aber dem Original und funktionieren mit den originalen Bitfiles von Mesa. 



 

Thanks for confirming that jitter itself is not the issue. This was expected with my tuning in place..
One of the difficulties with Ethercat, is that there are no IP addresses on the network to test network latency against. If this was a Mesa card, we would do that with sudo chrt 99 ping -i .001 -c 600000 -q 10.10.10.10 Perhaps there is an alternative method.

I think it can be assumed on a properly tuned Ethercat Intel NIC (like yours) that network latency is not a factor. Ethercat has an inherent advantage over Mesa because of its customized network protocol that uses significantly less bandwidth due to smaller packet sizes. The main network latency culprit is coalescing which has been disabled, SMP affinity has been used to ensure the NIC interrupt is running on the same core as Linuxcnc and a number of other optimisations that could introduce network latency have been tamed.This is confirmed where we see a substantial tightening of the Standard Deviation in before and after latency-histogram tests (more than halved from 2.3  to 1.1 usec on Mike's PC). This means the system is much more deterministic with fewer latency spikes (eg narrower bell curve, much more consistent timing on the servo thread).

It all comes back to your environment. eg a configuration issue or a problem with the ethercat system itself (ether the Ethercat master or the linuxcnc-ethercat driver. CNC is a very small subset of what applications the iGh master is used for. Its mostly used on factory floor automation. This is why I find it hard to believe that it has a problem as if it did, the Igh issues register would be flooded with reports and it isn't.

So by my analsyis,  the issue has to be a configuration issue or the linuxcnc-ethercat driver.

Hey guys 

just thought i would post this latest retrofit i am doing currently.  I know when i was just starting out 10 or so years ago i lived on this forum and really really appreciated the info on here.  So I am trying to post more so that maybe this can stay as a record and maybe help someone.

Retrofit is almost at the end of the process.  And I don't really have any questions currently though advice is welcome   So i thought maybe the show your stuff category would be the right place.  Mods feel free to move this..  

just editing to add a youtube video of machine.



machine is made in 1980s so at least 40 years old.

it has a vertical spindle on a over arm plus a horizontal spindle

all BT50

The reason i bought it was this has a 2m travel in the X axis  Y axis is 700mm and Z axis has 1150 max workpiece height

max speed is only 1800 rpm but that is ok.  i will be using larger tools on this and mainly only rotating at 400 RPM.

this has a gearbox and 4 speeds for both spindles, hopefully the photos make sense.  I will probably only use one gear and make it a two speed and use the VFD for the rest of the speed changes as that will allow enough torque and i think the extra gears are not needed.  time will tell i can always change that.

Photos coming in the next post

 

Damn, I was afraid of that, unfortunately I had to leave the workshop… just missed it. Thanks for doing it right away today! Sorry for my vad Timing....Thanks a lot for exporting it, I’ll test it tomorrow evening right away!I’m afraid I won’t be able to sleep tonight :O

Surmetall wrote:

Thank you for your help, and sorry for taking up your time. I hope to learn this myself as soon as possible so I won’t have to bother anyone.The exported file was called “.tnzip” for some reason I have no idea why. I renamed it to “.zip” so I can upload it here.
 

here is output.. check it all

Greetings everyone. Today I went to the customer's office after the company closed at 5 pm. I just got back at 8:30 pm. I had the chance to do some more testing, and I have to agree with Grandixximo.
I don't know why, perhaps I was in a hurry to not down the customer's machine for too long, and I made some mistakes.
The jitter results:
Debian Trixie, kernel 6.12.74-rt, latest Grandixxmo patch, Grub command line optimization (isolcpus, etc.) with 4 glx files open, 2 browser windows open, full-screen window movements, switching between different desktops, max jitter 65 microseconds.
The machine with refClockSyncCycles=-1 normally doesn't emit any noise, except for some window movements.
With refClockSyncCycles=1, it emits some noise.
With both refClockSyncCycles=-1 and 1, the command
ethercat upload -p 0 -t uint16 0x1C32 0x01 returns 0x0002 2
Pin pll-error oscillates around -1200 to 1300
Pin pll-out oscillates -5 to 5

I tried the commands:
ethercat upload -p 0 -t uint16 0x1C32 0x02
ethercat upload -p 0 -t uint16 0x1C32 0x03
ethercat upload -p 0 -t uint16 0x1C32 0x05

but it returns the error failed to upload sdo : no buffer space available

Debian Buster, kernel 4.19-27-rt, no optimizations on the Grub command line, with 4 glx files open, 2 browser windows open , full-screen window movements, switching between desktops, max jitter 95 microseconds.
With the same Grub optimizations as Trixie, max jitter is 75 microseconds.
With refClockSyncCycles=1, it easily emits noise.
With refClockSyncCycles=-1, it works flawlessly and without Grub optimizations, which with GRUB optimizations
pll-err pin from -1800 to 2000
pll-out pin oscillates with only two values: either -1000 or 1000

So I deduce that even Trixie has lower jitter than Debian 10, but for some reason, Debian 10 lets my machine work and Trixie doesn't.

It has its own GUI....I have not tried it with other UI's, but should be able to work. You can save the g-code and load it in any Linuxcnc ui.

In the readme->quick install section it mentions the 'standalone' mode

Thank you for your help, and sorry for taking up your time. I hope to learn this myself as soon as possible so I won’t have to bother anyone.The exported file was called “.tnzip” for some reason I have no idea why. I renamed it to “.zip” so I can upload it here.

both file missing startup IDNs

send me your active TC3 project archive I can translate it at my place... 

Hi Endian,sorry, but I still cannot get it working. I spent many hours on it yesterday evening, and I am obviously still doing something wrong.I am not sure whether I am missing an important step, whether I made a mistake in the configuration, or whether I am still missing a required driver or component.As you suggested, I redid the whole process from scratch using the current translator from the publish folder: fresh TwinCAT export, start the, use, and then convert the export again. This time the conversion itself seems to have worked properly.I am attaching:

• the fresh

  ethercat-conf.xml

  generated by the current translator
• my adapted machine

  ethercat-conf.xml

  with the other real bus slaves added back in

Current status on the real machine:
LinuxCNC 2.9.8
IgH EtherCAT master 1.6.8
all non-AX slaves go OP
only the AX5125-0000-0216 stays inCurrent error:
AX5125 stays in PREOP + ERROR.
AL status message 0x0045: "MBX_SOE"currently shows:ethercat slaves
0  0:0   OP     +  EK1100 EtherCAT Coupler (2A E-Bus)
1  0:1   OP     +  EL1008 8K. Dig. Eingang 24V, 3ms
2  0:2   OP     +  EL1008 8K. Dig. Eingang 24V, 3ms
3  0:3   OP     +  EL1008 8K. Dig. Eingang 24V, 3ms
4  0:4   OP     +  EL2008 8K. Dig. Ausgang 24V, 0.5A
5  0:5   OP     +  EL2008 8K. Dig. Ausgang 24V, 0.5A
6  0:6   OP     +  EL2008 8K. Dig. Ausgang 24V, 0.5A
7  0:7   PREOP  E  AX5125-0000-0216 EtherCAT Drive (SoE, 1 Ch.)
8  0:8   OP     +  EK1100 EtherCAT Coupler (2A E-Bus)
9  0:9   OP     +  EL2008 8K. Dig. Ausgang 24V, 0.5A
10 0:10  OP     +  EK1100 EtherCAT-Koppler (2A E-Bus)
11 0:11  OP     +  EL1008 8K. Dig. Eingang 24V, 3ms
12 0:12  OP     +  EL3255 5K. Potentiometerauswertung mit SensorversorgungCould you please compare:

• the freshly generated translator XML
• the adapted machine bus XML

My main question is:
Do you already see from these two XML files what is still wrong in the AX5125 startup / SoE configuration, or what the minimal correct AX5125configuration should look like?If there is already a known working example config for an AX5125 with, that would also help a lot, because at this point I am worried that I may still be missing something fundamental.ChatGPT helped me sort the files and compare the configs, but the machine is still not getting past, so I would really appreciate your expert view on the actual AX5125 setup.Thanks a lot for your time.

greetings
Tom

I double checked our ini's, and we both have the encoder scaling set to 8000 pulses/rev. Not sure what would cause that drift you are seeing.

I really like this. Are you running your router/mill on your web UI?

The comparison I'm making is about latency between Debian 10 with Kernel 4.19-27-rt and Debian Trixie Kernel 6.12.74-RT. Although Trixie's Grub has different optimization strings and Debian 10 has no optimizations at all, Debian 10 has half the jitter of Trixie on the same PC. Debian 10 has a jitter of 40 microsec and Trixie 85 microsec. So, since I want to do a further test with a new PC, can you advise me on which motherboard and processor would have the lowest jitter?