Advanced Search

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
 

I really should wait a few before responding to give my brain a moment to think about the issue at hand. I figured it out. Sorry to keep pestering you. Geometry was set to X-Z when I put it to XZ It started working as desired.

I figured out what I did wrong and corrected it. The preview shows the marker on the lower left of the preview screen.

The only problem to figure out now is the marker goes in opposite directions of the saddle. Press positive and the saddle goes to the right and the marker goes left out of bounds of the preview. I'm wondering if this is an encoder issue.

Hello PedPEx,

I'm currently setting up my own EtherCAT based controller as a mock up before I replace my current control board. Your single axis configuration really did help getting my JMC iHSV57-30-18-36-EC moving.

One question though: You are setting "setp cia402.0.pos-scale 3600". Do you have any reference where this value comes from? Can you give me a hint how it gets calculated?
My final setup has ball screws with 5mm/rev thread pitch.

Second question: Did you ever try to use the "basic_cia402" device type in the EtherCAT XML file and got it working?

Thanks,

Uwe

Hmm. It appears it won't allow me to do that. LinuxCNC terminated with an error. 

Redacted.

Dear All,

I try to set up 7i93 PWM control for my ATC motor and I struggle with its rotation direction change, meaning:

- if pwmgen.0.value = positive number, pwm signal is on PIN6 as expected, motor rotates clockwise.
- if pwmgen.0.value = negative number, there is no PWM signal on PIN8, motor does not rotate at all.

I use PWM controlled mosfet bridge which expects CW and CCW input PWM signals on TTL level.
Regardless of pwmgen.output-type it does not work, but based on hostmot2 manual in my understanding it should work with output-type 2.
7i93's firmware is standard.

What do I wrong, or how can I change the rotation direction with PWM if my motor drive expects CW and CCW PWM signals?

thank you for your help.
Regards,
Tamas
 

My router(laser) is currently torn apart undergoing an epoxy leveling upgrade to be followed with motor belt gearing change for plasma cutting. So weeks or end of summer away from any laser work.

I think linuxcncrc should be treated as a dead end as python has more support.  

What would be nice is a linuxcnc python TCP server that can communicate with Lightburn for laser cutting operations.

• TCP because that's supported by LightBurn running on a Windows PC to LCNC.
• Python as that seems best supported for LCNC interfaces.
• Lightburn interface as it works very well for laser operations. (outline cuts, laser offset, home, zero, etc.)

Getting Gcode across was easy using linuxcncrc and some string substitutions.
What takes a little more work is the extra commands to home and things like getting position. The Lightburn GUI has a serial terminal where you can see some of the extra commands. They use a lot of 3d printer Gcode extensions (M114 to get position).

What is your interest/focus?
 

Nope, she can not figure out what those do, strange as her machines have that part much, much more complicated.

just updates.  
Just test fits, mounting of connectors, test fit of control backplates..

Lcvette wrote:

if you are not on the latest release of probe basic, the offsets column setup is in the custom_config.yml file, change the columns to display to XYZR then save the file and restart probe basic and retry.
 

Yeehaaa, it was the custom_config.yml

Great,Großartig ,Thank You,Dankeschön !!!
Step by Step ,my little Smurf come to become ready

Latency  - best i can get from this Thing called Gurke
Motion - ready
Toolsetter - works fine
Probing - Great
Spindel -
 

if you are not on the latest release of probe basic, the offsets column setup is in the custom_config.yml file, change the columns to display to XYZR then save the file and restart probe basic and retry.