Advanced Search

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 5.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.

bonjour , 
je viens de passer de linux 2.5.4 de ma mortaiseuse a 2.9.5, le probleme, est que les signaus de spinbox ne passe plus .j 'ai lu qu il y avais un changement de pyton , j 'ai essayer plusieurs piset et changer post-gui halfile , mais rien ne chan,ge , pouvez vous m 'aider ?