Advanced Search

Yes, the account is easy, but posts will take quite some time.

So, are you saying that
"addf pwmgen.make-pulses base-thread"
Causes the PC to shut down and need a reset?

Is it possible that your base-thread period is shorter than the base-thread latency?

I have a Chinese parallel port board and I can't get the Y1 axis to be a slave to the Y2 axis for portigo on a plasma CNC machine. I'll pay for the help.

Thanks for the link. I had already looked through the thread and stopped at mesa 7i96.

However, I didn't see anything about optical correction. Is it possible to calibrate the laser with LinuxCNC, or do you have to use the manufacturer's software? 

Hi.
After 2 years I went to my home made hobbystic cnc to realize a project.
When used last time, the machine worked perfectly.
But today, starting LinuxCNC, I got a message error then LinuxCNC quit.

Here you can find the message (only the Print File Information section):

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/share/linuxcnc/tcl/msgs
INIVAR=inivar
HALCMD=halcmd
LINUXCNC_EMCSH=/usr/bin/wish8.6
LINUXCNC - 2.7.14
Machine configuration directory is '/home/joccnc/linuxcnc/configs/Prova01'
Machine configuration file is 'Prova01.ini'
INIFILE=/home/joccnc/linuxcnc/configs/Prova01/Prova01.ini
PARAMETER_FILE=linuxcnc.var
TASK=milltask
HALUI=halui
DISPLAY=axis
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
Found file(REL): ./Prova01.hal
hm2: loading Mesa HostMot2 driver version 0.15
hm2_eth: loading Mesa AnyIO HostMot2 ethernet driver version 0.2
hm2_eth: ERROR: 10.10.10.10: Could not retrieve mac address
Shutting down and cleaning up LinuxCNC...
Running HAL shutdown script
Killing task linuxcncsvr, PID=2058
hm2: unloading
Removing HAL_LIB, RTAPI, and Real Time OS modules
Removing NML shared memory segments


As I can see, the problem should be the Mesa board MAC address.
I didn't make any change (configuration, setup or else) last time I used the system (2 years ago), so I don't understand what happens.
Honestly, I made a first try with ChatGPT (I know, not the best idea but at the moment maybe.... - moreover it looks to me AS - Artificial Stupidity - more than AI - Intelligence....), but its suggestions were totally useless (some changes to ini and hal files), so I resumed my original files (attached).

Currently, LinuxCNC keep quitting; LinuxCNC correctly connects to the MESA Board.

My OS is LinuxCNC 2.7.14 + MESA 7i76e (Hybrid stepper drivers)

Can anyone help me to fix it?

Thanks

Andrea

These guys got it working with mesa and it seems  the pktuart so your 7i97 should do it..
forum.linuxcnc.org/27-driver-boards/3985...ot2-firmware?start=0 

 
ChatGPT is not particularly useful with Linuxcnc. I worry when I ask AI a question and it quotes into I wrote on this forum back to me.
now you have communication to the Mesa card, I would create a new config with pncconf and see how it goes. If it fails, share your hal and ini file and somebody will help. Also some rules.
1. Stick to the default axis user interface until you get a working  machine
2. Always start linuxcnc from the command line. That way you will see any error messages. Usually messages are fairly clear and refer to the file and line number 

I think the main difference with Linuxcnc is linuxcnc is a blank canvas where other systems have specific wiring terminals for specific purposes. That means you have a bit more work to do  as you have to define a bit more of your machine here. eg for coolant, you need to select a random pin on the 7i96s and then connect it to the appropriate internal signal. Also note if you have not defined your spindle, you won't see coolant/mist controls in axis. 

Proceed something like:
Get x,y,x morion working
Set up home/limit switches. If you did not have these, take the time to wire in a shared home/limit switch an all axes. It is much easier
Get estop working.
Work on your spindle. pin spindle.0.on needs to connect to the 7i96s pin you chose for the spindle on signal (spindle relay)
Set up your 0-10 volt speed control and scale it correctly
Get your encoder working (or do it later so you have something you can use)
Then set up coolant and mist. Test these with MDI commands M7,M8,M9
OIler then follows. I have not done anything with it but the pins are here
linuxcnc.org/docs/html/man/man1/halui.1.html#Lube

Main thing is to share console output and hal and in files here as you work through this so we can help

 

Hello everyone,

I am currently considering building a metal fused bed printer.

I currently have a 500W fiber laser with a wavelength of 1064nm.

I am looking for a galvo head for printing.

I would like a printing range of 300x300, so I am considering a laser beam expander to output 18–22 mm and an SL-1064-300-420 type F-Theta lens.

As far as I understand, the ideal solution for the head would be to find one with an xy2-100 protocol to use xy2mod.
And I am aware that I need to find a computer with very low latency.
I have a Mesa 7i97t, but I assume that it is not compatible because the protocol expects a PWM. What is the best card for galvo heads?

One last thing, is it possible to calibrate the galvo head? If so, how?
 

I think you have it correctly stated and just went to check precisely on the machine, but Linuxcnc won't start due to some mesa hardware issue. The lights are on, but looks like I have a day of diagnostics ahead.

