Advanced Search

Ok I got a real issue with a forum member and the posts he makes.
Most of the time it's not quite right, other times I feel if other users follow his advice it's going to cost them money, time or absolute worst case possible injury.

What do I do ?
Ignore him
Report him
or something else ?

Using the 12v rail from your PC negates the protection the optos are used for.

I suggest to forget all the BS you've learnt from the Hipster Maker crowd and read & learn by someone that knows his stuff.

This is a good start, written by the guy that designed the TEC-1 sbc back in '83 or '84:
www.talkingelectronics.com/te_interactive_index.html

Ok we get you don't get Python, they are just libraries, not dependencies, the same as you need libs for C & C++ and other things.

WTF you're dragging up a thread that's over 12 months old and repeating your opinions regarding Python & Java & not adding adding that is of relevance, every time you post it has nothing of importance or relevance.

Yeah I get the irony, but (insert vulgar speech here) you're such a (insert vulgar speech here) waste of space.

Hello everyone,I am a new LinuxCNC user and developer. This time, I would like to use LinuxCNC in combination with my cutting simulation process. I have encountered some problems and would like to know if there are any known solutions in LinuxCNC. If not, I am interested in developing features similar to G43.4 and G43.5.Before we get into the details, let me provide some context. I am running LinuxCNC 2.9.4 on Debian 12 with PREEMPT_RT. Please note that for my simulation process, real-time (RT) capability is not a strict requirement. My simulation uses the configuration from , which matches the machine type I need.Here is my understanding of the five-axis xyzab-tdr support:
The key is the toolpath (TP) transformation. Five-axis machines are different because they require transforming the workspace coordinates to real joint positions, which involves both forward and inverse kinematics. The xyzab-tdr configuration provides these transformations. The main parameters for these transformations are seven in total: , , , , , , and . The , , , , , and  define the machine’s geometry, while  functions similarly to Fanuc's G43.4 RTCP (Rotating Tool Center Point) tool compensation.In RTCP, G-code is typically provided in two forms:Fanuc-like: Siemens-like:My questions are:

1. In Fanuc, G43.4 is modal. Does LinuxCNC use the TP transformation as a modal mode as well? In other words, when using five-axis TP, is G43 equivalent to G43.4 in LinuxCNC?
2. The IJK parameters are used for Freeform Surface toolpaths. Does the G-code parser in LinuxCNC support IJK-style input?

Thank you in advance for your help and insights!

I’m not sure if you have any time to spare, but I’d be happy to compensate you for it. Even if you’re not local, I’d be grateful for any kind of remote tutoring or guidance—video call, screen share, whatever works for you.

I’m based in California and have already put a lot of time into getting this setup working, but I’m still stuck. The learning curve has been steeper than I expected, and I really need to move forward.

At the moment, I’m struggling with tuning the driver, displaying the distance between the Z and W axes, and getting the control buttons to function properly. Since you’ve done similar setups, I thought you might be able to help me through some of this and save me from going in circles.

If you can’t do it yourself, I’d really appreciate a referral to someone who’s handled a similar project and could assist remotely. Otherwise, I may end up switching to Centroid just to get our shop running and meet deadlines.

OK then the problem is not the firmware (I tried that firmware  with a 7I92TF and a 7I76
and the 7I76 was discovered and operated under LinuxCNC))
but rather a hardware issue, perhaps cabling or 7I92T 5V cable power settings.

Note that hm2_7i92.0.7i76.0.2 is not present in the G540+7I76 firmware I supplied, only
sserial channels 0 (7I76 field I/O) and 1 (7I76 expansion channel) 

Hi Peter,
Thanks for the firmware build. I have flashed it to the 7I92T and read back an identical hm2 configuration to the supplied pin file.
Unfortunately the 7I76 is still not coming up correctly; --sserial query finds no devices. Loading the board in hal fails to enumerate the hm2_7i92.0.7i76.0.2. Back to the stock firmware w/ identical hardware configuration and the 7I76 is found.

I would also like to see the config for using a servo as a spindle motor.

What does:

mesaflash --device ethernet --addr [card_ip_address] --readhmid 

report?

 

Python is object-oriented...sort-of.

I agree tho.

Also, take advantage of those optoisolators (superfluous though they are) and power the relay board with a totally separate 12V DC supply.

The power supply for the relays does not need to be that powerful.

Thank you for asking.

I've done a lot of research and I've just about found the solution, now I just have to imagine how it works in my head.

Below is the result of my research for those who are interested:

I found exploded diagrams of toyota embroiderers and therefore found their name.

Then it got easier!

Their names: thread catcher and ass'y picker (assembly picker).

ass'y picker : 

thread catcher :

 

Here is the code used to detect contact
plasmac.ohmic-enable is connected to the "enable" signal in the code below, as well as to the output that activates the relay.
"limitVoltage" = 12V, halfway to 24V
"inVoltage" is the read voltage from the voltage reader.
"ohmicState", internal variable, is used to make sure the voltage first go above the limit and then start watching for contact. The relay has some reaction time, some 10 msecs, enough to need to be handled.
"voltageState", internal, indicates successful voltage reading.
"sensed" is the outsignal for contact yes/no.

Now it works. Again
The arc voltage connector is not connected directly to the arc and the work piece. There is some electronics in-between I don't even want to know about. The arc voltage is fine when cutting, but not reliable at all when not cutting. And ohmic probing is not cutting.

Instead I had to resort to a second voltage reader and read the voltage where the probing voltage is applied.
And now it works reliably. At least on the tests I have done so far.
Test patterns. I might have used wrong material setting on some but that doesn't matter for the probing test.
 

A new voltage reader was put in the box, next to the relay that applies probing voltage.
 

Cover on and pushed in next to the plasma cutter.
 
 

Schematics and code is available at github.com/MetalMusings/MyOwnEtherCATDev...th-the-iptm-60-torch
It uses my own Ethercat device. But nothing hinders this principle to be used with other arc voltage measurement devices such as those from Mesa. 
 

+24V --> RELAY_COIL+ --> FLYBACK_DIODE_CATHODE
RELAY_COIL- --> 7I96S_OUT0+ --> FLYBACK_DIODE_ANODE
7I96S+OUT0- --> 24V_COMMON