On 9 December 2013 16:24, Sebastian Kuzminsky wrote:
> As Erik Christiansen said, these are relics from when we used CVS to
> track our repository. I think they should be removed from all our ini
> files, and I will gladly accept a patch against master to do so.
Or... They could be used to indi
On 12/8/13 09:12 , andy pugh wrote:
> The INI Files all seem to contain this:
>
> [EMC]
> # Version of this INI file
> VERSION = $Revision$
>
> I have no idea what that means, or what it is used for.
As Erik Christiansen said, these are relics from when we used CVS to
track our repo
On 08.12.13 16:12, andy pugh wrote:
> On 2 December 2013 16:02, Kent A. Reed wrote:
> > A common trick in other arenas has been to introduce this kind of
> > metadata retrospectively as a comment header
Some version control systems provide automated handling of quite a
variety of metadata.
> The
On 2 December 2013 16:02, Kent A. Reed wrote:
> One of the things which has long annoyed me is that our configuration
> files (INI as well as HAL) do not include a version number which in some
> way corresponds to the version of LCNC against which they were written.
> A common trick in other are
> From: mai...@mah.priv.at
> Date: Mon, 2 Dec 2013 17:15:30 +0100
> To: emc-users@lists.sourceforge.net
> Subject: Re: [Emc-users] INI Tricks
>
>
> Am 02.12.2013 um 15:42 schrieb andy pugh :
>
> > On 2 December 2013 13:23, Charles Steinkuehler
> > wrote
Am 02.12.2013 um 15:42 schrieb andy pugh :
> On 2 December 2013 13:23, Charles Steinkuehler
> wrote:
>
>> Perhaps with the hacking taking place on motion and the path planner and
>> whatnot, these can migrate to HAL where it seems like they belong.
>
> Doing that will break every single exist
On 12/2/2013 9:42 AM, andy pugh wrote:
> On 2 December 2013 13:23, Charles Steinkuehler
> wrote:
>
>> Perhaps with the hacking taking place on motion and the path planner and
>> whatnot, these can migrate to HAL where it seems like they belong.
> Doing that will break every single existing config
On 2 December 2013 13:23, Charles Steinkuehler wrote:
> Perhaps with the hacking taking place on motion and the path planner and
> whatnot, these can migrate to HAL where it seems like they belong.
Doing that will break every single existing configuration. (Unless the
new HAL pins take the rathe
On 12/1/2013 9:47 PM, John Kasunich wrote:
>
>
> On Sat, Nov 30, 2013, at 04:22 PM, andy pugh wrote:
>
>> You can always change PID settings (and anything else which is a HAL pin or
>> parameter) on the fly. You just either have to use the command line, or
>> make your own GUI.
>>
>> The explan
On Sat, Nov 30, 2013, at 04:22 PM, andy pugh wrote:
> You can always change PID settings (and anything else which is a HAL pin or
> parameter) on the fly. You just either have to use the command line, or
> make your own GUI.
>
> The explanation as to why things like max velocity and axis accel
On Sunday 01 December 2013 09:54:22 Charles Steinkuehler did opine:
> On 12/1/2013 8:13 AM, Gene Heskett wrote:
> > On Sunday 01 December 2013 09:09:19 Stuart Stevenson did opine:
> >> Doesn't the AXIS interface have a tuning module to allow you to tune
> >> without restarting? It even allows you
On 12/1/2013 8:13 AM, Gene Heskett wrote:
> On Sunday 01 December 2013 09:09:19 Stuart Stevenson did opine:
>
>> Doesn't the AXIS interface have a tuning module to allow you to tune
>> without restarting? It even allows you to save in the INI file.
>
> As of a recent 2.5.3, Scale values only for
On Sunday 01 December 2013 09:09:19 Stuart Stevenson did opine:
> Doesn't the AXIS interface have a tuning module to allow you to tune
> without restarting? It even allows you to save in the INI file.
As of a recent 2.5.3, Scale values only for a stepper system. I suppose
since its for servo's,
Doesn't the AXIS interface have a tuning module to allow you to tune
without restarting? It even allows you to save in the INI file.
On Nov 30, 2013 3:25 PM, "andy pugh" wrote:
> On 30 November 2013 20:20, Marius Liebenberg
> wrote:
>
> >
> > The idea of dynamic parameters is what we would be lo
On 30 November 2013 20:20, Marius Liebenberg wrote:
>
> The idea of dynamic parameters is what we would be looking for. I will
> support that notion as it is very frustrating having to restart the
> system constantly. Some parameters like PID tuning / servo parameters
> are done on the fly if you
On 30 November 2013 20:04, Charles Steinkuehler wrote:
>
> So why *ARE* some machine constants in the INI file while others live in
> HAL? Couldn't motion just export a bunch of HAL parameters that get set
> like anything else
I don't know. At least one user was wanting HAL-variable accellerati
Charles
The idea of dynamic parameters is what we would be looking for. I will
support that notion as it is very frustrating having to restart the
system constantly. Some parameters like PID tuning / servo parameters
are done on the fly if you use the calibration function. I don't see why
that
On 11/30/2013 1:28 PM, Dewey Garrett wrote:
>
> I think modularity is a good thing and will plug the option for
> twopass processing that can be specified in an ini file as:
>
> [HAL]
> TWOPASS=[on][verbose][nodelete]
Again, my issue is not with HAL, but with the INI file itself. I can
alre
I think modularity is a good thing and will plug the option for
twopass processing that can be specified in an ini file as:
[HAL]
TWOPASS=[on][verbose][nodelete]
With twopass processing, you can loadrt a given comp type
in more than one file. If one uses twopass processing _and_
the names=
>
> Hi. sorry, couldn't resist my five cents as not-developer but long time
> industrial player.
>
Either could I :)
> I hate parameters distributed in lots of " you just have to know them files".
>
> One "collecting" place like the ini of lcnc is what i love and use extensive.
>
I like it
On 30 November 2013 15:50, Mike Eitel wrote:
> Never needed it, but can't there be added a [MYSPECIALVARS] section?
You can add any custom sections that you want, called anything you
want, and references to them in the HAL files will work, as will calls
to inifile.find in Python code etc.
You ca
Charles Steinkuehler writes:
>
Hi. sorry, couldn't resist my five cents as not-developer but long time
industrial player.
I hate parameters distributed in lots of " you just have to know them files".
One "collecting" place like the ini of lcnc is what i love and use extensive.
Never needed
On 11/29/2013 7:53 PM, andy pugh wrote:
> On 30 November 2013 01:45, Chris Radek wrote:
>
>> I don't understand what you're saying - is this a reply to Charles's
>> original question or to my quoted paragraph?
>
> I couldn't find an ideal context paragraph to quote to make my point.
> And I am p
On 11/29/2013 7:28 PM, Chris Radek wrote:
> On Fri, Nov 29, 2013 at 05:27:17PM -0700, Sebastian Kuzminsky wrote:
>>
>> I think a #include-like directive would be both useful and easy to
>> implement, but i'm not volunteering to do it. ;-)
>
> I think this might be barking up the wrong tree: a tr
On 30 November 2013 01:45, Chris Radek wrote:
> I don't understand what you're saying - is this a reply to Charles's
> original question or to my quoted paragraph?
I couldn't find an ideal context paragraph to quote to make my point.
And I am programmed to always quote something.
The point was
On Sat, Nov 30, 2013 at 01:35:55AM +, andy pugh wrote:
> On 30 November 2013 01:28, Chris Radek wrote:
>
> > Paradoxically, the more intricate you make the ini and hal languages
> > with the goal of "ease of use", the harder it is for the gui
> > programs to handle (especially read and rewrit
On 30 November 2013 01:28, Chris Radek wrote:
> Paradoxically, the more intricate you make the ini and hal languages
> with the goal of "ease of use", the harder it is for the gui
> programs to handle (especially read and rewrite) them, the more
> brittle those programs get,
FWIW I can't really
On Fri, Nov 29, 2013 at 05:27:17PM -0700, Sebastian Kuzminsky wrote:
>
> I think a #include-like directive would be both useful and easy to
> implement, but i'm not volunteering to do it. ;-)
I think this might be barking up the wrong tree: a tree that only
you and your fellow programmers can s
On 11/29/2013 6:27 PM, Sebastian Kuzminsky wrote:
> On 11/29/2013 04:46 PM, Charles Steinkuehler wrote:
>> I know about the HAL options, I was wondering if there's any way to do
>> something similar with the INI file itself.
>
> There's not.
>
> I know because i wanted the same thing when i was
On 11/29/2013 04:46 PM, Charles Steinkuehler wrote:
> On 11/29/2013 3:30 PM, Jon Elson wrote:
>> Charles Steinkuehler wrote:
>>> I'm wanting to create modular LinuxCNC configurations to allow for easy
>>> modification by folks new to LinuxCNC. I can do fancy tricks with tcl
>>> for HAL files, but
On 11/29/2013 3:30 PM, Jon Elson wrote:
> Charles Steinkuehler wrote:
>> I'm wanting to create modular LinuxCNC configurations to allow for easy
>> modification by folks new to LinuxCNC. I can do fancy tricks with tcl
>> for HAL files, but that doesn't let me update anything in the [TRAJ] or
>> [A
Charles Steinkuehler wrote:
> I'm wanting to create modular LinuxCNC configurations to allow for easy
> modification by folks new to LinuxCNC. I can do fancy tricks with tcl
> for HAL files, but that doesn't let me update anything in the [TRAJ] or
> [AXIS ] *.ini file sections.
>
> So is there a w
I'm wanting to create modular LinuxCNC configurations to allow for easy
modification by folks new to LinuxCNC. I can do fancy tricks with tcl
for HAL files, but that doesn't let me update anything in the [TRAJ] or
[AXIS ] *.ini file sections.
So is there a way to do similar tricks with the actual
33 matches
Mail list logo
