Advanced Search

Don't rule out the possibility that there are electrical issues with the stepper motors/drives. A bad connection between the motor and drive can often cause problems or even kill a drive. Also make sure that the screws turn freely without any binding. Start with slow accelerations and max velocities and longer step timings increasing until you find the limits of the machine, then reduce to give you a safety margin.

On the flip side, all the electronics are in the drives so there is no control board to fail so you could argue Ethercat has fewer failure points do more reliable. I do like Mesa but Ethercat is easier to wire. Hers is a Ethercat plasma control box somebody shared with me today.

 

One small Chinese IO module and a Proma plasma THC

Seeme like Linuxcnc is set up assuming premeasured tools in a magazine. HOweer you can do this with repeatable tooling or adopt TTD in your MT3 or R8 spindle. When I set up QtDragon, I bought a tool setter and the tiny marble plate with a hole in it from Tormach. I measured all my tools in the toolsetter Including the 3D probe as tool 99.So after touching off with tool 99 with the probing routines, QTdragon asked me to change the tool manually and continue. This worked very well as you could run out a singlee gcode file instead of running  out seperate files for each tool the eold fashioned way!

Yes, I completely agree, it could be more dangerous than practical. Do you think any alternative would be to install a physical button on one of the ports to activate the spindle?

I have a parallel port with all the ports occupied. Would it be possible to configure the parallel port in "in" or "x" mode to have more ports?

The xml settings for the spindle using an EL8-1000 are:
<code>
      <!-- Spindle Leadshine EL8 1000 servo drive -->
    <slave idx="4" type="generic" vid="00004321" pid="000010c4" configPdos="true">
      <dcConf assignActivate="300" sync0Cycle="*1" sync0Shift="0"/>
      <syncManager idx="2" dir="out">
          <pdo idx="1601">
              <pdoEntry idx="6040" subIdx="00" bitLen="16" halPin="cia-controlword" halType="u32"/>
              <pdoEntry idx="6060" subIdx="00" bitLen="8" halPin="opmode" halType="s32"/>
             <!--  <pdoEntry idx="6098" subIdx="00" bitLen="8" halPin="homing-method" halType="s32"/> -->
              <pdoEntry idx="6071" subIdx="00" bitLen="16" halPin="target-torque" halType="s32"/>
              <pdoEntry idx="6071" subIdx="00" bitLen="16" halPin="target-torque-dummy" halType="s32"/>
              <pdoEntry idx="607A" subIdx="00" bitLen="32" halPin="target-position" halType="s32"/>
              <pdoEntry idx="60FF" subIdx="00" bitLen="32" halPin="target-velocity" halType="s32"/>
          </pdo>
         </syncManager>
         <syncManager idx="3" dir="in">
             <pdo idx="1a00">
                 <pdoEntry idx="6041" subIdx="00" bitLen="16" halPin="cia-statusword" halType="u32"/>
                 <pdoEntry idx="6061" subIdx="00" bitLen="8" halPin="opmode-display" halType="s32"/>
                 <pdoEntry idx="6064" subIdx="00" bitLen="32" halPin="actual-position" halType="s32"/>
                 <pdoEntry idx="606C" subIdx="00" bitLen="32" halPin="actual-velocity" halType="s32"/>
                 <pdoEntry idx="6077" subIdx="00" bitLen="16" halPin="actual-torque" halType="s32"/>
             </pdo>
         </syncManager>
    </slave>
</code>
 

Very nice enclosure!
I am also building a Samurai 120 with Leadshine EL8's and LinuxCNC.
My own enclosure is made from aluminium extrusions and is nowhere near as nice as yours.

My solution to the spindle drive problem has been to use a Leadshine EL8-1000 drive and a Leadshine ELM2-1000 motor for the spindle, replacing the original motor and drive. The new drive and motor are 1000W instead of the 1200W of the original Samurai but the motor is a straight drop-in replacement (same mounting holes and hardware, slightly shorter motor overall) and seems both very well built and with a decent overload margin so I suspect the final performance will be very close if not the same, and sticking with EL8's throughout means only one learning curve for manufacturer quirks etc.

When you do that, the same Marco Reps LinuxCNC servo scheme works for driving the spindle, except that the EL8 settings are slightly different to his Metronix spindle settings (for example Leadshine does in PDO idx 1601 a lot of what Metronix does in PDO idx 1600). You also need to factor in the belt ratio from motor to spindle to get the right RPM.

I am also adding small pneumatic cylinders to pull up a bit on the spindle carriage and take the Z-axis weight load, mounted with some sheet metal brackets I ordered from PCBWay that attach around the Z-axis motor atop the column.
 

Der grundsätzliche Unterschied ist, dass du bei EtherCAT keinen Lieferanten hast der Support anbietet. Wenn bei Mesa was nicht geht wird Mesa helfen können sowohl bei der Hardware wie auch bei der Anbindung an LinuxCNC. Wenn aber bei EtherCAT was nicht geht bist du auf Goodwill hier im Forum angewiesen weil Leadshine sich kaum für deine Probleme interessieren wird.

It does load in master now, but it takes a long time to get Qtdragon to show.

Lots of messages about un found widgets:

I'll now look at work flow to see what I can produce
 

If you get counts when there is no activity, that sounds like a noise issue

Is the encoder filter bit set true?
 
setp hm2_7i97.0.encoder.00.filter true

(for channel 00)

