![]() | |
| Home Page | Mark Forums Read | Today's Posts | My Replies | Classifieds | Reviews | Photo Gallery | Web Links | Share Files | Advertise With Us | Ad List |
| |||||||
| NCPlot G-Code editor / backplotter Discuss NCPlot software here. |
![]() |
| | LinkBack | Thread Tools | Search this Thread | Display Modes |
|
#1
| |||
| |||
Hi Scott, We have been having some funny results when plotting G84 tap cycle. I think the problem is when G84 is issued without an 'R' value. Does NCPlot store system variables after closing application? , It seems if you don't pass an 'R' value, it remembers what it was last time you did.See below i modified G840.prg to try and correct problem. (G840.PRG) #32=#5023 #33=#4203 IF [#18 NE #0] THEN G90 G0 Z#5102........was G90 G0 Z#5102 G1 Z#5101 F#9 IF [#4210 EQ 99] THEN G0 Z#5102 IF [#4210 EQ 98] THEN G0 Z#32 G#33 M99 (G84 - Forward Tap Cycle) (G84 X_ Y_ Z_ R_ F_) (X #24 X hole location) (Y #25 Y hole location) (Z #26 Finish depth) (R #18 Rapid plane) (F #9 Feedrate) Cheers Turner. |
|
#2
| ||||
| ||||
| Hi Turner, By default NCPlot does store all variables on exit. However, you can turn this off on the Preferences dialog. Just uncheck the setting that says "Save Variables On Exit". This also disables re-loading of the variables on the next startup. Can you explain in a little more detail what it is you're seeing? Do you only see the problem after first starting up NCPlot, or is it in any G84 block that doesn't include an "R" value? How does your control handle it? Thanks, Scott |
|
#3
| |||
| |||
| Hi again scott, sorry for the wait been really busy. Here is a snippet of program run on a haas ------------------------------ T1 M06 G43 H1 M08 G00 X20. Y0. S500 M03 G00 Z55. G84 Z50.0F500 X40. G80 G00 Z150. M1 ------------------------------ this sample program when plotted on haas config moves to X20. Y0. Z55. then moves to X20. Y0. Z0. then cuts to X20. Y0. Z50. on the haas machine the control moves to X20. Y0. Z55 then cuts to Z50. it seems to alway plot to Z0 first maybe i have'nt spotted the problem until we did this job that was cutting in Z+ Thanks Turner |
|
#4
| ||||
| ||||
| Turner, I think I understand what's going on, but if it's not too much trouble I'd like you to run a quick test for me: ----------------------- T1 M06 G43 H1 M08 G00 X20. Y0. S500 M03 G00 Z60. G84 Z50.0 F500 X40. R55. X60. G80 G00 Z150. M1 ----------------------- I'd like you to run this program for me twice. Each time make a note of the sequence of motion for each of the three holes. Thanks, Scott |
|
#5
| |||
| |||
| Hi Scott, I have tried your test prog and i got the same results on both runs. The preferences save variables on exit is switched off did you want this on for this test? these are the resulting plot moves G00 X20.Y0.Z60. G00 Z0. G01 Z50. G00 Z60. G00 X40.Y0.Z60. G00 Z55. G01 Z50. G00 Z60. G00 X60.Y0.Z60. G00 Z55. G01 Z50. G00 Z60. G00 Z150. While im here i have another question regarding scripting. Is there a way to return the full path of the currently opened file?. I have written a script that generates operator toolsheets using regular expressions on the nc file and then saves the file as .txt. The script needs the file name though to determine component type so toolsheet is made up with correct tooling. I got it working by using sendkeys closing ncplot reading registry value for recent file and reopening ncplot, loading file from registry value previously stored. Works fine but a long way round, and also unforgiving if anything is touched while sendkeys is running. Thanks again Turner |
| Sponsored Links |
|
#6
| ||||
| ||||
| Turner, I can add a scripting function that will return the loaded file/path, that's no problem. As for the test program, I should have been more specific. What I really wanted to know was how the Haas handles the test program I posted. I am going to run it on a Mitsubishi control and compare the two. Then I'll be able to see how it should be handled in NCPlot. Thanks, Scott |
|
#7
| ||||
| ||||
| Turner, I ran the test program on a Mits control and here's what I get. The first cycle, without the "R" value begins feeding from the current Z position, which is the endpoint of the initial rapid move. After reaching the final depth, Z retracts to the start position (Initial point return is active). The second cycle with the "R" value rapids to the R plane and then feeds to depth. After reaching the final depth, Z retracts to the start position. Any further cycles without the "R" act the same way. If I restart the program, the exact same scenario happens again. I'm pretty certain that your HAAS will do the same thing, I would just like to confirm it before I make any changes to NCPlot. Thanks, Scott |
![]() |
| Currently Active Users Viewing This Thread: 1 (0 members and 1 guests) | |
| Thread Tools | Search this Thread |
| Display Modes | |
| |
Similar Threads | ||||
| Thread | Thread Starter | Forum | Replies | Last Post |
| machine problem or software problem? | bcnc | Syil Products | 8 | 10-26-2009 10:51 AM |