Can you power the 7I77 from an external 5V supply?

When you say crash, what actually happens?


 

OK guys, 
Finally back on this again. Got LinuxCNC stable, ended up being a failing hard drive issue. Got my 6i25 and 7i77 boards back from MESA, everything checked out ok. 
I am still struggling on the MPGs. Still crashes the computer when I scroll the MPG handwheel. Its a differential encoder, plugged into encoder #3 slot on the 7i77. I have tried a new MPG, same result. I would say its safe to say the MPG hardware is not the issue. 

Also make sure all power management is disabled on the host PC
Similar issues can come from Ethernet (EEE) or PCIE power management

I had a problem with a Mesa board disconnecting a couple years ago.

Turned out it was a bad/weak DC-DC power supply.  Voltage would drop intermittently, causing the Mesa to reset and I'd get the 'error finishing read' nightmare.  Looked like a network issue, but @PCW helped me diagnose it as a power problem.

Maybe double-check whatever is powering the Mesa and see if it's dodgy.

Just talking from my experience, on my machine i got good result with ilowpass / multiply stepsize

setting for all axis:
MAX_ACCELERATION = 1100.0

If set Stepsize on mpg to 100 or less, it works very good. Even stepsize 500 worked, larger was not safe.
jog-counts and jog-scale can be set for all axis, only the enabled axis will move finally.
This config was made many years ago, thats all i remember

# The stepsize selected is always multiplied by 0.001
# ilowpass − Low-pass filter with integer inputs and outputs
# mult2 − Product of two inputs
 

The Default Axis?

Which interface for linuxcnc u using?

still interested in taking a tcl touch screen version of axis further any interest?
will like to add pause routine as per 3d printers etc

Ich habe jetzt getestet mit und ohne Erdung des Computers - das Problem trat natürlich nicht auf! Ich versuche es später noch mal, mit laufender Spindel...

I don't know what you mean by "queue error" but here's my situation:
I have a pair of mechanical NC probes, one toolsetter and one touch probe. Both are a bit sensitive to machine vibrations (the machine is aluminum extrusions) so I added debounce to reduce those. The toolsetter still trips when I rip a pocket off, but that's useful
However, because of the debounce, the probe trip is now delayed and unpredictable, so I have to probe very slowly.
The probe operation is:
* probe towards, record hit.  Speed in the 1-2 in/min range
* probe away, record hit.  Average the hits to get the final result
* G0 away to clearance.
The problem happens when the "probe away" is still unstable during the G0 move (there really isn't a "deceleration phase" here).  I suspect it's a symptom of the probe design, as it gets *worse* as I go slower, as if the contacts were scraping past each other (yes, I know it's not that kind of probe).
 

I did a calculation:
with 4 ethercat sto servos, beckhoff ek1100(interface), el1809 (16inputs), el2809(16outputs),el4102(vdf control) im getting ~50€ more expensive than mesa + 4 cables.

If I ditch the beckhoff and handle i/o by the servo drives im more limited in machine control and vfd has to be set manually. Spindle control could be added later when I need more i/o for toolchanger anyways.

Basicly a drive i/o system instead of a centered i/o.

Thats why I have difficult times deciding stuff like that, I have two in my eyes equal options. Sto would only come in when using ethercat tho, so theres that.

I also heard about mesa-ethercat combo but it sounds complex with no real benefit. Something you try just because you can I feel. It would probably make sense for me to see what kind of modules I need for ethercat and look how much thats going to cost. 

OP-
The benefit is that Mesa hardware is inexpensive and easy - especially for the 'pricey' types of IO (encoder, analog).

Once you price out the ethercat IO modules, you might price out a Mesa FPGA board and appropriate daughterboard(s) and find it'd be cheaper to go with Mesa for IO.

I suspect for your modest IO needs it won't make much difference, but for an IO-intense machine an Ethercat + Mesa combo becomes attractive.

As far as complexity... every LCNC machine - including Ethercat based - needs a HAL file.  Both Ethercat and Mesa services are started in the HAL file, and pins are assigned like normal.

Not trying to convince you of anything in particular, just letting you know options are available.

rodw wrote:

PRogress!
The vendor supplied XML can go in the bin with the rest of your windows stuff. its for twincat. So explained. I have never used this stuff.

Quickest way to test outputs is to hook up an output to coolant or mist so you can trigger with GUI or MDI command

Rod - I appreciate your suggestions, but we seem to be talking past each other.

I know - have known since I started - the vendor xml file is useless for LCNC.  I was hoping someone more experienced could interpret the vendor xml file to see if the output bit(s) required were buried or presented inside the file.

The quickest way to test outputs is to simply trigger them in halshow; no need to net them to coolant or mist or anything.  This is what I've been doing the whole time I've been fiddling with the outputs.

The drive has been communicating with LCNC since the 1st post in this thread.  As long as I don't flub the xml file edits I've had no problems with the connection & communication between LCNC and the drive.

I just received a reply from Stepperonline regarding the outputs.  I'll test later tonight, but it appears the original OEM (JSS Motors) failed to document anything about the outputs.  Stepperonline was kind enough to supply information about some required parameters (again, undocumented) and the Ethercat addresses/bits needed to trigger the outputs.

I'll post the information later for future reference once I've confirmed it works.

tommylight built this in a cave! with a box of scraps! . LOL.