Advanced Search

ok, i'm a bit confused, maybe something is wrong but mostly what i see looks ok. you said your z range is Z0 to Z-6.3, but i see your earlier post referencing Z=-7.4953 something doesn't seem to be adding up.

is this a bt30 or is30/20 machine with repeatable holders? or is it an er collet type machine?

i'm trying to figure out where the issue is. maybe a detail written walk through r a video would be easier, i don't see anything wrong off the top of my head but without seeing dro's at time of command or active work offsets etc. triggering a limit isn't hard to do. especially if you have an offset set super close to min or max travel etc.

im not getting any of that behavior nor other reports so i have to assume user error, not to be taken as picking on you, just trying to identify where the issue becomes the issue.

if you are suing non repeatable holders, it may be better to use that type of tool touch off. it basically resets the work coordinate system for each tool so it cuts at the same height as the previous tool without storing tool offsets in the table. this tends to work better for er collet type machines and i think there is a really good touchoff routine by another member on here maybe tootall18 from memory? but that is only if you are an er collet. if you have repeatable holders like bt or iso style then the stock touch off is the correct one to use.

grossm5000 wrote:

Anybody have any ideas??

Yes:

PCW wrote:

I would check the 7I77s 5V supply, my guess is that it droops
when you connect the MPGs, either from a wiring error or
too much current.

If you have the encoder power wires reversed, that will for sure make the voltage drop and cause the failure.
But, some parallel cables have so thin wires inside that might also be the reason for the failure.
My advice:
-set Mesa boards for each to have it's own power supply
-find a good quality USB cable and cut the USB-whatever connector leaving only USB-A side and the wire, wire it to Mesa 7i77 as the power supply
-do NOT do this before checking the wiring and making sure it is correct.

I have 5v power from the computer. I unplugged ALL the terminals on the 7i77 TB3,4,5,7,8) reinstalled LinuxCNC (worried about kernel issues) and the darn thing still dumps me when I launch the program. 

I feel like I’m getting to the limit of the things I can do to make this work. Any help is welcomed. Anybody have any ideas??

aikiaviator wrote:

I read somewhere about a need to set the config of the THCAD2 into the settings of the Software based on a frequency... Cant remember where I saw that but the config setting are my main concern at the moment. 
 

The thcad is a voltage to frequency converter. It has individual calibration frequencies at 0 volts and max scale volts (10v or 5v) on a sticker on the board. you enter this data into the QTplasmac interface. Read the docs and  it is well explained.

After another glance, 17.3MHz !!!
That is the realm of radio frequencies, not something you find on a machine.... usually.

Hi yes, I have a cut chart for the cutter. BUT it does not specify a variable air pressure chat such as the one you have presented. So I think this could be useful. Thanks.

Separately, I was concerned about the configuration settings: mostly about the arc voltage etc... I read somewhere about a need to set the config of the THCAD2 into the settings of the Software based on a frequency... Cant remember where I saw that but the config setting are my main concern at the moment. The other thickness settings are in line with the cut charts for the machine.

That being said, I have literally never used a cutter, so have zero experience on how this should be set up. I live in Melb, AU. So if anyone local, would put on beers coffee or whatever for some localised help. 

Thanks Tommylight.
-Set up the THC, any fine tuning without it is useless when THC is active.
Ok. Will note

-25A for 5mm thick is way to low, roughly 10A/mm is OK
Yes this is already set to 40A in the 5mm profile

-with working THC, you need to fine tune air pressure (exclusively while the air is ON), voltage=cut height, feed rate
Ok. This I have definitely NOT looked at. Will do. Thanks.

-cut quality will vary based on air moisture, material being cut, nozzle type and wear, so use new nozzle for fine tuning and after you have things working properly
I have a three stage Breathing Dryer rig from when painting, + a standard dryer, so dry air should not be a problem. But the rest of it I will need to work through. Thanks.

My main concern was the settings in the Configuration setting, specifically arc voltage setting etc... Any thoughts on this? Do you have some that you may be using?

Yup, that's noise. Your scope settings are so "zoomed in" in time and voltage you probably can't see the real signals.

• Set your scope's Y axis (voltage) range to more like 1V/division. More if the signals are (eg) 24V.
• Set a trigger on a rising or falling edge, with a threshold of something in the middle of your signal voltage range. Eg, if it's a 5V system, set the trigger at 3V or some such.
• Change your X axis (time) to much longer. This depends on how fast you're moving the motor, but 25 ns is way too fast to see the signals you probably care about. Something more in the 100 us or 1 ms range probably makes much more sense.

