Snuggly's Plasma Build

Hi Todd,

I agree. But the gantry type's with homing sensor's only on X0 and X1 is one of the exeptions.
If you have homing sensor on Z. You have no problem. It stay's in the rules of linuxcnc.
Without homing on Z. You find out the solution is a custom component. Or change the linuxcnc source code.
The last option will be a great impact to merge after a few year's of separate coding between the master and the sub.

Would it not be simpler and more effective just to add a Z and Y home sensor. They would not need to take any more io points, they could share with the X1 and X2 home inputs, if you are short on io points..

Hi Todd,

Thanks for your input, i know what you pointed about.
Effective is not the word for the problem. The problem is different. It has more to do with machine size.

In point of time. It matters. If a machine each time linuxcnc startup have to be homed, customer's will think about why homing each time i startup... ?

In practical way we could say add a home sensor on Z, i agree.
Y homing for milling machine's is standard.

For plasma a home z is out of the box. Only the probe sensor is important in my case.
But it really takes time by format 2x4m or 2.5x6m if machine is stopped and closed in the middle.
So that is not a fast option. I tell only my experience so far, and provide information that is usefull to
developper's section to make Linuxcnc the most powerfull cnc application in the world.

I could do it myself, and write a component. But i also will help others, like snuggly. I like this guy and his video's.

Todd wrote:

I believe that both of those problems become non issues if you use the convention of having the machine home the Z axis first before it homes the other axis.

And most machines can be jogged before homing. Some gantry setups may be exceptions to that rule. But even those can usually jog the non slaved joints before homing (in other words move the Z out of the way).

Getting the Z axis out of the way was an early (and violent) learning for me. Yes it takes more time to home sequentially but it sure is safer!

@Todd Zuercher: I boughtthe 7i96 specifically for my large gantry machine so I have plenty of IO at the moment. I have been able to start the homing process, my end-stops just aren't working.

@Grotius, thanks man, I appreciate the help

@Rodw: I was able to get the machine to home in the proper order (z, y, x1&x2), thank you for your suggestions!

I've been talking to PCW about how to write in the NC switches for Mesa, (in_not > in-not) however I can't get my pins to trip in halshow. I'm going to try a different wiring scheme and see if that fixes the problem. Still waiting on PCW to confirm the wiring for my endstops.

Just a quick update, depending on how you wire your switches on the 7i96, will determine what you do with your common pin on the board (TB3 Pin12), in my case I have to wire the pin to ground.

@Rodw, you were right, it was my wiring for the most part. Also, GPIO pins on the mesa board are numbered 0-10, not by overall pin count, which was my mistake entirely.

Found the info above: forum.linuxcnc.org/27-driver-boards/3276...ernet-board?start=10

PCW -
The 7I96 isolated inputs have a single common pin.

If you have 5V signaling and your switch common is connected to +5V you should connect the 7I96 input common pin to ground, then when a switch is closed (and 5V applied to the input pin)
the corresponding GPIO bit should read high

If you have 5V signaling and your switch common is ground, you should connect the 7I96's input common to +5V
then when a switch is closed (and the 7I96 input pin grounded) the corresponding GPIO bit should read high

You can use the "watch" command in axis to look at the GPIO pins in real time

Figured it all out, limits working! I might've mentioned my openbuilds stepper on the Z axis isn't working, I'm trouble shooting that now.

We'll back to integrating TOMA THC into Mesa just a little later today. Cross your fingers gentlemen.

UPDATE: driver is done for, luckily I have a handful of A4988 drivers (should still work), wiring them up might be a pain though.

FFS I couldn't get the DRV8825 to work so I swapped out a DM860A (dropped amps to lowest setting), wired the driver exactly the same as the DM542A and it won't work... I kept the same step/dir values.

So many little issues popping up. I looked up some recommended step/dir values to change over. getting pretty cold here so I need this thing running ASAP so I can get it into a shop.

andypugh wrote:

It's worth using step times comfortably over the minimum spec.

This is by far the most common problem that people have with our hardware and
step drives that are wired properly but wont move.

Unless it limits your maximum velocity I would suggest
using step times that are double the drives minimum specification.

Also unless you have insanely quick acceleration (many Gs), there also no real disadvantage to using
quite long setup and hold times so 20000 ns is a good value to use there.