Advanced Search

Fair point on the age of the base, but it is not as stale as the "1.5.2" label makes it look. YangYang's build sits on the 1.5.2 API boundary, but a lot has been grafted on top of it. Martin Ribalda's refactor moved the slave scan, slave config, SDO request, dictionary, and state-change FSMs into per-slave state machines running off externally supplied datagrams, which means every slave progresses through INIT to PREOP to SAFEOP to OP in parallel instead of the master FSM walking them one at a time. That is where the OP speedup comes from, not the age of the base. On top of that there is an SDO injection path, so CoE transfers ride on the realtime cycle alongside PDOs and startup list SDOs plus PDO mapping writes do not each cost a full master FSM round trip. The 1.6 era API surface is mostly backported too (ecrt_master_sync_reference_clock_to, mbox gateway, rescan, RT slave request hooks, full FoE request API, reboot FSM, bulk register read/write, SII from file, and so on).

On the kernel side, the native drivers have been updated for modern kernels. The devices/ tree ships 6.12 variants of igb, igc, r8169, genet, e1000, e1000e, and stmmac, and DKMS builds cleanly against Trixie's 6.12 headers.

I tried the obvious "just tune 1.6.9" route first. Applying the same constants YangYang's build uses (EC_WAIT_SDO_DICT=0 and EC_SKIP_SDO_DICT=1) on top of stock 1.6.9 drops OP from around 15 s to around 12 s. YangYang's build reaches OP in roughly 5 s on the same bus. The remaining gap is not a constant that anyone can tune; it is the per-slave FSM architecture, and 1.6.9 does not have it. 1.7 does not have it either, I checked, master/fsm_slave.c is still 685 lines in 1.7, the same as in 1.6.9, against 1339 lines in YangYang's build.

So "use the newer version" is the intuitive answer but it does not actually close the gap. Porting Ribalda's refactor cleanly onto 1.6.9 is weeks of work with a large regression surface. Shipping YangYang's build with modern Debian packaging gets working fast OP debs this week. Different tradeoff, not a rollback.

OP transition time is of course unrelated to grinding itself, this is about how long the user waits for the machine to come up, not motion behavior.

rodw wrote:

