Advanced Search

Hallo Forum!

Ich bin nun soweit die Maschine zu testen und die Achsen zu verfahren.

Mein Hauptproblem: Ich kann selbst im Dialog "Achsen tunen" die Kommunikation mit meiner Mesa-Karte nur für kurze Zeit aufrechterhalten. Die LAN-Schnittstelle blinkt dann nicht mehr und es geht nichts mehr.
Die 5V Versorgung habe ich schon gegen eine stärkere getauscht, hat aber leider nichts gebracht.

LinuxCNC habe ich noch nie gestartet ohne diese Fehlermeldung:
Operation Error: hm2/hm_27i92:error finishing read! iter=4730

Der Rechner ist ein alter AMD Athlon(tm) II X2 250 Processor. 4GB DDR3-Ram, alt, aber eigentlich ausreichend, hoffe ich zumindest.
Leider auch mit Realtekchip für Ethernet.

lspci -nnk | grep -iA3 net  gibt aus:
02:00.0 Ethernet controller [0200]: Realtek Semiconductor Co., Ltd. RTL8111/8168/8211/8411 PCI Express Gigabit Ethernet Controller [10ec:8168] (rev 03)
    Subsystem: Foxconn International, Inc. Device [105b:0e22]
    Kernel driver in use: r8169
    Kernel modules: r8169

Ich habe bereits einen Kern isoliert mit "isolcpus=0,",
meiner Meinung nach sind die Jitterwerte auch eigentlich ganz io..

Irgendwelche Ideen?

Vielen Dank schonmal, Gruß, Thomas

In my opinion, Ethercat is a great solution for small machines that can use integrated drives.
I have mills where the individual axes are connected to the rest of the machine via a one patch cord and one power cord, and things like homing limit switches  or other sensors are connected locally to additional drive inputs.
Such a machine is simple to wire and, in my opinion, more reliable.
However, if all the control is to be located in one cabinet and long and multi-core cables are to be run, Ethercat loses its advantages for now. It's just expensive and difficult to set up, and what's best about it becomes secondary...

First off, AI helped with website, marketing etc ... I dont think its capable of complex applied math thats required for a CAM and we did not use any AI for the same.

Second - GPL obligations attach to distributing a derivative work of GPL-licensed source. No GPL source is ever in our tree. The code was written against our data model, our kernels, our architecture — the post-processor library isn't a re-derivation of anyone's, it's config-driven dialects off a specified ISO base.

Every component we ship is enumerated and licence-checked by the build, and the build fails if one isn't.

I'd fall back on other more knowledgeable folks who use AI more extensively than we do if this does not answer your query.

So do you have any recommendations wich brand of ethercat drives to use for minimal setup and maximum stability? How big of an issue is hosst PC performance with ethercat ?
Is the importance of host PC performance comparable to a mesa card? Or more or less important? The thing is that for the first evaluation of Linux CNC we will use a mesa card, as it's the cheapest and quickest way to test it, but later we would like to use ethercat drives.

Sorry for the offtopic, but I have to ask, how can you be sure that AI won't use GPL-licensed code to write a commercial program? After all, AI does not write code from letters and numbers, it only modifies examples found on the Internet...

jjdege wrote:

Hi,
in the XML file you posted, the vendor ID (VID) is 0x00400000, while the EC1-57E manual says 0xAB5 or 00000AB5.
That could be the problem.
Hi

Use the values reported by ethercat slaves -v

Hi,
in the XML file you posted, the vendor ID (VID) is 0x00400000, while the EC1-57E manual says 0xAB5 or 00000AB5.
That could be the problem.
Hi

Thanks Peter for your help and quick responce.

I would strongly recommend against deionized (DI) water in any cooling system where you don't have the exact specifications of all materials in the loop (i.e. an off-the-shelf spindle cooling system).

DI water can be extremely corrosive to certain metals, plastics, and rubbers, especially at elevated temperatures.  I suspect most of the major components would be unaffected, but you can't verify what the MOC is for everything you can't see:

• o-rings & seals
• adhesives
• solder/braze
• hose & pump internal materials
• internal coatings in spindle

My recommendation is to use distilled water, not deionized.  Distilled will achieve the objective of eliminating tap water mineral deposits, but without the risk of some system component you can't see or control being corroded.

(distant) 2nd choice would be reverse osmosis (RO) water.  RO water is corrosive to certain metals, but should be ok (ish) with most polymers.

Don't take my word for it - a simple search for "DI water corrosion" should result in a trove of chemical compatibility charts.

