Advanced Search

Hey, is anyone doing hard stop homing? I'm not finding any combination of LinuxCNC + hard stop homing. Google is not my friend today. Llm claims to know everything about it but I'm not buying that. If google doesn't know about it then llm has got to be fabricating it.

I am ready to try coding a halcomp if it doesn't already exist. I just don't got time to reinvent the wheel if someone else has already done it.

I consider hard stop homing to be the least accurate version of homing, but in today's project it will be a lot better and cleaner than rigging up some homing switches. If I can attain 5mm repeatability I will be happy, but I am confident I can do better than that.

I caught the index signal with my oscilloscope! It is near the top end of the ram travel, a tiny little pulse. I think I still have the ram jogging up/dn too fast the mesa card isn't latching on it, possibly even to fast for the electronics in the sensor itself. I unbolted the sensor from the Y1 ram and moved it slow with my fingers and caught the ~200uS pulse visible in the second screenshot. The ram is still jogging open loop and way too fast for homing. Looks like I'm on track to close the loop, and try tuning it hydraulic servos and all.

Now that I understand how the index-enable signal is read/write and is latching (I disconnected it from joint.3.index-enable to make sure it's not clearing it before I get to see it.) my latching hal AND2 + OR2 wiring the other day was unnecessary.

Here you go

i put that. it just waits for something.
 

Edit: i got it. Just rename the file from arduino-connector to arduino with loadusr -W arduino and it works.

The real-time threads must be loaded before using any pin.

Put loadusr -W arduino-connector at end main hal file.

All LinuxCNC motion hardware is real time so as I said the only limitation is that the accuracy
of some operations like probing and homing without using index is limited to velocity *
servo thread period (usually 1 ms). This is typically not an issue because the final velocity can be quite low
as the distance covered by the final latch move is small.

On Mesa hardware, the stepgen is a digitally controlled rate generator. At ever servo thread
invocation (typically 1000 times a second),  LinuxCNC reads the current stepgen position
from the hardware and compares it to the actual commanded position and makes corrections in the rate 
to keep the step generation in sync with LinuxCNCs commanded position. This typically
keeps the external step generation within a small fraction of a step of the commanded position.
 

I would probably renumber the sserial channels so the 7I85 sserial channels start at 0 rather than 1

Flashing is safe as long as you have a recent mesaflash that supports the 7I96S

You could also use some threshold (> 200?) on  the fault count pin

You should also find out why you are getting sserial faults, in general these should never happen

I also think it's actually a bug if run is not cleared when all communication is lost and LinuxCNC
gives up

Hello, I'm new to the forum. I have spent the past year and a half building my own CNC mill that runs on LinuxCNC, and it is mostly done now. Except that I can't get it to finish a program because it keeps thinking that the limit switches have been triggered even though they haven't.

I built this mill from scratch. It is made entirely of aluminum plate and extrusions. It has NEMA23 closed loop steppers, SFU1204 ballscrews, HGH20CA linear rails, a 2.2kw 220v 3 phase spindle and 2.2kw VFD, a "5 axis" parallel port breakout board, a Dell OptiPlex 990 with a parallel port card and running LinuxCNC (obviously). For limit/home switches I have it set up to where one limit switch doubles as a home switch, and all six switches are normally closed and in series all going to one input pin. The limit switches are generic micro switches, and the limit/home switches are Metrol CS067B. I have 24V running through the switches, so I'm using a 24v to 5v optocoupler board to bring the signal down to 5v for the breakout board. The Metrol switch wires are not shielded, but because they cost $67 a piece, I don't want to mess with that. The wires for the other switches are shielded.

This is what happens when I try to run a program: I home the machine, import the program into Axis, hit run, and it could be 1, 5, or 60 seconds later that it suddenly stops the machine because a limit switch was supposedly hit. It doesn't seem to happen consistently. I originally had the VFD next to the other electronics in a copper mesh cage, but ended up making a sheet metal box for it and moving it away (and took the spindle cable out of the cable chain that also held other wires). I thought that would prevent any EMI from interfering with the other electronics. But that didn't fix it. I have narrowed it down to an issue between the spindle/VFD and the breakout board. I can run a program perfectly fine with everything on except for the spindle/VFD, so it can't be the steppers or drivers. I have tried running 24v directly to the optocoupler board, bypassing the switches, but it still triggers. I have tried completely bypassing the limit switch circuit by jumping the input pin on the breakout board to ground, and it still triggers. I have spent hours researching this, and I have tried almost everything. I have my VFD in a Faraday cage. I'm using a shielded spindle cable with the shielding grounded at both ends. I have the signal wires shielded and grounded. I don't know what I'm doing wrong.

I have spent weeks trying to diagnose this, and now I am only more confused. Part of the problem is that I'm only 18 and I'm not an electrical engineer (I'm not even a mechanical engineer yet!), and I'm learning a lot of this for the first time. I have run out of things to try, and I would really appreciate any help I can get. Thank you in advance!

Got LinuxCNC built. Running latency test. Tried running Axis and QtDragon, gui just crashes, need to spend a little more time on it, maybe tomorrow. I think I got some missing dependencies going on.

Hi. 
I copied the arduino-connector.py to the usr/bin/ as arduino-connector
Run the terminal with halrun and then with loadusr arduino-connector, it load next i try show pin, all good.
I run linuxcnc and go to Halshow and input loadusr arduino-connector and it loads.
I can see the pins, and net signals to a external encoder or input pins, works great.
The problem is when i put the command loadusr arduino-connector in custom.hal but i get the error  pin arduino.din.4 is not found. (the pin is active in show pin command)
I did try loadusr python3 arduino-connector or loadusr python3 /usr/bin/arduino-connector but no change.
If i try loadusr -W arduino-connector it loads but after that its waiting for something.
I use Debian 10 with kernel 4.19.195 RTAI with python 3.7.3

Edit: well the pins are not loaded. i put a show pin in the custom.hal after the loadusr arduino-connector and it shows no pin.

might help to post your 'motion_control_test.ui'

bump

Hello PCW,

LinuxCNC does report an error as a popup, but I was wondering if there is a way to force a fault. There doesn't seem to be any pins that can easily be used.

The main way to do it that I see is checking the state of the hm2_7i96s.0.sserial.port-0.port_state pin and generating a misc fault if it is no longer in the run state (which appears to be 0x3).

Is there a cleaner way of doing that? The only 7i84 pins in HAL that show up are just I/O.

I've attached a txt file listing all of the mesa pins.




 

Altaros make a relatively inexpensive 8-station tool changer for CNC lathes. www.altaros.cz/accessories/157-automatic...ead-for-8-tools.html  I don't have one to test with, but I have written a driver for it (as a user space Python HAL component). 

I needed to add .py to the end of the filename to upload it. This should be removed to install the file


To install the component, place the "altaros_ath" file in the same directory as the INI file of the LinuxCNC config being run, and make it executable. (chmod +x altaros_ath)