If you do the above, you'll probably see step/direction signals, or quadrature, or something. Either way, it's very likely something LinuxCNC supports "out of the box". Engineers are lazy and generally don't invent new protocols if they don't have to

Thank you for all of your help Peter, I have finished all of my testing now the conclusion is clear.

Not able to help here but this is a continuation of the deprecation of Python 2.7 back when Debian Bullseye (v 11) was released. You need to convert your handler to Python 3. 

Inside the Basic.hal file, you have trivkins called twice as noted in the error report
"trivkins: already exists"

Update:
i have copied the "working" fies from page 1 into my axis.sim folder, removed the date in their names and put the Basic.hal to be called in the axis.ini file. now the axis.sim does not start and i get this error log: 
Print file information:
RUN_IN_PLACE=no
LINUXCNC_DIR=
LINUXCNC_BIN_DIR=/usr/bin
LINUXCNC_TCL_DIR=/usr/lib/tcltk/linuxcnc
LINUXCNC_SCRIPT_DIR=
LINUXCNC_RTLIB_DIR=/usr/lib/linuxcnc/modules
LINUXCNC_CONFIG_DIR=
LINUXCNC_LANG_DIR=/usr/lib/tcltk/linuxcnc/msgs
INIVAR=inivar
HALCMD=halcmd
LINUXCNC_EMCSH=/usr/bin/wish8.6
LINUXCNC - 2.9.8
Machine configuration directory is '/home/christian/linuxcnc/configs/sim.axis'
Machine configuration file is 'axis.ini'
INIFILE=/home/christian/linuxcnc/configs/sim.axis/axis.ini
VERSION=1.1
PARAMETER_FILE=sim.var
TPMOD=
HOMEMOD=
TASK=milltask
HALUI=halui
DISPLAY=axis
COORDINATES=X Y Z
KINEMATICS=trivkins
Starting LinuxCNC...
Starting LinuxCNC server program: linuxcncsvr
Loading Real Time OS, RTAPI, and HAL_LIB modules
Starting LinuxCNC IO program: io
Starting HAL User Interface program: halui
linuxcnc TPMOD=tpmod HOMEMOD=homemod EMCMOT=motmod
Found file(lib): /usr/share/linuxcnc/hallib/core_sim.hal
Found file(lib): /usr/share/linuxcnc/hallib/sim_spindle_encoder.hal
Found file(lib): /usr/share/linuxcnc/hallib/axis_manualtoolchange.hal
Found file(lib): /usr/share/linuxcnc/hallib/simulated_home.hal
Found file(lib): /usr/share/linuxcnc/hallib/check_xyz_constraints.hal
Found file(REL): ./cooling.hal
Found file(REL): ./Basic.hal
Shutting down and cleaning up LinuxCNC...
Removing HAL_LIB, RTAPI, and Real Time OS modules
Removing NML shared memory segments

Debug file information:
Note: Using POSIX realtime
trivkins: already exists
./Basic.hal:3: waitpid failed /usr/bin/rtapi_app trivkins
./Basic.hal:3: /usr/bin/rtapi_app exited without becoming ready
./Basic.hal:3: insmod for trivkins failed, returned -1
2381
Stopping realtime threads
Unloading hal components
Note: Using POSIX realtime

Hi maruf1777,

I’m an engineer with Teknic and I came across your thread. There are a lot of good recommendations from other users, and it looks like you’ve got some solid next steps to test. If you want direct help from Teknic, feel free to contact us at 585‑784‑7454 or www.teknic.com/contact/ and one of our engineers will be happy to assist.

Also to build on dbtayl’s quadrature note: when ClearPath is set to quadrature input, it treats each edge transition on the A and B signals as a count. So if you keep the same command resolution (counts/rev), the required signal rate on each line is actually 1/4 the pulse frequency you'd need when using step & direction. If your Mesa card supports quadrature output, you can set ClearPath’s Input Format to Quadrature in ClearPath‑MSP, which can help if you’re running into pulse‑rate limits or signal‑integrity issues.

Best regards,
Nick D. - Teknic Servo Systems Engineer

Stimmt das ist Pflicht 

At 75 and 185mVPP, those look like noise, not a signal of any kind, although the first one is weirdly clean sinusoidal.