There are a number of applicable standards. I am no expert on them. Aside from local country specific standards like AS4024 here in Australia, International standards include ISO 13850, IEC 60204-1 and IEC 60947-5-5
on a home machine, often a 2 pole estop button is used. one pole cuts mains power to spindle and stepper motors and the other is low voltage circuit wired to linuxcnc to tell the controller estop has been pressed. But this does not safely bring heavy machines to a stop so it gets more complicated. Also its not helpful if you have the control panel at one end of a plasma table and you want to place an estop at the other end where the console is. One approach might be to run a pull rope right around the table but running mains power to another distant switch clearly adds its own safety risks.
I suspect estop-latch predates the standards but it does allow you to create an estop chain in software. It is somewhat complicated to understand initially and I find its best to draw it on paper as a series of boxes (one for each estop-latch) each of these boxes has an OK-out pin which needs to connect to the reset pin on the next in the chain with the last OK-out connected to iocontrol.emc-enable
Each latch will have either a fault-in or ok-in pin attached to the estop button or door latch or whatever that needs to be safe before the machine will start. Finally, the iocontrol.user-request-enable pin is attached to the reset pin on the very first latch. So when the user requests the machine to be enabled (usually the orange button in axis), a short pulse is sent to the first reset and if all faults are clear, the sigal to start the machine arrives at linuxcnc. The beauty of this approach is that you can just as easily use a momentary push button to act as that reset signal if you wish.   

Taking that into the standards says the controller can have no part in the safety circuit, and every sub-circuit and every contactor needs to have  dual redundancy so a fault will not trigger anything and both circuits need to work before something's enabled. Also if there is a power outage, the machine cannot become live again when power is restored. You need to press that reset button. Also every contactor and every relay needs to be a force guided one where a non conducting pin is forced between relay contacts to guard against them welding closed from an arc.. Aside from that the safety circuit or safety relay does the same thing as estop-latch. It won't enable the machine until every component being monitored is safe.

AI did help. But if you check it out, you would know that it was built by humans for humans.

UPDATE

It wasn't me.

I ran the issue through Claude and the overlord reported back that the sidebar tab .py file had (I think) an indeterminate layout which was conflicting with the main UI file.  No error messages, but wasn't loading.

I've attached a Claude-generated document describing the issue and the suggested fix.  I've tested the fixed .py file and it's working fine.

Lcvette - might want to have a look and see if you're interested in editing PB as suggested.

snowgoer540 wrote:

How much of it was written with AI?

+1
-
Personally i do not like whatever this AI thing is called, it is an LLM and should be called as such as it has nothing to do with any kind of intelligence.
But, i do like it for some things, mainly being tired of very, very bad "Software engineers" and "Graphical Designers", and hate it as humans will misuse everything so we are inundated with slop everywhere.
I did use it to do some Python programing, and given the right direction it does produce usable code, but absolutely does not produce "production" level code without being heavily guided, and needs constant monitoring and checking as it messes up a lot.

Billy wrote:

# --- ESTOP-OUT ---
net estop-out  =>     hm2_7i96s.0.ssr.00.out-00
setp hm2_7i96s.0.ssr.00.invert-00 true# --- ESTOP-EXT ---
net estop-ext     <=  hm2_7i96s.0.inm.00.input-03#  ---estop signals---
net estop-out     <=  iocontrol.0.user-enable-out
net estop-ext     =>  iocontrol.0.emc-enable-in

Omit the first line by adding # in front of it.

Gosh... I didn't mean to open a can of worms!

Thank you very much tommylight for your suggested fix. Unfortunately when I add this line to my hal file, linuxcnc fails with the following...

"./Bridgeport.hal:313: Pin 'hm2_7i96s.0.ssr.00.out-00' was already linked to signal 'estop-out'"

(aside: line 313 is where I added tommylight's line)

I have been reading up on the HAL interface, and I have to admit that I am still quite confused. about how these things are intended to work? It is clear that they do, and for that I am thankful. It is just very hard for a newbie such as myself to make sense of.

Rod,
I appreciate all of your helpful literature and the videos you have made on various linuxcnc topics.

When you say "Its pretty well described in the man page and there was a hal tutorial about it on the forum." it would be *super* helpful if you would link the articles/threads you are referencing. Otherwise I really have no way of knowing which particular man page or forum thread you are referring to. There are a number of forum threads which seem to fit your description and which also appear to contradict one another?

I wonder if you are referencing the estop-latch man page? If so, I have read it, and I do not feel that the man page does a very good job of describing estop-latch at all! It does not explain estop-latch's purpose, when it should be used and when it should not. Further, it does not provide any usage examples. The man page does describe the options, and I expect it does so completely, but it does not explain any of them. I found it quite cryptic actually. I am still entirely confused about what problem estop-latch is intended to solve.

I understand there is some debate about whether having the hard estop signal run through linuxCNC is "compliant" or not. I must admit that I am completely in the dark as to what standard we are complying with, so I have no opinion. While I do care about safety, compliance is not a issue for me right now in my home shop.

All I am trying to achieve here is to have "hm2_7i96s.0.ssr.00.out-00" go high when "hm2_7i96s.0.inm.00.input-03" goes low.

Seems like it ought to be simple... but there is clearly some piece of the larger picture that I am missing, because it is appears that it is not simple?

Thank you for your help.

Bill