Advanced Search

Have this Pendant:
www.amazon.com/dp/B01E6VTZHC

Wiring as below (see attached image).


I have inputs 0-15 available on the 7c80 (have TB02.0 connected to GND)

Looks like Black, Black/white, Black/Orange can all be tied together and connected to GND
Black/Green and Red tied together and connected to 5v+ (power and LED+)
Yellow to an input pin (X)
Yellow/Black to an input pin (Y)
Brown to an input pin (Z)
Black/Brown to an input pin (4th)
Grey to an input pin (spd X1)
Black/Grey to an input pin (spd X10)
Orange to an input pin (spd X100)

I'm not sure on how to wire the A+,B+ and A-,B- for the dial

Looking at this post, would it make sense to use the Encoder (TB4) header for A/B?
forum.linuxcnc.org/27-driver-boards/53986-7i96-mpg-encoder-a-b 

Not sure on how i should wire the E-Stop, should E-Stop be controlling a relay for the psu/vfd input power (220v in this case)?

New installation of Linux2.9.3 on a Lenovo Yoga

I followed the tommylight Ethernet setup for 7i9x and can't seem to get Linux to recognize the 7i96s

Power LED and the green user LED's change status, I'm getting a swirly network icon up in the top right that I assume is indicating it's trying to connect.

Settings and error are as shown in attached.

I also tried moving the jumpers from the default 192.168.1.121 to EEPROM and same result except can't connect to 10.10.10.11

Suggestions?



 

Yes, 200 RPM

You have set the host PC's IP address to the Mesa cards address.
This will not work, all IP addresses on a network must be different.

I would suggest setting the host IP address to 10.10.10.100
(and the 7I97 to 10.10.10.10)

Well, naturally, that looks normal  (no exponential/varying thread pitch)
Was that at 200 RPM?

Hi
Im new to linux cnc and linux in general. coding and programming is not my strengths so im looking for some help with my retrofit.
I have a maho mh800w which has a philips 523 controller. This has died multiple times and i have been lucky enough to repair it until now as the cpu board or graphics board has gone.
Time for a retrofit as im sick of drip feeding programs.
RotarySMP has been kind enough to forward on all his information which has been great to cross reference philips 432/532 wiring diagrams.

Hardware so far
hp elitedesk 800 g2
Elo touch screen
Heidenhain te425b panel
3 heidenhain 602d's
Mesa 7i97t, 7i84, 7i73, ordered 7i74+7i73

Warning i will probably be asking simple questions but i dont know what i dont know.

1st problem
I cant get a basic configuration to open. this is a basic config that tommy light shared in some thread.
Ive tried 10.10.10.10 and 192.168.1.121 with 7i97t and im lost.


ive done the mesa ethernet card manual as ive an intel Ethernet chip.
 This file describes the network interfaces available on your system
# and how to activate them. For more information, see interfaces(5).#

#source /etc/network/interfaces.d/*
auto lo
iface lo inet loopback

auto eno1
iface eno1 inet static
address 192.168.1.121
netmask 255.255.255.0
hardware-irq-coalesce-rx-usecs 0

Ive done

maho@maho:~$ linuxcnc
LINUXCNC - 2.9.3
Machine configuration directory is '/home/maho/linuxcnc/configs/my_LinuxCNC_machine/backups/basic7i97_2024-06-10'
Machine configuration file is 'basic7i97.ini'
Starting LinuxCNC...
libnml/buffer/shmem.cc 320: Shared memory buffers toolCmd and toolCmd may conflict. (key=1004(0x3EC))
libnml/buffer/shmem.cc 320: Shared memory buffers toolSts and toolSts may conflict. (key=1005(0x3ED))
libnml/buffer/shmem.cc 320: Shared memory buffers emcError and emcError may conflict. (key=1003(0x3EB))
emc/iotask/ioControl.cc 786: can't load tool table.
linuxcnc TPMOD=tpmod HOMEMOD=homemod EMCMOT=motmod
Note: Using POSIX realtime
Found file(REL): ./basic7i97.hal
hm2: loading Mesa HostMot2 driver version 0.15
hm2_eth: loading Mesa AnyIO HostMot2 ethernet driver version 0.2
hm2_eth: ERROR: Could not retrieve hardware address (MAC) of 192.168.1.121  encoders=6 num_pwmgens=6 num_stepgens=0 sserial_port_0=00xxxxxx: Connection refused
hm2_eth: rtapi_app_main: Connection refused (-111)
./basic7i97.hal:9: waitpid failed /usr/bin/rtapi_app hm2_eth
./basic7i97.hal:9: /usr/bin/rtapi_app exited without becoming ready
./basic7i97.hal:9: insmod for hm2_eth failed, returned -1
Shutting down and cleaning up LinuxCNC...
Running HAL shutdown script
Could not open command file 'shutdown.hal'
hm2: unloading
Note: Using POSIX realtime
LinuxCNC terminated with an error.  You can find more information in the log:
    /home/maho/linuxcnc_debug.txt