Since the mill is a knee mill, the distance between the z quill and the table is not fixed so I don't think your system would work for me, if I am following your method correctly.

(Your English appears excellent to me)

Can my account and post history be deleted please.

The 3 Axis EXE in my Maho needs both 5V and 12vDC, and output single sided signals. Two of three channels failed. I replaced them with 601D EXE's. They only need 5VDC, and output differential signals.

I’m reaching out to the forum to hopefully get some guidance.I’ve spent the past several days working through a LinuxCNC setup with a Mesa 7i96S for what should be a fairly straightforward retrofit on a :Bridgeport Series 2

• XYZ mill
• X & Y steppers
• Z servo (knee)
• No exotic kinematics, just a basic mill configuration

I’ve gone through many iterations and changes (largely guided by ChatGPT), and while I’ve learned a lot, I’m currently back near square one. I did manage to get one motor oscillating back and forth, so I know signals are getting through at some level.At this point:

• I do have solid communication between the PC and the Mesa card
• Network issues are resolved (static IP for Mesa, internet via USB dongle)
• Latency issues were addressed by disabling several BIOS features
• Debian installation and networking are now things I actually understand, which is a win

That said, I’m struggling with what feels like a high barrier just to get basic motion. My main question to the community is:

Is it realistic to expect a simple XYZ mill (2 steppers + 1 servo) to at least jog without days of trial-and-error, or is this learning curve typical?

For context, I’m not new to CNC:

• I previously had this machine running under UCCNC
• I had:
  • A 4th axis
  • VFD spindle control
  • Spindle brake
  • Mist, air to the knee, and lube pump
• All of that worked reliably

The only reason I switched to LinuxCNC was:

• I want true rigid tapping
• I’m interested in the QtDragon / QtPlasma ecosystem
• I also have a router and another plasma table I’d like to potentially convert

So this is not a casual experiment — I’d really like to make LinuxCNC work long-term.I’ve learned a lot in the last few days:

• Installing Debian cleanly
• BIOS tuning for real-time performance
• Static networking for Mesa Ethernet cards
• Separating “GUI motion” from real hardware motion
  …but I’m still not confident I understand the correct minimal path to first motion.

I’m hoping for reassurance that:

• This transition is doable
• There is a clean, recommended workflow for initial bring-up
• I’m not fundamentally missing something obvious

Any perspective, advice, or “yes, this is normal / no, it shouldn’t be this hard” would be greatly appreciated.Thanks in advance,
Mark

I am having problems with the loading of examples from the GladeVCP manual:  Run the sample GladeVCP panel integrated into AXIS like PyVCP as follows:

when the workpiece is touched off in fact the tool table is shifted

I don't think that's how it works[*].  The only time my tool table changes is when I measure a tool with my toolsetter, it never changes because I've touched off the workpiece.  Touching off the workpiece should change the WCS's offsets, accounting for tool length, not the tool lengths themselves.
I think you've figured out the right way to do it, though.
I've not used "tool touchoff" yet but from what I've read, it works relative to the WCS.  Thus, you have to start with a tool that the WCS is zero'd to (regular touchoff), and you can set the rest relative to that (with tool touchoff).  With TT you first put the end of the tool at a known location relative to the WCS, then tell the system "this tool is at XYZ regardless of what you think, to adjust your idea of the tool's location[2]" but it only works if you know what the XYZ is.
So what you're doing with your depth gauge is measuring it's Z with a "known good" tool, then setting all the rest of the tools to "that Z" because "the tool is at that Z, adjust for it".  You have to re-measure it each time you change the WCS, with another "known good" tool, because when you change the WCS you change the location of the depth gauge *relative to the WCS*.
What my system does is use a separate WCS just for the toolsetter (depth gauge in your case) which is always the same offset from the machine origin (G59.3, set from the INI file by my M6 code).  That way I never have to measure the toolsetter, because it's always at the same XYZ relative to the machine.  It does mean, though, that the tool "lengths" are relative to some arbitrary datum.

[*] although maybe we're not understanding each other, because the odds of English being the problem are just as good
[2] I just realized I set up my camera and laser offsets the hard way...
 

I understand what is happening here now. When I set all the tools together, using a depth gauge on the machine table the tool table is filled out with a set of z heights. When I then touch of one tool to the work piece, I get the desired effect of a set of tools all set to the work piece and if nothing needs changing, all is well. The piece can be machined
However when the workpiece is touched off in fact the tool table is shifted by what ever the difference in height is between the work piece datum and the depth gauge, and if just one tool needs adjusting, you need to know what this difference is. I didn’t. 
So to set the tools and also know what this offset is in case of breakage etc, I think this can be achieved by taking one tool, touching off the z axis to the workpiece datum, then moving this same tool to the tool depth gauge and recording the z offset to trigger it. Then when triggered touch the tool off and enter the recorded offset, which is the z offset of the workpiece datum. Then change to the next tool using MDI TX M6 and again move the tool on to the depth gauge and when triggered, touch that tool off, entering this same z offset just recorded before and again with all the tools.
Should you then need to make a tool adjustment or change this can be done by touching off on the same gauge on the machine table, entering our established z offset from the gauge to the work piece datum.
must work as just made this on my Hurco KMB-I