Advanced Search

@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. 

Hi guys,

Is there any documentation yet for a carosel atc? Or dose pb use the standard lcnc tool change? 

Also I have dc motors on my atc that use pwm can thesr be used or do i need steppers? 

Aciera wrote:

I might have found a clue as to what causes this problem with G33.


 

Thank you so much for confirming the behavior I saw, and for the workaround guidance.

Have you raised an issue on GH about this?

NOTE: It'll be a bit before I can test this on my lathe as the 2nd motor I was planning to use turned out not to work.  So I threw money at the problem and have to rearrange my electrical cabinet to fit a significantly larger drive.  Re-wiring seems to take me an eternity.

Thanks Chris, that's going to take a bit of study for me to break it down. Pretty cool stuff.

JT

Hi Meiser,

That could only done by ./build_cmake script

# flush build dir
rm -rf *

Hmm. That script is designed by Joco. But i take responsebility for it.
I know also from previous years, that this can indeed remove things you dont want to.
I experienced the same years ago, in a moment i lost my entire home dir content.

Will remove the rm in all scripts now. Sorry Meiser.

@Arciera,

The abstract proposes forward transformation (projection) to the xz plane.
Indeed the problem does not arise when there is no z value.
And yes we are directly fitting in 3d space.

The problem isn't there, when you do a plane fit. This is in fact a 2d fit solution in 3d space,
including forward & inverse transformation steps. We did this using the 2d clothoid lib in our
previous planners.

Maybe we can think about this problem and how to solve it using a 3d space fit.

You can state that this is a clothoid wich makes a full torsion turn, wich has no reason to do so.

• I think the ceres is giving it a initial torsion value, and goes on with the torsion during fit iterations until a endpoint fit is found.
• Why does it use this full torsion only in certain space corner directions? Is there a reason we don't know yet?
•  

@Mennil,

The clothoid3d uses a non-linear solver to find the xyz endpos for the clothoid fit.
The solver will iterate to the desired endpoint in shortest way, naturally.

It's very unlikely for the ceres solver to give us a self intersecting result as shown in your picture,
unless we give incorrect input angles.

And it's unlikely we have infinite solutions regarding the 4-clothoid-spline fit.

 

The codebase ruled out self intersecting clohoids by making improvements to the abstract:  Abstract bug fixes

1. In eq45, page 7, the Delta Theta is calculated by: Thetai4 - Thetai0.
   The clothoid Delta Theta produced by this substraction, is not alway's correct.
   When the incorrect value is used, it shows a self intersecting clothoid. Eq.45 input Angles are in the range [0,-2pi], [0,2pi]. Substraction can lead to a incorrect
   Delta Theta. To solve this issue, we convert back the thetai[x] into a xy vector.
   From here the signed angle between 2 vectors is calculated.
   
   This ensures a correct Delta Theta value. Problably this is also the reason why in the abstract forward & inverse transformations are used.
   In this codebase forward & inverse transformations are obsolet

Also note that [JOINT_4] FERROR=10 and MIN_FERROR=1 may seem a bit large but are due to a lag in the simulated encoder feedback from the Mitsubishi controller I use here.