Dann teste erstmal in Ruhe, und wenn 400W ausreichen meld dich hier. Dann finden wir schon eine Möglichkeit. Ich hab 2 ohne und 1 mit Bremse.

My configuration is a PrintNC (a dual Y ganged CNC machine) with a FlexiHAL board with a uFlexiNET Ethernet board, and I am connecting it directly with an Ethernet cable to a Dell Optiplex 780 , running the latest LinuxCNC image (linuxcnc_2.9.8-amd64.hybrid.iso).
I flashed the board with remora-eth, and uploaded the attached configuration (FlexiHAL-config.txt). I also attached the hal and ini files.
What happens is, that I can home and move X and Z correctly, but not Y. The gantry goes back to the endstops, and I can see the homing sequence almost completing successfully, but at the end, one side starts moving to the opposite direction, towards the front.
The wiring and driver setting are identical on both Y sides, and the same hardware works perfectly with grblHAL, so I don't think it's a wiring or driver issue.
Any help is greatly appreciated.

Hallo Sascha H.,

grundsätzlich habe ich Interesse daran!
Ich habe mir jetzt den 750-W-Motor mit Treiber bestellt, der ist auch gestern gekommen. Netzfilter und Encoder-Kabel mit Batterie fehlen noch (sind noch unterwegs).
Wenn ich demnächst etwas Zeit habe, möchte ich ihn in mein LinuxCNC einbinden und hoffe, dass ich dann ein paar Drehmomentwerte aus meiner Musteranlage bekomme, damit ich die Motoren abschätzen kann, die wirklich benötigt werden.

Wenn ich das weiß und 400 W ausreichend sein sollten, hätte ich Interesse daran.
Wie kann ich dich am besten erreichen? PN geht hier im Forum leider nicht.

Gruß Mücke

It looks very nice and promising, but where can I find more information about the hardware? I tried searching online but couldn't find any results.

I reflashed the default firmware and still same, none of SSR outputs work. It seems that I have to do some manual control for water pump.

Wenn 400W auch ausreichen, dann hätte ich noch kaum benutzte A6-EC übrig. Mit oder ohne Bremse und mit Batterie am Encoderkabel.

github.com/mika4128/liscio/tree/main
new trajectory/gcode compressor for the future trajectory planner, testers wanted, feed your gcode to it, check the SVG output

If you run qtdragon in debugging mode (-d) and run from a terminal or use debugging mode and look at the system log on the status page you should get more info on where qtdragon is looking to do it's checks when the INI MDI button fails.

What I still haven't been able to understand is why QTDragon in neither of its two versions can execute subroutines from MDI with o<XXXXX> call, while with AXIS it does execute them. I think, and I'm not wrong, that it's because QTDragon looks for those subroutines in some specific directory different from the one set in the INI in SUBRUTINE_PATH.

Can this image work with gpio pins?

Easiest way is to connect the main spindle PID-out signal to both stepgens (main and guide bush drives).  You can do the same for the drive enable signal.

Make sure to program both drives with the same input steps/rev.

If you want to be able to un-couple the guide bush motor for some reason, you can have an AND2 component between the PID signal and the bush stepgen which requires some other thing to be true (like a switch, button, or M-code enabled pin).

If you want a fault alarm in LCNC for the guide bush drive, you can add a misc-error and connect the bush drive alarm output.  See the MOTION component man page.
linuxcnc.org/docs/devel/html/man/man9/motion.9.html

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.