Advanced Search

You don't do estop in the component.
Have an ouput pin flag for this condition and connect that to machine estop pin if you like to,

Hallo, bei mir ist die Situation ähnlich. Ich habe neu eine gebrauchte High Z S-1000/T mit einer AMB FME-1050 und werde die vermutlich auf eine China-Spindel mit 2.2kw oder 3.5kw umrüsten.

Der Nachteil der Bürstenmotoren ist, dass sie weniger effizient sind und mehr Wartung brauchen. Eine China-Spindel wird höchstwahrscheinlich mehr Drehmoment haben.

@Andrax
I think we’re actually very close in spirit here, but there is one important distinction worth making.In the current code, the triggers for global_estop() are:

• drive reports error, or
• start watchdog timeout, or
• run watchdog timeout.

All of these indicate a sequence / handshake failure (homing didn’t start in time, didn’t finish in time, or the drive signaled a fault). They are not, by themselves, evidence of uncontrolled or runaway motion.So from an industrial point of view, this logic is more a process watchdog / fault handling than a true safety watchdog. Using a global E-Stop here is a very conservative choice (and understandable for a “fail-safe” CNC-style approach), but conceptually it mixes two layers:

• Fault handling: homing failed, timeout, drive error → abort sequence, raise alarm, inhibit motion.
• Safety / E-Stop: hazardous or potentially uncontrolled motion → immediate safety stop (usually hardware/ STO).

That’s why I was suggesting that most of these cases could be handled as axis/sequence faults rather than a global E-Stop, unless there is real evidence of dangerous or uncontrolled motion (e.g. runaway, loss of feedback, velocity growing when it shouldn’t, etc.).So the current logic is consistent as a conservative “stop everything on any homing failure”, but the triggers themselves are not proof of uncontrolled motion — they are proof that the homing sequence didn’t progress as expected.

To square add HOME_OFFSET to your ini. If you are 2mm out of square, the difference in this value needs to be 2mm

You  might do a halscope plot of both limit switches and both joint positions
when homed to get a better idea of whats going on.

chatgpt has a lot to learn. This is the official home comp template
github.com/LinuxCNC/linuxcnc/blob/master...onents/homecomp.comp
these are the pins which are added to joint.N but you can add others
 hal_bit_t *request_custom_homing; // input  requests custom homing
 hal_bit_t *is_custom_homing;      // output verifies custom homing

Andrax, the best way to learn C code is to read it as you understand basic control mechnisms

Crumbs I was sure that the angle used in M19, was the angle after an index pulse, but can see now its after the enable edge.

The spindle position after an index pulse is the angle relative to the index pulse, not the enable.
The enable arms the hardware to detect the index and when index has  been detected by the
hardware, signal the driver that index has been detected. The counter hardware also either latches
the count at index (Mesa hardware does this) or clears  the count at index so that the spindle position
is set to 0 at the index position.

Thank you for getting back to me. That had already been changed in the original file but I forgot to change it in what I posted online. It still has the same problem. Currently it is on joint 2. The constant homing issue has left the gantry a little out of square. It seems like whichever side is closer at the start has the problem

Both joints of a gantry need negative home sequence numbers,
but your ini file has a negative and a positive:

[JOINT_1]

HOME_SEQUENCE = -3


[JOINT_2]

HOME_SEQUENCE = 3

Hello, I finnally got my cnc plasma table running been a little over a year in the making. Very thankful for all the people on this forum who helped me get it going such as Tommylight and Rodw. With this being said im not perfectly happy with the qtplasmac interface. It is light years ahead of mach 3 but still missing some. From my understanding the way it works is the qt takes over the Z axis entirely and automaticly inputs Lead ins and feeds from the material specs, Its like 70% of the way to being a cam software in itself. This kindof makes a mess if you want to use sheet cam or something similar.  you will have options double up that have to be over ridden, aswell as theres not really a great way to run sheetcam via linux as far a i know. So I am embarking on the wild journey of creating a open source cad/cam intergration into qtplasmac. I think with the modern advancements of ai I can have this project shipped in a few weekends. My qeustion for everyone on this forum is what essential features would you like to see? what improvements could be made? My goal is to give a little back to the community and make my software free/opensource or if it turns into a massive project make it so cheap that it can be sold on a one time very minimal fee to cover dev costs with no encryption so pirating is easy for anyone who cant pay the cost. 

So in the meanwhile, without working UI I tried to test comms with halcmd.

Does
4 bit IN TRUE remora.SPI-enable
4 bit IN TRUE remora.SPI-reset
4 bit OUT TRUE remora.SPI-status

actually mean there was some comms? UART doesnt show anything though.

If it's open loop, the question becomes what is changing the analog out command?

(bottom trace second plot)

Hi - I've gotten Linuxcnc to work well on several machines but each time the machine wasn't constructed with enough precision to make it reliably work the way I wanted.  On this machine I finally built it the way I should have.  I used the files from my old machine and adapted them to this machine If something is commented out it is because I haven't got to that yet.  The machine moves great and the X and Z axis move and home really good.  The Y axis moves good but I can't get it to home properly. If things are set up so that each axis has a pnp sensor on side will respond to the sensor but the other side will turn off the led acknowledging it should home but it keeps moving towards the sensor.  If I tie both sides to a single side it works as expected.  This is fine but it prevents squaring.  I've included my files so maybe somebody could see where I've gone wrong.

Peter,
No its open loop. I've got all the gains at zero bar FF0=1.
I do have an encoder though.

Not really sure whats going on now as I run into segfaults. I havent changed a thing on linuxcnc side, i just changed the config.txt on the SD Card

line 977: 2610 Segmentation fault $EMCDISPLAY -ini "$INIFILE" $EMCDISPLAYARGS $EXTRA_ARGS

Before that I haven't seen anything in the terminal or anywhere, thats why I'm a bit puzzled. Yes I compiled it from main branch, using OS6 Version for the Firmware and likewise for the hal component.

Is there a way to just test it with the halcmd? I tried loading the remora component, but struggle beyond. Show pins shows no active session.

Both the debug file and the regular logfile are basically empty with no specifics concerning the error.

Thanks!