Advanced Search

Is there a place that has instructions for new users on how to set up an ethercat machine once lcnc and ethercat is installed?

Yes, the docs make it pretty clear I should start with a fresh install.

I'm wondering though: My wheezy-based 2.7.4 system is still running on my old PC. It's been fairly heavily customized, with a custom PYVCP panel addon, a custom POSTGUI_HALFILE to support my gamepad wand, and a custom HALFILE which is used to square up my axes, and which depends on a halcompile'd module (Thanks again for your help, @rodw: forum.linuxcnc.org/10-advanced-configura...rors?start=10#106073)

I'm thinking perhaps I should do a fresh install of 2.9 on the old PC, and get it running all of my customizations on the new release, before moving over to the Rpi+Mesa setup. Just to separate the tasks somewhat. Does that make sense? Or maybe that would just make needless extra work.

So when lines have no intersection, there is no extra torsion turn.

that's quite interesting.

RDA wrote:

Please note that the signal in the drive P1 connector is inhibit, so when the input floats the drive is enabled. This means that in order to disable the drive, you need to provide 5V (from P1 #1) to P1 #11.
For a machine like that, I would just wire a single ”enable” to the drives. Either use the existing relay (most likely NC contacts between P1 #1/#11) or reverse the logic in lcnc.
Relay probably better so that drives are disabled when there is no control to the relay.
 

I did this on my recent mill conversion.  I set up a 3-pole double-throw relay that was activated by the E-stop circuit.  The relay's NC contacts make the disable connection.  When the relay is energized by the control coming out of E-stop, those contacts open and enable the servo amp.  The 3 relay poles make sure there are no connections between the separate servo amps that could cause some crosstalk.
Jon

I would use the higher resolution, perhaps increase the following error limits
and proceed to tuning.

If you have oscillation, reduce your P term.

For velocity mode drives, most of the tuning is setting the correct FF1 term

If you set the analog scaling to machine units per second at 10V, FF1=1.00

You can change the PID values live with the "Calibrate"  window.

I think it's pretty damn cool myself.

JT

@Arciera,

Attached a gcode sample. A cw and a ccw square. That contains the problem.

Extra torsion turn:
 

No extra torsion turn:
 

The investegation, i printed the clothoid result and take a look at the theta values, and compared them :
** where != means is not.

If clothoid output is like this, fit is ok:

• theta10 Z != 0
• theta 20 XY = 0
• theta 14 Z = 0
• theta 24 XY = 0

If clothoid output is like this, fit is not ok:

• theta10 Z != 0
• theta 20 XY = 0
• theta 14 Z = 0
• theta 24 XY != 0

This let me think about how to solve this. When you have the not ok situation,
you can introduce a tiny error to get the fit off-plane. A off plane fit seems to solves this issue.

So when you add 1e-6 (ultra tiny error) to one off the trimmed line's z-position, it goes off plane. Problem is solved.
So when lines have no intersection, there is no extra torsion turn.

Now i did not test any further. So i hope this is it.

Just so you guys know, I host my own 6.12 PREEMPT_RT sources with all the necessary real-time bits applied, including those for the i915 driver.

github.com/NTULINUX/linux

The 6.12 PREEMPT_RT kernel can lag behind so I manually update my sources to the latest 6.12 mainline kernel more often. My tree also allows building with the -O3 flag (compiler optimization flag) to speed up context switching, a typical culprit for latency spikes.

Just be sure you use the ntulinux/6.12.y-rt branch.

Cheers!

Hi  scotta , I am based in the UK, and I am considering buying a few EC300 boards, flashing them with your amazing firmware and putting them on eBay as a LinuxCNC compatible controller. I think this would ease the way for some people into the LinuxCNC world. Would you have anything against it, or do you know if it is against any license agreements? 

When I was looking for a LinuxCNC compatible controller, the only sensible option I found at the time was the Mesa boards, which are quite expensive and require shipment from the USA to the UK. Also, probably not everyone wants to play with flashing the boards.

Let me know what you think. Thanks!

Please note that the signal in the drive P1 connector is inhibit, so when the input floats the drive is enabled. This means that in order to disable the drive, you need to provide 5V (from P1 #1) to P1 #11.
For a machine like that, I would just wire a single ”enable” to the drives. Either use the existing relay (most likely NC contacts between P1 #1/#11) or reverse the logic in lcnc.
Relay probably better so that drives are disabled when there is no control to the relay.

Yes action buttons are some of the most complicated code.
It does make buttons a little less boring

I have a fundamental problem to follow the discusions on ohmic and/or hypersensing.
It would be great if someone can point to the mistake in my thinking.
All of the pilot arc torch heads I know have an electrode connected to the plasma voltage (negative) and a shield connected to the workpeace.
With a HF pulse on the plasma voltage (relative to the shield / workpeace) the arc is started.
This means that the torch head tip (shield) which is electrically connected to the workpeace can't be used for ohmic sensing because it's alrerady connected to the workpeace.
What's wrong ?

Personally I would close the feed back loop with linear encoders, this will give actual feed back position, with a mesa FPGA this is a very well worn track with plenty of info available. Same for the spindle and encoder that also employs an index.
Sorry I'm too broke to have experience with Ethercat so really can't make a comment that maybe of use.
What kind of lathe are you working with ?
I'm kind of lucky with my Frankenstein Myford ML7\Super 7 in that I have plenty of room for the stepper motors, the only issue was the X axis, but I was able to use 10mm ballscrew and unlike most other lathes the nut is fixed to the carriage casting rather than running under the cross slide.

And for my techno babble mate, lathes conventionally use a XZ setup, Z being the carriage and X being the cross slide.
Also very few lathes, I can't think any that the average Joe would have access to lathes that use linear rails, mostly dove tails for cross slide and top slide and either plain rectangular ways for the bed,eg Myford, rectangular single prism, think 7x14 mini lathe or dual prism for the more industrial type. These are just the ones I can of off the top of my head.

Sorry to the OP for getting a bit off track.

Have you raised an issue on GH about this?

Not yet. I would like to have somebody else confirm this first.

Thanks for the links, closer but not solved yet....

After more searching/reading it looks like the utility xinput might give me some insight as to what touchscreen driver is actually being used and then I can probably tweak the calibration.I installed xinput and get the following when I run it. 


Looks like SYNAPTICS Touch digitizer is the driver for the touch aspect on the touchscreen. I looked in /usr/share/X11, and there are 5 .conf files:
40-libinput.conf
10-radeon.conf
70-waycom.conf
10-amdgpu.conf
10-quirks.conf

None of these have a line for XAxisMapping or YAxisMapping, if they did I could  probably just change 1230 to 0123.

So I ran xinput_calibrator and touched the screen etc. and it detects the touches generates a snippet with the calibration data that I'm supposed to put in a file named 99-calibration.conf and place that file in /usr/share/x11/xorg.conf.d/ 
 
So I did that, rebooted and no change, so it looks like 99-calibration.conf is either being ignored or is in the wrong location?Any insight would be helpful.