Advanced Search

Sorry for my late reply.

I have tested today without any G-Code loaded. The issue remains.
As far as I am aware, I am not calling any special subroutine. Just the default feature from QtPlasmac.
What I've noticed is, that I am using the HAL-Pin plasmac:laser-on instead of qtplasmac.laser_on from the QtPlasmac users guide. I was simply unable to get it to work with qtplasmac.laser_on.

Ich habe es nun selbst rausbekommen.
Der entsprechende Teil muss so aussehen, dann funktioniert es:

Hello!
I am looking for a CNC system with which I can practise programming by hand. Preferably with a GUI that allows operation like on the machine.

It should not only work as a machine controller but also as an offline system on the computer.

I am also interested in whether the current Linuxcnc is compatible with Pal, Sinumeric and / or Heidenhain.

Kind regards R.Lehmeier


Translated with DeepL.com (free version)

I got the Anilam controller working. It's antiquated, at least as far as I'm concerned; sneaker net file transfer via very slow USB-floppy emulator. I'll run with it for a while before spending any more money. Thanks!

Welcome to the dark side!

So I made a rebuilt config, and can see what went wrong.
The pins were setup correctly. but maybe looks odd, because I have had to use encoder inputs as my switches are 5volt devices.
# --- MIN-X ---
net min-x <= hm2_7i92.0.encoder.03.input-a

# --- MAX-X ---
net max-x <= hm2_7i92.0.encoder.03.input-b

# --- MIN-Y ---   (The index pulses are inverted, so the NOT function reverses that.)
net my-input-signal-1 <= not.0.in hm2_7i92.0.encoder.03.input-index
net min-y => not.0.out

# --- MAX-Y ---
net max-y <= hm2_7i92.0.encoder.04.input-a

# --- MIN-Z --- THIS IS SPINDLE EXTENDED ie DOWN limit
net min-z <= hm2_7i92.0.encoder.04.input-b

# --- MAX-Z --- THIS IS SPINDLE FULLY HOME ie UP limit
net my-input-signal-2 <= not.1.in hm2_7i92.0.encoder.04.input-index
net max-z => not.1.out

Mess up was that all the axes, had a similar mistake. Had only min terms in all three places
Putting the max terms as follows has fixed it.

net min-x => joint.0.home-sw-in
net min-x => joint.0.neg-lim-sw-in
net max-x => joint.0.pos-lim-sw-in

X and Y home on the min end, so need to be told, and also that there is a switch at the other end. (Had min there too instead of max.)

Z homes at the max end, which is fully UP
net min-z => joint.2.neg-lim-sw-in
net max-z => joint.2.pos-lim-sw-in
net max-z => joint.2.home-sw-in

Homing all good now, Thanks

Context:
I want to use Linuxcnc for a Ultra-Precision machine.
For that i need Linuxcnc to tell my drives (via Ethercat) the waypoints with high resolution.
I can get 0.5 nanometer resolution out of the Ethercat bus with the 32bit Integer format at the travels that i need. Which is sufficient.

Now as for my question:
From what i gather the path planner and everything works in single-precision floats.
Doing the math on that at 10mm and 500mm positions tells me the resolution between bits of the float number is not enough.
10mm/2^24=0.59nm
500mm/2^24 = 29.80nm

I dont want to waste that much precision in my control for no reason (plus having to convert to the scaled integer value).

Is there a way to change that to double precision floats (64bit) without having to rewrite the whole control?
Also feel free to tell me that my math is wrong^^

Leo
 

when it becomes merged there will be some notes, it will be a pretty big update announcement.

Yes, I think its a good idea and something I have suggested a while ago.
Especially for multi-stage logic, simply connecting pin to pin makes more
sense.

I did indeed modify JOINT_N_SCALE to match the drive configuration and the value in the INI file. and it works fine now. The axis moves exactly with the commanded value. Changing the BASE_PERIOD value to 10000 in the firmware also increases the speed without the joint tracking error occurring.
The only drawback is that if one modifies the STEP_SCALE parameter in the drive, the firmware would necessarily have to be recompiled. That is why it seems like a good idea to remove these parameters from the firmware so that they can be modified at any time.

My first guess is that the sserial channels on the 7I74 are not enabled in the hal file
(with a sserial_port_1=00000000 stanza in the hm2_pci driver loadrt line)

Yes, 7I96/7I96S TB3 pin 12 is the input common.
Isolated inputs accept +-5 to +-36V signals relative to input common.

If you connect +24V to input common, the inputs will be activated
when grounded (connected to the 24V negative output) This
is the normal way to setup the input for NPN sensors
(or switches with a common ground)

Thank you so much for your help, your video helped a lot, I was able to flash on Stlink V2, but how do I install and use pyqcd, I didn't find anything that helped me, I could explain to me, or point someone who has already asked this question to see what He did1

Hello,

I am new to the CNC world, and would like to convert my small-ish lathe to CNC.
I think motors with around 2Nm for Z and around 0.6Nm for X will be sufficient, based on some preliminary measurements. For X I am constrained to Nema 17 size to be able to integrate them well.
For I/O and the spindle encoder, I would like to use a Raspberrry Pi and Beckhoff EtherCAT terminals, which I have already gotten to work (thanks for all the great ressources on here!). I would also like to use EtherCAT-connected drives for the axis (and maybe later the spindle), though I am unsure, which path to take there.

Initially, I was looking at closed-loop stepper drivers such as the Rtelligent ECT60 or the Lichuan CL3-E57H , which close the loop on the driver. But then I also found the Beckhoff stepper terminals  EL7041 and  EL7047 , which would make integration quite elegant as I am already using other Beckhoff terminals. With these however, I am not quite sure if they support closing the loop on the driver. The EL7041 manual mentions some closed-loop control aspects (differing between the standard and the -1000 model), but I don't fully understand what it actually can and can't do. The EL7047 supports closed loop in conjunction with FOC, but it is officially only supported with Beckhoff motors and requires them to be unloaded on startup for referencing. I could not find out if non-FOC closed-loop operation similar to the ECT60 or CL3-E57H is possible as well.
What approach would you recommend here?

In general (e.g. if the Beckhoff drivers can only act as open loop drivers with encoder interfaces), is it advisable close the loop in LinuxCNC when using such an EtherCAT based setup without any FPGA for low level control?

Another option would be AC servo drives (probably the  Lichuan ones due to their comparable cost), at least for the Z axis as I haven't found a Nema 17 sized option that would fit X. These would probably provide better performance, but seem more complex to set up and tune.
What do you think about this alternative?

I am looking forward to your comments, and hope the questions are specific enough. Please let me know if any details are missing.

Best Regards
Daniel

I think I found source of LINUXCNC_CONFIG_PATH:

github.com/LinuxCNC/linuxcnc/blob/ceb434...rc/configure.ac#L702
github.com/LinuxCNC/linuxcnc/blob/ceb434...rc/configure.ac#L724

But I don't know if it will help me in any way.

A friend advised me that it might help if I added the following to pncconf.py:Unfortunately os.environ does not contain 'LINUXCNC_CONFIG_PATH'