and
    /home/maho/linuxcnc_print.txt
as well as in the output of the shell command 'dmesg' and in the terminal


Please help. Paul


 

Die PC address ist beim 192.168.1.121 eingeshtelt, das muss etwas anderes sein, wie 192.168.1.100 oder 192.168.1.111

Könnte das das Problem sein?
hm2_eth: ERROR: Could not retrieve hardware address (MAC) of 192.168.1.121: Connection refused

Wenn hm2_eth die Mesa Karte ist...

PCW wrote:

The spindle needs A and Index or A/B and index.

Note that the MPG encoder inputs on TB3 are fairly
slow so may not be suitable for axis scales.
 

Hmmm....

Lot's of questions and limited knowledge on my side.

Do you know if the isolated encoder inputs are fairly slow because of the opto's or is it the sample speed of those inputs by the FPGA?
If I instead use the inputs available on the expansion connector:
a) Are they fast enough to keep up with the scale data?
b) How would I configure those inputs as quadrature inputs so I can route the results to the DRO display in Linux? Can I do this in HAL?
c) If there is not a way to configure those pairs of inputs as quadrature inputs?

I suppose I could decode the quadrature signals by using a flip-flop in HAL to give direction and then just count pulses for the count, not sure if HAL is fast enough to not miss the counts especially when I do a change of direction? I have a vague image in my mind of a HAL based up-down counter with the flip-flop driving the direction and say the A signal driving the counter clock, hopefully such a counter exists?



Not sure if there is any protection on the expansion pins (I'm guessing direct to FPGA), so either I make a fast isolator board (assuming the inputs are actually scanned quickly) or I take ESD precautions when connecting and just risk it. The DRO pickups will be powered via the 5V on the 7i96s so they will not be powered when the 7i96s is not so will not be driving the unprotected pins when the Mesa board is not energized. Comments/Suggestions welcome.

Here's the plot you requested:
 

This cut is slightly different from the previous ones, as it has a tapered exit for the thread.

The comment about the non-constant exponential threading velocity got me thinking about the threads I cut. I made six. On about half of them, I had to rerun the program because there were tight spots in the threads and I could not easily get the nut on. Running the program a second time, at the same speed, still resulted in some cutting near the bottom of the threads.

I laid the treads up against a 8TPI tap. About half of them look OK, and the tap will sit in the threads without wobbling. The other half, the tap wobbles, or see-saws. Here's a photo of one of those. You can see that the tap is touching on the left side of the thread on one end, and the right side on the other. The reason some of them are OK might be because they were run twice. I don't recall which are which.

 

The spindle needs A and Index or A/B and index.

Note that the MPG encoder inputs on TB3 are fairly
slow so may not be suitable for axis scales.

Hallo, 

nach einigen Änderungen zur Verbesserung der Latenz startet Linux CNC leider nicht mehr. Die Fehlermeldung habe ich im Anhang beigefügt. 

Folgender Hintergrund:
Linux CNC läuft auf einem Lenovo ThinkCentre M91p. Die Ansteuerung der Maschine XXYZ erfolgt über eine Mesa 7i96s. 
Das ganze hat soweit auch gut funktioniert. Beim ersten größeren Job habe ich jedoch die Fehlermeldungen "unexpected realtime delay on task 0 with period 2 000 000 " und "hm2/hm2-7i96s.0: Watchdog has bit ... " erhalten.

Daraufhin habe ich erneut einen Latenztest gemacht der über Stunden auch völlig unauffällig war aber irgendwann kam dann eine extreme Abweichung von 1 300 000 ns.
Gibt es eine Möglichkeit die Ursache zu lokalisieren? 

Ich habe dann versucht mit den Hinweisen aus dem Video von Talla83 die Latenz zu verbessern. Die sehr seltenen Abweichungen der Latenzmessung habe ich immer noch dazu kommt Linux CNC startet nicht mehr...

Testweise habe ich eine neue Konfiguration erstellt (reine Maschine ohne jegliche Einstellungen) auch diese startet nicht. 
Kann mir jemand helfen? 


Vielen Dank

Grüße
Erwin 

 

Take a look at this plot:

 

There is something pathological here as the Z velocity is never constant,
having a slow exponential rise, so the thread does not have a constant pitch.
This is not due to the acceleration constraints but either a hardware/encoder
bug or bug in the threading code.

 This is why I asked for a plot of the encoder position/velocity, to determine if this
is a LinuxCNC threading bug or hal/encoder bug.


 

cmorley wrote:

I would think (in general) encoder resolution, axis acceleration and trajectory servo update rate all have potential to improve the tracking.

but changing the speed significantly is not going to track in the same place with the current code. I wouldn't think it would be hard to code absolute position tracking, but I bet it has some corner cases.
 

If that's the case, it's crazy and broken as any speed variation would  cause threading inaccuracies.
The time to get into sync with spindle rotation can of course vary, but the target Z position must be
synchronized to the spindle angle for the actual cutting path (or it's not spindle synchronized motion at all)