Advanced Search

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?

 

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. 

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?