Hi all,

a quick update from the multichannel LinuxCNC project I posted about earlier (looking for testers with real machines). Everything now lives on our new site: www.cnc.gmbh

What you'll find there:

Try it online – a live test environment where you can run the multichannel system in your browser, load programs for several channels and see how the synchronisation (wait marks, channel coordination, Sinumerik-style syntax) behaves, no install needed.

Download - the current .deb packages for Debian [12/13] (amd64, [arm64]) plus the full source code. Build instructions are included.

Config generation offer, since the most common question is "how do I get my machine running with it", we're offering, for a limited time, to generate the complete LinuxCNC configuration (INI/HAL, channels, axes, spindles, I/O) for your retrofit, works for existing LinuxCNC setups you want to migrate as well as brand-new retrofits. Send us your machine data and drive/IO hardware via the form on the site, and you get a ready-to-run multichannel config.

Feedback, bug reports and especially reports from real machines are very welcome, either here in this thread or via the site.

Thanks,
Daniel

Right now I don't think there is any form of "active" spindle. There is the primary spindle which responds to commands with no spindle designation or $0 commands. And all spindle commands intended for spindles other than the primary one must be appended with with $n, where n=the spindle's designation number.

Before the addition of multiple spindle support, one of the main work arounds was to create custom M-codes to designate "active" spindles that would then receive the standard spindle commands. But that isn't how the current multi-spindle support works. In some ways I think that is almost a better way to make it work. And It still can be done this way, but it does make for a much more complicated hal configuration.

One way to debug this might be to do a halscope plot of the homing sequence.
That is, plot the home switch states and Y +Y1 motion during a home 
move.

Hi HansU,

I'm not sure the files are the issue since nothing has changed since the panel last functioned properly. However, I've attached both files.

Thanks for working with me.

Kind Regards,

Hi PCW;

I reinstalled the boards and then verified with halshow that all of the field input switches were functioning correctly. With the spindle located in the middle of the table I started the homing sequence. Z and X both homed properly, however, when Y started the homing process a, "joint.1 failed to unhome" message was presented 3 times then joint.1 began to home while joint2. failed to move.

The machine is configured with both the Y and the Y2 axes (joint.1 and joint.2) set up with "both limits and home" switches using a single input for each axis. Thus, neither axis home switch was triggered yet LINUXCNC could not logically unhome one of the two axes.

What is the next step to resolve this issue?

Kind Regards,

Good to know. Thank you very much for taking the time to respond.

This is normal for the 7I97T, newer cards have had the LED indicator
circuit changed to prevent this dim glow but, the 7I97T has not had a
board revision to fix this yet, but It's just a cosmetic issue.

Thanks for the advice.
What are your thoughts on using a LAN9252 + STM32F407 combination for this task?
Specifically, running the open-source SOES (Simple Open EtherCAT Slave)  repository to stream the hardware encoder count over SPI to the LAN9252.
I don't have a tight deadline or an urgent problem to fix; I am mostly interested in learning and getting hands-on experience with the EtherCAT architecture. Is this a viable and stable solution for a lathe spindle encoder under LinuxCNC, or is it not worth the hassle?

 

Hello,

On our 7i97T, five of the six isolated-output LEDs (OUT0–OUT5, next to TB5) glow dimly whenever LinuxCNC is running, although every output is off. The brightness differs from channel to channel, and the OUT0 LED stays dark. Photo attached (LinuxCNC running, all outputs off).

Setup

• 7i97T, firmware 7i97t_7i74d.bin; a 7i74 on P2 with a 7i70 and a 7i71 on smart serial
• LinuxCNC 2.9.10 (uspace), hm2_eth; ssr.00.rate at the default 1000000, all invert-NN 0, all out-NN 0
• 5 V from a Mean Well MDR-40-5 on P3: 4.99 V measured at P3
• OUT0–OUT2 switch the logic inputs of a VFD (Control Techniques Commander CD, about 14 V open circuit, about 1 mA), with OUT+ toward the drive. OUT0 and OUT1 pass through safety-relay contacts. Nothing is connected to OUT3–OUT5.

Measurements (ohmmeter, red on OUTn+, black on OUTn−; VFD unpowered, safety-relay contacts open)

• All outputs off: OUT0, OUT1, OUT3, OUT4 and OUT5 read O.L. That holds both while the LEDs glow and with ssr.00.rate set to 0, when the LEDs go dark.
• OUT3 commanded on: 0.3 Ω (the meter leads), LED fully bright. Off again: O.L, back to the dim glow.
• The LEDs are dark before LinuxCNC starts, and go dark when it exits or the watchdog bites.
• Two days ago, with the VFD powered and the outputs off, its inputs on OUT0–OUT2 read their full open-circuit voltage.

Questions

1. Is a dim glow on the output LEDs with the outputs off normal for the 7I97T? Or does it point to a damaged output driver?
2. If it is damage, can it get worse? Could an output that is off start to conduct? Is there a further test you would suggest?

Thank you.

In a nutshell:
All small Chinese milling machines based on 10 or 12 mm shafts and TR8 screws should be considered working models at best.
They have a lot of educational value and zero practical value.
Of course, there are worse and better models, but all of them have problems with stiffness, vibrate and have irremovable backlash.
Any attempt to improve anything in them is a waste of time and money.
The GRBL driver is the least of your problems. Code written for GRBL can be executed on LinuxCNC without any changes (it may or may not work the other way around).
To be usable, a milling machine must have linear rails, ball screws, and a rigid metal frame. With a budget of USD 1,000 you can find something.

Aciera wrote:

many further changes are currently in testing and will hopefully be merged step by step into master over the coming months.
 

I'm afraid this won't be a solution for me, just replacing one problem with another.
forum.linuxcnc.org/ethercat/59324-lcec-c...c-2-10-and-debian-13
The changes in the master branch have gone way too far. You should wait until version 2.10 is finished before rewriting the basic code. Now it's the case that code written a month ago will not work with LinuxCNC compiled today. If it continues like this, no one will control it...
For now, I would like to stay with the version compiled on September 26, i.e. with working Ethercat.

I know how to deal with changing limits and I wrote the appropriate m-codes yesterday and changed existing M428 and M429. It can also be solved differently.
It's workable for now.

tuxcnc wrote:

But today a serious problem arose and I had to look into it

I wouldn't call an incorrect syntax highlighting a serious problem

tuxcnc wrote:

The second image is in program execution mode. Why the hell do the parameters change from black to gray,

It's because editing is disabled while the program is running.

tuxcnc wrote:

And if this is the case, why is the default g-code theme set to "classic" and not "gcode"?

What of the classic G-code theme do you dislike in detail?

I'd report that as a bug, somebody might change it to act on the current spindle as they have been out for a while...

Also there is now a  driver for the Beckhoff EL6001/EL6021 serial terminal driver modules to get rid of your PC based serial port connection. This driver publishes a serial tty port to your PC so you can continue to use mb2hal with very little change
ref:  github.com/linuxcnc-ethercat/linuxcnc-ethercat/pull/525