Machsupport Forum
Mach Discussion => General Mach Discussion => Topic started by: Sage on October 07, 2009, 02:13:57 PM
-
I've noticed a very annoying issue with Mach.
I've recently been using Mach as just a G-code viewer. I create G-code with a program (PCB-Gcode) then open Mach and load the file to observe the results. I then close the G-code file in Mach and modify the g-code. PCB-Gcode generates a new file but with the same name as the old one that overwrites the old file (confirmed).
When I return to Mach and load the G-code file it displays the old information not the G-code from the new file.
I've tried erasing the file from the disk before regenerating it but Mach still displays the old information.
The only way I can stop this is to exit Mach and return and open the file. An obvious pain. It then picks up the new file information.
I believe this is someting that needs to be corrected by the Mach programmer. I think there is probably a flush memory buffer function that should be issued to force Mach to clear it's cach and actually load the file contents instead of from memory.
In the old DOS days you sometimes had this problem and you could do a CTRL-C to clear the disk cach and re-log the disk drive. I'm not sure of any such think exists in Windows.
Anyone have a work around for this?
Sage
-
Never seen or heard of anyone with that problem so its very unlikely its a Mach problem.
Hood
-
Just tried it on three different computers with 5 different revisions of Mach and all work exactly as expected. Might be an idea to reinstall Mach over the top of itself to see if it clears up your problems.
Hood
-
Ok.
Short of doing exactly what I'm doing I can't suggest any way of duplicating the issue.
I'll see if I can come up with something others can try.
Sage
-
Just thinking, does the code load fully when you reload it? What I mean is do you see the path generation window pop up then dissapear and the code window goes back to the start of the file. If it is not reading it fully then it is quite likely that it will display the previous toolpath.
Hood
-
Yes it seems to load the file fine and the tool path updates fully. I even tried regen again. Same thing.
I've never seen this before either. I tried to simulate by making two files, one a copy of the other except for one G-code difference.
I saved them in separate directories so they could have the same name.
I loaded one in Mach and looked at it. Then unloaded it. In explorer I copied the other one over the original.
I loaded the file again in Mach but it was fine and showed the changes.
Not sure if this is exactly what goes on with what I was doing. Could be the operations are handled differently by Windows.
I guess I'll forget it for now.
I'm getting good at shutting down and starting up Mach. anyway. Once I get the PCB-Gcode parameters figured out as to what they affect in the G-code hopefully I won't have to do it much.
Thanks for your help and quick response Hood.
Sage
-
That is weird, how about making the changes then opening the file in Notepad before reloading it in Mach, does that make it correct or is it still wrong?
Hood
-
Doesn't help.
Here's the steps I followed.
Generated the G-code file in Eagle with PCB-Gcode then loaded it in Mach. Noted toolpath display.
Closed the file in Mach keeping mach open.
Generated the new file with different parameters.
Loaded it in Mach noted it had not changed.
Closed it in Mach. Kept mach open.
Opened it in notepad (can't tell one from another in notepad it's a huge file)
Closed it in notepad.
Opened it in Mach. Still the same old file.
Closed Mach all together.
Restarted Mach
Opened the flle - it's the new one.
Beats me. I can't duplicate it with any other operation. Maybe Eagle messes up Mach. Still smacks of some sort of memory cache problem. Where else would Mach be getting old information.
Sage
-
I have never seen this either. Only thing I can think of is directories not being right.
Brett
-
Not sure what your thinking is with that. It's not like Mach is picking up an old file 'cause it's looking in the wrong place or anything. It finds it fine as long as you close mach and open it again.
In any case I'll remember the issue and if I come across it again under different circumstances I'll test it some more. I've moved on for the moment.
Sage
-
Do me a favor. Open the code in Mach and leave it open. Then go into PCB G-code and make a change and save it. See if it will let you save it while it is loaded in Mach.
Brett
-
I have never seen that behavior.
New one to me also.
RICH
-
HMM...
Close both appications. Do a Windows search of the file name. There should only be one file in one location with that name. If there are more than one get rid of the others.
RICH
-
I tried your suggestion.
If the file is open in Mach then PCB-Gcode gives an error - access denied...
I would have expected this since Mach does need to open the file and presumably it keeps it open - locking it just in case you want to edit it or something.
The problem comes when you close and then re-open it. Mach apparently reads it from memory, not from the file the second time around (as already detailed previously).
Anything else you'd like to try. (tomorrow) ?
Sage
-
There is only one file with that name. It's in my Eagle projects directory. When I open Mach it defaults to the last place you got files from which is at the moment is the same Eagle directory.
As mentioned it's not like Mach is picking up the wrong file every time (i.e looking in the wrong place at the wrong file). It's quite happy to open the updated file as long as you exit Mach and return.
Thanks to all for helping.
Catch you tomorrow. I have to sleep on it for a while.
Sage
-
Ok one last thing for tonight.
I forgot that the files have a date and time stamp in the G-code header.
I noticed that Mach IS loading the latest file.
But I had always been using the big toolpath display (you get when you press the toopath button) because I have to zoom in a lot to see the artifact I'm changing settings to get rid of and it's easier to see.
In any case if I zoom in on the little toolpath display it is fine.
The big tool path is the one that does not seem to pick up the changes. Maybe it's caching old information. The two displays are different.
Even though the small toopath does go blank and appear to refresh when you load the new file. I guess the big one is not.
If I do a regen while on the big tool path it updates to the new file as well.
I thought I'd tried the regen before with no help but I've been back and forth so much I might have gotten confused what I was supposed to see.
In any case it does seem to be a big toolpath display refresh/caching problem.
Sage
-
Hood:
There is a minor problem with Mach (as mentioned above). The big toolpath display seems to be fooled by file changes.
Try this. It exhibits the problem for me.
Take a G-code file and copy it to another file with a slightly different name (so they can co-exist in the same directory).
Edit the second file so it does something obviously different that can be seen in the toolpath. Try not to make the file too much bigger though.
Start Mach and load the first file into Mach and display it on the big toolpath display.
Go back to the main Mach page and "close G-code". Keep Mach running.
Go to a new windowand with windows explorer rename the first file (the one you just open in Mach) to sometihng else and rename the second (modified file) to the same name as the first file was.
Go back to the Mach window and load the modified G-code file (which now has the same name as the original file loaded into Mach).
In the main page toolpath you should see the modified file toopath fine.
If you switch to the big toolpath display you will still see the original file displayed instead of the new one.
A regen will update the display to the new file.
This displays the problem every time for me. It's not a big deal but I feel that if you close a G-code file it should clear it out of the whole program and should not be lurking inside the program somewhere.
Just another small thing to add to the list (please).
Sage
-
Do you have the driver installed?
-
Just tried doing exactly what you said and it works perfectly for me, Ger may be on to something re the driver if you are just simulating.
Hood
-
Hello all,
I think, I also noticed this phenomenon in the past:
After modifying the G-Code file (even from inside Mach3 with the "Edit" button) the small toolpath window refreshes automatically and shows the changed toolpath, but the big one does not. You have to refresh it manually to see the contents correctly.
Might this behave different depending on graphics board in the PC? (I don't have an idea, as I don't know how and where the toolpath displays are generated.)
Maybe this point should be on the task-list for revision 4.
Konrad
-
No I don't have the driver installed. This is just my "sit in front of the TV and write code machine". I haven't checked it out on my production machine. What is your line of thinking as to why it matters?
Enough said I guess.
I'm just pointing it out because for the programmer it's probably going to be obvious why this happens (or doesn't) and just as easy to fix it.
Just trying to make Mach as good as possible by pointing out the oddities.
Sage
-
HMM....
Never even noticed what your saying since i always do a refresh of the screen post any change.
Must be getting old and not as observant as in my younger days! ;D
I'll look for it now. ;)
RICH
-
Some people have reported that if they are using Mach in simulation and no driver is installed that they get weird things happening, I personally have never seen this when I deliberately deleted the driver to test. Best thing is just install the driver, it should do no harm even if you do not have anything connected to the computer, all my computers have the driver installed, even ones without a parallel port.
Let us know if it fixes it.
Hood
-
Well it appears to be one in the same problem that others have alreay reported i.e. the toolpath display is not always correct and needs to be refreshed.
I guess some refresh as a matter of normal operation (presumably because they see it doesn't look right) and don't think twice about the fact that it should not be wrong in the first place.
I guess I'm just ponting out that the toolpath display is incorrect quite often.
We can all just keep pressing the button and be done with it or we can request that the programmer have a look and possibly fix a simple oversite such as forcing a refresh everytime the toopath display is activated.
Just trying to make suggestions for improvement here.
(I don't suppose anyone is compiling a list of the little bugs that get noticed from time to time ?? :-\ )
Sage
-
Well it appears to be one in the same problem that others have alreay reported i.e. the toolpath display is not always correct and needs to be refreshed.
us
I guess some refresh as a matter of normal operation (presumably becuse they see it doesn't look right) and don't think twice about the fact that it should not be wrong in the first place.
I guess I'm just ponting out that the toolpath display is incorrect quite often.
We can all just keep pressing the button and be done with it or we can request that the programmer have a look and possibly fix a simple oversite such as forcing a refresh everytime the toopath display is activated.
Just trying to make suggestions for improvement here.
(I don't suppose anyone is compiling a list of the little bugs that get noticed from time to time ?? :-\ )
Sage
Given the massive changes being made to the basic structure of the code for the up-coming v4 release, in particular the de-coupling of the display code from the main motion code, this problem has, in all probability, already been fixed.
Regards,
Ray L.
-
No I don't have the driver installed. This is just my "sit in front of the TV and write code machine". I haven't checked it out on my production machine. What is your line of thinking as to why it matters?
A lot of things don't work correctly without the driver installed. When I was making a screenset and testing it on my laptop without the driver, I had numerous problems. After installing the driver, everything worked fine.
-
That in itself is an issue. I don't suppose those items got added to the list (if there is one)?
The only way to move forward is to log all of the current issues and make steps to correct/avoid them in the future. This could actually save time in the process by not having to go back and fix problems.
BTW
A re-write doesn't guarantee correction of any of the existing issues especially if you don't know what they all are.
Sage
-
Some functions need the driver to operate correctly. Just install the driver, and see if it works. My laptop isn't capable of running a machine, as the pulses are way too rough. But it works fine for testing with the driver installed.
-
As metioned Im seeing the problem on my G-code development laptop which doesn't even have a parallel port. I don't want to bog it down with a driver that does nothing.
Enough said on this topic. I'll just keep pressing the regen button.
Sage
-
This has been an issue for me for more than three years on a PC dedicated and connected to my router. The PC runs nothing but licensed Mach3 v2.63(I think). I seem to get edits in the body of the G-code, but if I add a line forget it. You can open the files, close the files, rename the files, shut down Mach3, run CCleaner to get rid of all temp files, reboot the computer and sacrifice a goat but that line you added will never appear. I always figured it was an amusing little Mach3 quirk.
-
If you add a line of g-code to the end of the file, you must hit enter after the line or it won't show up in Mach3. Mach3 needs to see the carriage return.
-
Thanks! Sheesh, I can't count how many months I haven't used the edit code function because I didn't know that. I only had the code window freak out on me as described by the other folks here once and it went away after a reboot and dump of that code file.
Now I just have to figure out how to prevent my machine from intermittently trying to force the entire spindle through the spoilboard. Not a Mach3 issue - I suspect hardware.