It makes no sense to roll back to a version built for  kernel 2.6 (Trixie's is 5.12) that's not been touched for 7 years...

You mean 6.12 for sure, 5.12 is also pretty old.

It makes no sense to roll back to a version built for  kernel 2.6 (Trixie's is 6.12) that's not been touched for 7 years...

Here's the thing, it may be difficult to tell what happened, but the card did not leave Mesa with
a blown  27 Ohm resistor network and a bad 74ACT541. Also, it is important to know what happened
so it does not happen again.

The good news is that the card is repairable. Mesa normally charges $35.00 for minor repairs like this.

adhamamer wrote:

Im pretty confident that i did not cause this damage, all the wiring Ive done on tb2 was also done on tb3 to a standard tb6600 stepper driver
What do you guys think i should do?

I have no idea what do you expect from us to tell you as i am sure you do not want to deal with reality.
My reality is: I have over 80 or 90 of Mesa boards in daily use, never ever had one fail nor had issues, ever, mostly on industrial machines in use 24/7/365.
P.S.
This is my polite answer as you said "im pretty confident...".
Next time try to figure out how that happened instead of insisting it did not happen.
Also, whatever the price of any Mesa board is, i have to pay at least twice that to get theme here, and i pay that gladly.

jlm123 wrote:

So My brother and I converted a PM-940V to a CNC machine.

What did you use for the ball screws and plates? Did you create your own or use a purchased kit?

Update:

MESA Replied:“OK, examined the cardU15 (STEP+/DIR+ 0..3 driver) and RN31 (27 Ohm resistor networkin series with STEPO+/DIRO+ and STEPO-/DIRO- pins) were both damaged.RN31 had opens on the STEPO+ and DIRO+ pins.Damage was likely caused by connection of theSTEPO+,DIRO+ pinsto either something outside the 0 to +5V range (even briefly) ora long time short of the STEPO+,DIRO+ pins to 5V or ground.”

Im pretty confident that i did not cause this damage, all the wiring Ive done on tb2 was also done on tb3 to a standard tb6600 stepper driver
What do you guys think i should do?

@papagno-source check these as well please
0x1C32:02 (cycle time), 0x1C32:03 (shift time), and 0x1C32:05 (min cycle time), 0x1C33:01 (input side)
Would still love to get direct access to the hardware so that I can check myself...

Edit:
YangYang found a 1.5.2 that is much quicker to OP

github.com/synapticon/Etherlab_EtherCAT_Master

Will try to port to 1.6.9 stable, otherwise make compatible linuxcnc-ethercat package for this 1.5.2

The OP times should not relate to the grinding.

dear sir i spent the last days trying to improve my understanding to linuxcnc system and structure , i hope to give hand and i suggest this proposal " what if we do the tangent calculation in parallel interpreter and syncronize the data somehow whith index ", i am not sure if it is the best practice but i am tring

Hallo
Bin gerade bei der Suche nach Hilfe und bin im  Internetr  genau über mein Thema gestolpert. Aber zuerst eine kurze Vorstellung:
Bin 67 Jahre alt und seit 40 Jahren im CNC-Geschäft. Zuerst Maschinenbediener, später Programmierer. Baue schon seit Ewigkeiten kleine CNC-Maschinen für den Modellbau aber fast nur mit Mach3-Steuerung. Habe gerade eine kleine 5-Achs mit Mesa-Clone 7i92 in Betrieb genommen und bin total begeistert von den Möglichkeiten mit Linuxcnc. (Aber ohne die Hilfe von Gemini hätte ich das nie hinbekommen)
Und das führt zu meinem Problem: Vor lauter Begeisterung habe ich gleich eine 7I98 bei Aliexpress bestellt. Hab mir von der KI die Chinesische Anleitung übersetzen lassen , die Bitfiles aus dem Internet gesucht und das Board prompt gebrickt. Da Ihr dieses Problem ja offensichtlich gelöst habt: Gibt es eine sicher funktionierende Anleitung zum flashen und woher bekommt man die richtigen Bitfiles ? 
Danke und viele Grüße !

See linuxcnc.org/docs/devel/html/gui/gmoccap...cities_and_overrides

You are welcomed, always.

Still cant get it to wok.

Print file information:
RUN_IN_PLACE=no
LINUXCNC_DIR=
LINUXCNC_BIN_DIR=/usr/bin
LINUXCNC_TCL_DIR=/usr/lib/tcltk/linuxcnc
LINUXCNC_SCRIPT_DIR=
LINUXCNC_RTLIB_DIR=/usr/lib/linuxcnc/modules
LINUXCNC_CONFIG_DIR=
LINUXCNC_LANG_DIR=/usr/lib/tcltk/linuxcnc/msgs
INIVAR=inivar
HALCMD=halcmd
LINUXCNC_EMCSH=/usr/bin/wish8.6
LINUXCNC - 2.9.8
Machine configuration directory is '/home/christian/linuxcnc/configs/sim.axis'
Machine configuration file is 'axis_mm.ini'
INIFILE=/home/christian/linuxcnc/configs/sim.axis/axis_mm.ini
VERSION=1.1

check_config:
Unspecified [AXIS_A]MIN_LIMIT, default used: -1e99
Unspecified [AXIS_A]MAX_LIMIT, default used: +1e99


check_config:
[JOINT_3]MIN_LIMIT > [AXIS_A]MIN_LIMIT (-150 > -1e99)
[JOINT_3]MAX_LIMIT < [AXIS_A]MAX_LIMIT (250 < +1e99)

check_config validation failed

Debug file information:
(empty)



.ini atached.

Thanks for the thanks RotarySMP.
I watch your videos. There's a certain satisfaction in solving the puzzle to bring these machines back to life.
I owe a special Thanks to PCW,  tommylight and others. Without this forum it would have been pointless.

Valve Body Video

Greetings everyone.
So I tested Grandixximo's latest fix.
Slave 0, i.e., the VIPA's I/O, wasn't synchronizing, while the drives were. That is, the VIPA card's Run LED wasn't staying on, but blinking.
So I decided to change the slave sequence. The drives were on 0-1-2, and I/O was on 3, last.
Now slave 3, i.e., I/O, is running correctly.
I started testing. I have the impression that the drive quotas are read faster at startup, sometimes almost as fast as Debian 10. I tried refClockSyncCycles=1 and refClockSyncCycles=-1. In the refClockSyncCycles=1 mode, the axes emit noise more frequently.
The refClockSyncCycles=-1 mode seems to work better, but sometimes I hear a little noise, especially if I move the browser windows.
In refClockSyncCycles=-1 mode, the pll-err pin oscillates from about 800 to -1000, but if I move the windows, it sometimes reaches -10000, and I seem to understand that as the value increases, the noise increases. The pll-out pin stays at values ​​from 2 to -2.
In refClockSyncCycles=1 mode, the pll-err pin always remains zero. The pll-out pin always remains zero.

In both modes, the ethercat command upload -p 0 -t uint16 0x1C32 0x01 returns 0x0002 2, on all axes, including the slave.

I tried changing the sync0Shift value to 500000 without any change.

At this point I'm thinking of changing the PC, I don't want the problem now to be the jitter of Debian Trixie, which is greater, at least double compared to Debian 10.

I'd like to point out that with this latest fix from Grandixximo, the pull-err value is hovering around zero, like Debian 10. While in previous versions the pull-err value was around 99200.
Furthermore, with the latest fix, the plug-out pin has a fluctuating value close to zero, while with previous versions it was always zero.