Probably, but I'm not sure what the best way to do it would be. I really hate using the keyboard for things like that because it can be dangerous under some conditions. I use a touch screen and it's easy the way the ui is setup to just use the on screen controls for that type scenario. the risk of accidentally turning something like the spindle on while typing scares the crap out of me. The focus of the ui components can alter keyboard behavior so if you think your in a lineedit but focus is somewhere else in the ui you could easily trigger the spindle inadvertantly. How many times have you typed something only to look up and see no text in the box because I had not set focus on the entry when I thought I had. Bad scary..lol

Glad you got it sorted!

Got it, thank you

Thanks Tommylight,

I have set the encoder now in single ended mode from 0 to 1. It is working fine now but have different problem. 

Current status:
I have wired the following
NI-9401 Digital output pin1 to A+ of encoder 7i95
Ni-9401 GND to GND of encoder

Set the loop timing in LabVIEW is 1 sec. 
In Hal show configuration, I can see the A pin gets on and off after each 1 sec.while the B is always on. When the A pin is in off condition no counter increases for 1 sec. When the A pin gets on for 1 sec, the counter is keep increasing randomly.

I expected the counter will not increase during off time when A is off

---

this is correct.
I expected the counter will increase by just one time for next 1 sec---- this is not happening.

I didn't understand your comment B+ wiper/pins. Please tell me more about the connection/wiring of B+, B-, and A- pins.

Also suggest me one daughter board compatible with mesa 7i95 for analog input output with cable model number. I want to buy daughter board and necessary cable together.


Thanks 

I am not an expert, but I was confused about offsets when I started out, and took the time to "get it".  I hope I'll share that here
There are two ways to measure a tool:
1. Measure it relative to some predictable surface, on the bench.  I.e. use a jig and height gauge to measure the actual "length" of the tool.
2. Move the tool tip to a known point in-machine, and do the math.
The first case is common in bigger shops (they can justify the extra equipment but is typically limited to a Z measurement, typically referenced to the center of the bottom of the spindle itself.  It also assumes the tool sticks out the bottom of the spindle (Z-) and not in any other direction.
The second case is used with toolsetters.  On my machine, I probe the toolsetter to get the machine Z at the probe point, subtract some arbitrary number I store the XY and mostly Z location of the toolsetter in the INI file), and that's the "offset".  It's no longer a *length*, it's an *offset* from a reference point.  My "reference point" is near the end of a 1/4 endmill (about 2" below the spindle), by design, so if you forget to set it at least your crash will be less spectacular.
In LCNC you can also do a "tool touch off", where you've probed or touched off your workpiece, change tools, move the tool tip to a known location, and tell LCNC "the tool tip is at XYZ, please set the tool offsets so you agree."  This is useful if you have multiple "spindles" on your machine (my Z carriage has both a spindle and laser, so the laser "tool" has a non-zero XY offset too).  If I touch off 0,0,0 to a point with the spindle's tool, then move the machine so the laser is at that point, the display will show the laser's "offset" from *the current tool* (i.e. it displays machine+G54+T1+T2) but LCNC can do the math for you.

Fundamentally, they're all just offsets in the nine-axis space LCNC uses.  If you want to move the tool tip to a work-local XYZA coordinate (my machine has 4 axes), you take that XYZA, add the G54 XYZA offset, add the G92 XYZA offset, and add the Tool XYZA offset, and move the machine to that absolute XYZA location.
So a "workpiece touch off" assumes the tool offset is correct and sets the G54 offset, and a "tool touch off" assumes the G54 offset is correct and sets the tool offset.

So to return to your question: "it seems like it's moving the G54 Z".  No, it's not.  The displayed Z is the machine's absolute location, plus the G54 (or other WCS) offset, plus the Tool offset.  If you hit the "View->Show Offsets" menu these additional offsets will be displayed.
So it's important to remember that a "touch off" moves the G54 relative to ALL the tools, and a "tool touch off" moves one tool relative to the others.  Thus, you can't change tools and then touch off with that unmeasured tool, because you've changed both sets of offsets at once, and LCNC will be confused.  Put the tool in, measure it, then touch off; or touch off with an existing measured tool, then change tools and measure it.

Also, I think all CNC machines handle offsets basically the same way, but present it to the user different ways (different words, macros, buttons, etc.).
 

Hi Mark, thanks — that’s an interesting idea.

Technically, running two separate LinuxCNC instances on two physical PCs (one dedicated to motion control, the other acting as PLC/HMI) could meet the functional requirements.

However, for our target environment — multiple non-G-code operators, industrial maintenance, and potential future machine sales — we prefer a clearer separation of roles:
LinuxCNC dedicated strictly to deterministic motion control, and a real industrial PLC + HMI handling sequencing, recipes, interlocks, and operator interface.

On the motion side, we are currently planning to use Mesa Electronics hardware (for example 7i96S with 7i84U remote I/O and THCAD-2), but the exact hardware is not finalized yet. LinuxCNC would remain focused purely on motion and kinematics.

Using two PCs increases overall system complexity (two OS installs, updates, storage, diagnostics, etc.), and it still doesn’t fully meet the typical industrial expectation of having a dedicated PLC for troubleshooting, maintenance, and customer acceptance — compared to using a conventional PLC platform (e.g. Mitsubishi, Omron, Beckhoff, etc.).

Safety will be handled by dedicated safety hardware (E-stop, STO, safety relays or a safety PLC), independent of whether LinuxCNC or PLC is used for logic.

So at the moment we are leaning toward a PLC + HMI + LinuxCNC motion architecture rather than using a second LinuxCNC instance as a PLC replacement.

Cheers!