Advanced Search

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.

Jeff Bridges in Iron man!

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

please run 
latency-histogram --nobase --sbins 1000 show 
and share the screen dump here after a good workout.
Your version of way to bad is not enough for you to advise you on

Yes, I experience this effect as well. It is caused by the fact that, when using the handwheel, you are constantly commanding a new target position for the axis. Even if you are only moving in small increments—0.01 mm or 1.00 mm at a time—the acceleration and deceleration ramps are still being applied. If these ramps are set too short, the axis accelerates and decelerates with every single increment, which is what causes the rattling sound.
You could address this by generally lengthening the ramps—though this would impact your machine's overall dynamics—or you could implement a specific solution within your XHC HAL configuration

Thank you so as for the spindle, i am actually not using a spindle head as the machine is a metal forming machine, so i have 2 Y axis Motors 4.4kw, 1x X axis 4.4kw, 1.5 Z Axis for pressure and the 2 1.5kw on the resistance table moving up and down in relation to Z movement,
Will Look into the the Beckof units

djdelorie wrote:

I have a probe that bounces during the G0 move away after probing.
 

You can reproduce the queue error?

I have made in the past something similar, using small pc and MESA.
Really I was not successful in optimizing BIOS settings. There was periodic latency delay. But you should not worry about that to much, if you don't have problems with motion of course. MESA handles motion execution, so it's not depend from pc latency to much. In my case it was only warning message.
But you can increase latency of linuxcnc config for better response or change.

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

Thanks for your reply. What do you need to help narrow down the problem? I only adapted the `Toolchanger.ngc` file for my machine; otherwise, I haven't changed anything in the G-code.

Danke, das ist ein guter Hinweis (da hätte ich auch selber drauf kommen müssen)! Die Maschine ist sehr gut geerdet (Sorotec Hobbyline).

Ich habe gerade mal nachgemessen: Der Lenovo-PC läuft über ein 19V-Netzteil und ist nicht geerdet! Das werde ich nachher mal ändern und testen. Und dann werde ich auch testen, ob der GCode mit ausgeschalteter Spindel durchläuft. Der Fehler tritt aber nur sporadisch auf und nie an der gleichen Stelle.

Ich werde aber berichten, ob die Erdung etwas bringt!

Danke!
Chris

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. 
I need 4 servos, 60 € more than the other servos for all 4, dont know if sto makes sense for me, that would be another ~ 60 € ish. 
I already have a pilz safety relais, how do I tie that into the system with sto?

Im using 8 endsensors and possibly multiple tool sensors in the future,  so I would go for 16 i/o right now and add more later if needed.

VFD would be controlled by a 10v analog output ~50 €

In turn I could sell my mesa, dont know how much I would get tho. Sadly I cant send it back anymore, at least I think so.

OK.. Well bypassing the programming gobbldygook... only thing different on this file was a new tool - a tapered nose ball end. I went back and changed the tool designation in vectric (the program used to make the file) ((Not the tool name) and re tried the file - seems to be working. I think the utf-8 doesnt like the degree symbol maybe?? Being a tapered ball nose is has the degree symbol (small o) in the tool type description in Aspire. Any comments??
Thanks

The drive is connected to LCNC - that's how I've been triggering the inputs and attempting to trigger the outputs.

The drive is hooked up to SSRs and I've got LED's driven by the outputs.  If I force the outputs via the tuning software the LED's light up.  So test hardware is functioning as expected.

Simply renaming the vendor-supplied xml file doesn't work - it's incompatible with lcec_conf.

The xml file I'm using works for the inputs, and the address for the digital outputs is correct - otherwise I wouldn't be seeing the digital outputs line in the tuning software parameters monitor change.

What I need is the bit value, or more likely a combination of bit values, which the drive requires to trigger the outputs.  I was hoping someone could interpret the vendor-supplied xml file snippet and explain it to me.