Open terrylm opened 7 years ago
I think that step 4 (clicking the toolbar icon) is actually unnecessary to produce this behavior. At least I've been unable to think of a reason why it would actually influence the outcome...
I don't know what guarantee LinuxCNC has ever offered when the part program is changed between the time it is opened and when it is run (and it's entirely possible that some other internal changes in LinuxCNC have impacted this behavior; different editor programs could potentially cause different behavior in LinuxCNC as well, depending whether they overwrite the original file in place, or remove the original file and replace it with a fresh copy of the newly-written file).
If you prefer that edits are NOT seen without a "reload" command, then I think there's a workaround that will work as long as you're using the AXIS UI . It is a trick that uses the "filter" feature of AXIS UI. (some other UIs may support this feature, but I didn't check any of them)
Say you prefer to use the ".ngc" extension for your part programs, find the [FILTER]
section in your inifile and add the line ngc = cat
. (cat
is a unix program that reads a file of input and produces the same file as output) When you do this, the actual part program that LinuxCNC loads is in effect a copy of the original, and any edits to the original file won't be reflected. You can list as many extensions as you like, so you could also put gcode = cat
, nc = cat
, etc., for any extension you think you are likely to encounter.
Hi Jepler
You are correct, no need to click the broom. I will use cat as you suggest. Thanks
It does still seem to me to be a bug though. If it is going to reread the file, then the code displayed should also be updated.
Here are the steps I follow to reproduce the issue:
This is what I expected to happen:
I would expect that the displayed code would be run, not the file on disk that no longer matches the displayed code.
This is what happened instead:
See above
It worked properly before this:
Had linuxcnc 2.5.4, did clean install of 2.7.4, installed latest updates, now at 2.7.8. The issue did not exist in 2.5.4, I am sure I would have noticed. It started after installing 2.7.4 and continues in 2.7.8.
Information about my hardware and software:
I used the iso image provided, so it is the standard out-of-the-box install.
uname -a
): Linux mill 3.4-9-rtai-686-pae #1 SMP PREEMPT Debian 3.4.55-4linuxcnc i686 GNU/Linux On an old Pentium 4 that is only used for my mill.scripts/get-version-from-git
): 1:2.7.8This might be related to issue #200? Seems probably not related.