In Dewey Garrett writes:
>creates user configs in ~linuxcnc that are flat. Moreover,
corection: i meant ~/linuxcnc of course
--
Dewey Garrett
--
Check out the
The configs directory is multilevel but pickconfig
creates user configs in ~linuxcnc that are flat. Moreover,
soft links within the configs tree support testing
within both RIP builds and deb installs using the
same set of files.
This maintainer.txt file has more detailed information:
On Fri, Sep 01, 2017 at 04:36:35PM +, Dewey Garrett wrote:
>
> > The machine next to it is running version 2.5.4,
> > and does reference the nc_files folder for gcode
> > files. I checked the ini file for any other
> > reference to nc_files, and no other instances
> > exist.
>
> This commit
> The machine next to it is running version 2.5.4,
> and does reference the nc_files folder for gcode
> files. I checked the ini file for any other
> reference to nc_files, and no other instances
> exist.
This commit altered file opening (5 years ago):
Jeff,
The machine next to it is running version 2.5.4, and does reference the
nc_files folder for gcode files. I checked the ini file for any other reference
to nc_files, and no other instances exist.
Regards,
Eric
On September 1, 2017 10:29:05 AM EDT, Jeff Epler
On Fri, Sep 01, 2017 at 09:21:42AM -0400, Eric H. Johnson wrote:
> Dewey,
>
> So is PROGRAM_PREFIX in the DISPLAY section getting ignored? I previously set
> it to:
to the best of my knowledge, PROGRAM_PREFIX has never been used by
task for opening part programs with relative paths. If I'm
Dewey,
So is PROGRAM_PREFIX in the DISPLAY section getting ignored? I previously set
it to:
/home/emcuser/linuxcnc/nc_files
Then would require no path when specifying the nc file name in open.
Thanks,
Eric
On September 1, 2017 8:44:19 AM EDT, Dewey Garrett wrote:
>
>
>set open c.ngc <-- relative (to ini dir) pathname
--
Dewey Garrett
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
Dewey,
Ok, I got fooled, the absolute path is working. The problem is linuxcncrsh
returns an ack even if the does not open, and axis, which I am also running for
startup purposes, does not update the display for the opened file (except in
the heading).
The previous version also worked with a
On 1 September 2017 at 02:31, Eric H. Johnson wrote:
> The open command is not working for me in linuxcncrsh (set open name>), which should open a gcode file. I have tried prefixing various
> paths, including the complete fully qualified path to the nc file, but keep
>
linuxcncrsh (emcrsh.cc) has had little maintenance
except for updates for joints_axes and those have
not (intentionally) altered file opening.
I did some experimenting using a run-in-place (RIP)
build of the master branch at commit:
a7aeaa6 Tue Aug 29 09:25:23 2017 -0700
Procedure:
I use
All,
Forgot the version, this is in lcnc 2.8.0-pre1.
Regards,
Eric
All,
The open command is not working for me in linuxcncrsh (set open ), which should open a gcode file. I have tried prefixing various
paths, including the complete fully qualified path to the nc file, but keep
getting a file
All,
The open command is not working for me in linuxcncrsh (set open ), which should open a gcode file. I have tried prefixing various
paths, including the complete fully qualified path to the nc file, but keep
getting a file not found error. The code in shcom.cc that specifies the file
is as
13 matches
Mail list logo