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

Both of those claim to use GRBL, not LinuxCNC, so the LinuxCNC knowledge base here is wasted.

I have no experience with either machine. As a low-stakes entry to answer "do I even like CNC as a hobby?", I suspect either will work equally well (or poorly). You'll very quickly run into limitations- Z height, power, and/or rigidity. Slowly cutting soft woods and plastics should be doable, beyond that... best of luck.

If you're in any way mechanically-inclined, assembly is a complete non-issue. Either one is going to be noisy and make a mess once it's cutting anything.

Do note that the price of the machine is only part of the cost of entry, even if you ignore the disease of buying/building bigger machines later. Even the bare minimum setup of tools/collets/workholding could add a very significant fraction to the cost of one of those machines. If you want CAM software, that could also trivially double or triple the cost (though there are free options- FreeCAD is quite good). No way around the learning curve of either writing gcode or using CAD/CAM, regardless of what machine you're using.

Would I do it? No... I'd save the $[x]xxxx I've spent on machines thus far and buy a Speedio Sarcasm aside, hobby CNC is a massive chicken and egg problem. You don't know if you like it, but the low-cost-to-entry stuff you'll outgrow quickly and/or will turn you off from the hobby with its maddening limitations. You've got to pick what level you're willing to jump in at, recognizing you can ask all the questions in the world and still not know enough.

All that said, I suspect you'd outgrow either machine very quickly. I personally would suggest trying to start with something with more mass, but I understand budgets/space/etc. are what they are. Might be worth checking on other hobby machining forums to see if anybody has a similar machine they want to get rid of cheap- wouldn't surprise me at all if somebody is a step or two ahead of you on the path and would be happy to let a gently-used machine go for cheap just to get it gone.