On Friday 22 November 2019 20:07:22 Gene Heskett wrote:
> On Friday 22 November 2019 19:07:33 Dmitry Yurtaev wrote:
> > > This all sounds as if its is only applicable to servo systems, us
> > > hobbyists with steppers running everything might as well sit back
> > > and enjoy the "what ifs" since
> Can you try the RTAI kernel?
> wget http://www.linuxcnc.org/temp/linux-image-4.14.148-rtai-amd64.deb
oops, sorry, missed that. i mean i did try the rtai-patched kernel before...
but anyway. can't repeat it on N3150 now, used i7 M 620 instead, debian 9
it boots, hangs for a while with a blank
On Friday 22 November 2019 19:07:33 Dmitry Yurtaev wrote:
> > This all sounds as if its is only applicable to servo systems, us
> > hobbyists with steppers running everything might as well sit back
> > and enjoy the "what ifs" since steppers have their own
> > insurmountable jerk problems when
On Friday 22 November 2019 18:50:39 Herzog Raoul wrote:
> dear Gene,
>
> I agree with you, OpenCN is not meant for stepper motor applications,
> since there is no feedback control using encoders.
>
And unmentioned, but even more important is the fact that what feedback
we have is quantized at
>
> This all sounds as if its is only applicable to servo systems, us
> hobbyists with steppers running everything might as well sit back and
> enjoy the "what ifs" since steppers have their own insurmountable jerk
> problems when useing common $40 50 volt drivers, and mesa cards.
>
but us
dear Gene,
I agree with you, OpenCN is not meant for stepper motor applications, since
there is no feedback control using encoders.
In my application I even use "dual feedback" with a rotary encoder on the motor
axis, AND a linear encoder for each axis !
I'm definitely working in a high end
On Friday 22 November 2019 18:01:41 Herzog Raoul wrote:
> dear Nicklas,
>
> a given DC bus voltage for the drives is indeed *one* reason why the
> jerk *must* be limited, otherwise excessive tracking error occurs. But
> another reason for jerk control is to avoid machine vibration.
>
> best
dear Nicklas,
a given DC bus voltage for the drives is indeed *one* reason why the jerk
*must* be limited, otherwise excessive tracking error occurs.
But another reason for jerk control is to avoid machine vibration.
best regards,
Raoul
-Message d'origine-
De : N
Envoyé : vendredi
dear Nicklas,
of course, feedforwards are utilized (and well parametrized) in the *drives*,
otherwise excessive tracking errors appear.
But this is done in the *drive*, *not* in OpenCN.
OpenCN calculates physically realizable setpoint values (according to "optimal
control theory").
Since the
According electric motor equations commonly available jerk is controlled by
voltage and could be changed instantly which in practice is within one
switching period while acceleration --> velocity --> position is integrated in
some way from jerk. Velocity will for example add a back-emf changing
On Fri, 22 Nov 2019 21:59:33 +
Herzog Raoul wrote:
> dear Andrew,
>
> thanks for your positive feedback.
>
> There were many reasons for us to develop OpenCN :
>
> 1) of course scientific curiosity ... I'm working for ~8 years in this field
>
> 2) but, more important, I had and have
dear Robert,
thanks for your positive feedback !
I'll try to answer most of your questions :
1) licence
Good point !
We have here a campus licence for the whole Matlab suite, as most universities
have.
I asked my Mathworks contact person whether the generated C code is compatible
with GNU
dear Stevenson,
LinuxCNC lacks jerk control and "G^2 blending".
Without jerk control, the tangential acceleration jumps, without G^2 blending,
the normal acceleration jumps.
Both lead to an excitation of machine vibrational modes ... leading to bad
surface quality.
No problem for hobbyist
Just for my education would you tell me where LinuxCNC is so far behind
today's commercial CNC controls?
On Fri, Nov 22, 2019, 4:01 PM Herzog Raoul wrote:
> dear Andrew,
>
> thanks for your positive feedback.
>
> There were many reasons for us to develop OpenCN :
>
> 1) of course scientific
No need to explain in detail. Just the general areas would be fine.
On Fri, Nov 22, 2019, 4:01 PM Herzog Raoul wrote:
> dear Andrew,
>
> thanks for your positive feedback.
>
> There were many reasons for us to develop OpenCN :
>
> 1) of course scientific curiosity ... I'm working for ~8 years
dear Andrew,
thanks for your positive feedback.
There were many reasons for us to develop OpenCN :
1) of course scientific curiosity ... I'm working for ~8 years in this field
2) but, more important, I had and have customers having problems with surface
quality as feedrate increases.
I'm
Dear Raoul,
I truly admire your and your team's efforts.
Let me ask you about the purpose of OpenCN. Why did you decide to create it?
Was it mostly for science or you have immediate use for it?
Sincerely,
Andrew
пт, 22 лист. 2019 о 09:48 Herzog Raoul пише:
> dear Linux developers,
>
> I'm
dear Nicklas,
there is not "somewhere someone" who wrote "a" PhD thesis about trajectory
planning, but over the last 20 years you will easily find >100 thesis about
this subject !
It took us a considerable amout of time to understand and categorize them ...
Qt : yes the new GUI is written in
> dear Linux developers,
>
> I'm pleased to announce a new fork of LinuxCNC, called "OpenCN* :
Forking must be a disadvantage if some stuff must be left out but as you said
it is a major rewrite so ...
>
> OpenCN is an open source numerical control (CNC) for high end machining
> applications
Hi Raoul,
That's impressive work! Thanks for sharing it with all of us. It's been a
long-standing goal for us to support limited-jerk planning and smoother
blends. It's a major achievement to both create G2-continuous blends and
optimize the overall feedrate, and I'm excited to see your future
dear Les,
the modifications we had to introduce to LinuxCNC are very substantial, mainly
due to
1) the fact that we use a minimalistic, highy patched Xenomai, where we can
dedicate processor cores to specific tasks (asymmetric multiprocessing (AMP)).
2) the fact that the trajectory planning
Hi Raul,
Why create a fork? Maintaining a project like this is a huge amount of
work and forking often results in a lot of duplicated work. LCNC is very
modular so it is possible to add a lot of functionality without breaking
existing code. If you work with the LCNC project you have access to
On Friday 22 November 2019 02:32:50 Herzog Raoul wrote:
> dear Linux developers,
>
> I'm pleased to announce a new fork of LinuxCNC, called "OpenCN* :
>
> OpenCN is an open source numerical control (CNC) for high end
> machining applications (high dynamics, high precision).
>
Hardware
23 matches
Mail list logo
