Advanced Search

If none of them work, the card has likely been damaged, possibly by
driving an inductive load with no flyback diode, or a problem with the
5V supply.

Likely damaged components are U9 (74ACT540) and possible 1 or more
MOSFETs (Q1,Q2,Q3,Q5 =  PMN55ENE or equiv)

Also just to make sure that it's not a homemade firmware issue, you might
re-write the firmware to the default 7I96S firmware:

mesaflash --device 7I96S --addr 10.10.10.10 --write 7i96s_d.bin  --reload

(replace 10.10.10.10 with 192.168.1.121 if your card is jumpered that way)
 

No, none of them work. So it seems, that I can't get my water pump to work with Mesa.

This is the second part to my plan of converting my taig ball screw lathe to a Swiss-style lathe. I need to sync both the main drive servo (Which is on the new Z axis BEHIND the taig headstock, and a second servo that rotates the guide bushing inside the headstock. (the native taig Z axis will be used for W offsets of gang tools). I know the best way to do so is mechanically but I think it would be too hard to get up and running and am hoping to get some results sooner. Anyway....


Do you all have ideas on the best way to do this? Right now I run any spindles on the lathe as step/gen instead of analog. Currently on my regular taig, my rotary encoder is on the 5C headstock shaft

My plan: Move the rotary encoder onto the drive servo so that it correctly shows the rotation of the bar stock itself. Then...
(1) Potentially try to split the rotary encoder signals - one to the linuxcnc mesa board, and the second directly into the encoder input on the slave servo driver
(2) Split the step/dir signals that normally go into the master but split them to go into the slave servo and just ensure my drive settings like PID loop is all identical (encoder stays on the main drive shaft of the master spindle and its signal goes solely to mesa)

Some notes:
- Tandem axis would not work for this I believe
- I am using a low resistance guide bushing, meaning it is easy to spin the stock through the guide bushing, so I suspect as long as the RPM's are relatively similar it should not cause a big issue like stock twisting or serious marring
- The motors I am using would be a master 1000W A2M-80SV03230 servo motor with S2SVD20 drive and a slave 400w servo motor of same type with driver S2SVD15 which will simply drive the headstock to rotate at the same speed as the stock (both are from RATTMOTOR)

yeah that sounds like you have some form of stacking going on maybe with tool length offsets maybe? i don't know, the main probe basic method work for repeatable holders, i tested it just yesterday while doing some work in the shop, so i know its not probe basic. I would investigate your tool setter subroutine and see what you have actually going on maybe.

I found this:

forum.linuxcnc.org/qtpyvcp/58735-probe-b...ing-no-tool-selected
and installed pyside-tools package, it's work! thanks.


Tim

m6 Toolchange by hand, with a fixed toolsetter. I am not sure, but it works fine as long as the tool has not much more length then the tool before. Example: a 4mm mill with a length of 25mm first, then a 6mm mill with 50mm length, bumm joint 2 (z) exceed positive limit, what makes me wonder, the cnc has a z range about 240mm, the workpiece is 45mm high. After the error, w
hen i go to the home position(not homing!), it works.

hello everyone:

I was installed the debian13+linuxcnc2.9.8 ISO image from linuxcnc.org. and installed qtpyvcp and probe basic used method below:
kcjengr.github.io/probe_basic/debian_13_...develop_install.html
but, it can't start 

 

Thank you

Tim

how are you setting the tool lengths?

The download links on the bottom of this page:
linuxcnc.org/downloads/
are a bit misleading. The top links link to bookworm packages, while the lower ones point to trixie.

The downloaded files don't have the release name in them. That confused me because the python versions etc... didn't fit. Took me a while to notice that I had the wrong packet.

If LinuxCNC is running and you have no watchdog bite (red LED on 7I96S)
and halcmd setp hm2_7i96s.0.ssr.00.out-00 true does not activate SSR0's LED,
Then its likely that the 7I96S has been damaged.

Do any SSR outputs work?

I'm aware of it. I have one error driving me nuts, i think it has nothing to do with probe basic, maybe you have an idea. The exceed joint 2 (it is z) positive error. Read all i could find about it, nothing helped. I don't see any reason for this error, it is always plenty of room to the positive limit, then if i go to the home position, it is working. In a bigger cnc job, this often stops the job when changing to a longer tool and i can start over. Very annoying.
Michael

I have spindle CW and CCW signals connected to out-04 and out-05. Both works fine.

I want control spindle water cooling with relay and Mesa output. I have connected relay to PB3 pins 13 and 14. When I try to control the relay, nothing happens and Mesa output led not switch on.
I bought cnc router used, so I'm not sure, what Mesa configuration I have. I have read Mesa's pinout and it shows HOSTMOT2 and I can find line
TB3-13,14              11   IOPort       SSR              0        Out-00          (Out)
If I try to control output by command "halcmd setp hm2_7i96s.0.ssr.00.out-00 true" and read state by command "halcmd show pin hm2_7i96s.0.ssr.00.out-00" state changed from false to true. Still, output led not lights up and relay not change the state.
I'm totally stucked with this and have no idea what could be wrong.
 

Hallo Martin

I am Otto, I also got a Knuth Mark Super CNC - Busy Trying to get running

I am battling throug a Re-install today of gplus 450

Just a Question - After Sorting out You Gplus 450 - Is It Stable and Working Now ??
My machine Original was windows 2000 - previous owner Installed Windows XP SP3 Buils 2600
(What are You Running - Windows Version ??)


Wishing You a Good Day

Regards Otto from Cape Town

 

It could work, after lots of testing, I think the noise papagno is experiencing is mostly caused by the servo thread spiking above 1ms, so widening the cycle time could certainly help.
The main reason why Debian 10 does not grind in his case, is mostly because Debian 10 with kernel 4.19 gets lower latency, and this is pretty universal IMO, Debian 13 Kernel 6.12 has overall worse latency, although with system setup tooling that you can get from Rodw, the latency can be improved a lot.
There is only one slight latency regression with the new linuxcnc-ethercat, the modulo operation that I currently must use to do phasing is causing slightly more latency on the servo-thread, and I want to fix that, I am preparing patches to modify Linuxcnc to expose a function to allow proper native phasing, so that I can lighten up linuxcnc-ethercat to match the older performance for both positive and negative refClockSyncCycles modes. Previously I was undecided if going that path, or using Sascha Ittner method/hack of moving ecrt_master_application_time out of lcec_main, but I found that Sascha's hack causes issues with papagno's hardware, I tried this with built binaries from Sittner repo, with refClockSyncCycles -1 nothing would move, therefore I am now convinced the proper path is to have a native linuxcnc phasing function, this will require updating both linuxcnc, and rebuilding linuxcnc-ethercat against the new linuxcnc-dev headers, hopefully the patches will be ready and merged soon, will try to keep you guys updated on the progress here, I know there are people following in the background

Yes I didn't update qtdragon_hd yet. I didn't realize that is what you were using.