Advanced Search

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!

 I thought I followed the manual but obviously I must be missing something. During the installation I deleted the contents of the post gui hal (the manual say comment them out) and only added back my pendant hal file. Was that my mistake? What do i need in my post gui hal?

Hello Tommy,

May I have few examples please?
Because this is my actual setup and except mpg, it seems to work fine. Maybe I missed something

Follow the configuration setup in the docs and it sets up manual tool change dialog on a tool call. It's in your hal file and postgui hal files

Your ini file is full of values that make no sense, so make a new config with reasonable values, or copy relevant parts from a standard config.

I made a small video, sorry it's not a proper screen recording.


It shows the behavior quite well. The mpg count is correctly counting, joint.2. Jog count also but the axis doesn't move each time, it jumps from time to time.
Deadband is quite low, I don't think it come from this

Hallo miteinander,meine bisherige Musteranlage (LinuxCNC → Mesa → Schrittmotoren) hat grundsätzlich sehr gut funktioniert. Allerdings ist und bleibt das Ganze ein reiner Testaufbau.
Jetzt möchte ich etwas größer denken und den Schritt von der Demo- und Testanlage hin zu einem echten Prototypen machen – mit dem Ziel, daraus irgendwann einmal eine wirklich verkaufsfähige Maschine zu entwickeln.In diesem Zusammenhang bin ich auf die Leadshine EL8 gestoßen. Zusätzlich habe ich das Video von talla83 gesehen, was bei mir die Frage aufgeworfen hat, ob ein Umstieg von Mesa auf EtherCAT sinnvoll wäre.Ein mögliches Beispielsystem, wie ich es mir aktuell vorstelle:

• Linux-Rechner
• LinuxCNC
• Leadshine EL8 (Servo-Treiber)
• Beckhoff EK1100
• Beckhoff EL1018 (DI)
• Beckhoff EL2004 (DO)

Was mir aktuell noch schwerfällt einzuschätzen:

• Welches System ist im Alltag wartungsanfälliger?
• Welches ist auf Dauer robuster und stabiler?
• Welches zickt beim Systemstart eher mal herum?
• Gibt es typische Stolpersteine bei LinuxCNC + EtherCAT im Vergleich zu Mesa?

Ich würde mich sehr freuen, wenn Ihr Eure Gedanken, Bedenken oder auch ganz konkrete Erfahrungen dazu teilen könntet – insbesondere im Hinblick auf einen späteren Dauerbetrieb und einen professionelleren Maschinenaufbau.Hier noch die relevanten Links:

• Video talla83:
  
• Leadshine EL8:
  www.leadshine.com/product-detail/EL8-EC400F.html
• Beckhoff EK1100:
  www.beckhoff.com/de-de/produkte/i-o/ethe...-koppler/ek1100.html
• Beckhoff EL1018 (DI):
  www.beckhoff.com/de-de/produkte/i-o/ethe...-eingang/el1018.html
• Beckhoff EL2004 (DO):
  www.beckhoff.com/de-de/produkte/i-o/ethe...-ausgang/el2004.html

Vielen Dank schon mal für Eure Rückmeldungen!Viele Grüße
Mücke

Hi EdWorks, Some of it is documented on this forum. I got stuck at one point in the ethernet comms losing packets but that is resolved (documented on the forum). If you want to have a look, I could show you over video (Telegram/Signal).

In hindsight the setup was pretty clean and simple with a few gotchas along the way.

When I run Goode in the simulator, it asks me with a “tool change request, insert tool #”, to insert the tool before it will proceed. However, when I  run a program on my main install I do not get that same request screen. The program will wait for me to load a tool before running but it never shows me the tool change request screen or any notion that’s it’s waiting on a tool to be loaded. Is this a normal function or have I not set something up correctly?  I am running without ATC.

Just curious, would two separate LinuxCNC instances, running on two physical PC's, one for the motion control, and the other acting as the PLC meet such requirements?
Cheers,
Mark