- February 24, 2017 at 6:03 pm #28384
Ok folks. Right when I when I thought I was getting the handle on this, Ive run into a Z-Axis issue. I know the lost Z-Steps have been beat to death here. Ive previously been using Estlcam v10.xx and RC7, had the rapids set according to what was recommended and have not had one single issue.
Ive since been trying the Aspire software and yesterday carved a 2hr job with one little Z-Step mishap. I assumed it was a fluke and set out today for the real run. About 40 mins in I ruined a piece of oak as the Z-Steps went nuts. I tried again with similar results.
I thought that the RC7 firmware would limit the rapids to keep this from happening?? Any advice would be appreciated. I’m not sure how to “insert” g-code as Ive seen others mention to alter the g-code (speeds).
Ive been using the “”Emco VMC 100 ATC (mm)(*.nc)”” post processor as I read on here somewhere thats what someone was using.
Thanks in advance for the help as I cant keep wasting material.February 24, 2017 at 6:49 pm #28389
The software updates article has all this info, on the homepage. Im not at a computer right now.February 25, 2017 at 8:43 am #28402
I found a post processor that someone created for Vectric that I am currently trying. Maybe that will cure it? Fingers crossedFebruary 26, 2017 at 6:51 pm #28520
Just a quick update. The post processor I downloaded for aspire seemed to fix the z step issue. But….it appeared again this evening. It’s real sporadic. No pattern to it. *ran a 2hr job yesterday without issue*. I may try double checking the stepper voltage for the Z but it was all bought here and should be good. I’ll update if I do next anything out.
P.S. The Aspire software is awesome. Should be though. 2k for the full versionFebruary 26, 2017 at 8:03 pm #28531
Double and triple check to make it’s not trying to move Z anywhere faster than the firmware supports. Most post processors will try to move Z at the same speed as X and Y somewhere. When you send too fast of a move to Z weird things can happen. My personal thoughts are that it does a signed number overflow, changing positive numbers into negative…February 27, 2017 at 7:29 am #28571
Bill, I’ll be honest. I’m not sure where or how to look. Here is the post processor I’m using if you know what to look at. https://www.dropbox.com/s/2zchoy8q9g30yjs/Marlin_mmSafe_Z.pp?dl=0February 27, 2017 at 2:40 pm #28598
Here is my Post Processor Info If anyone can help me
+ Emco VMC 100 Vectric output configuration file
+ Who When What
+ ======== ========== ===========================
+ Mark 02/01/2009 Written
POST_NAME = “Emco VMC 100 ATC (mm)(*.nc)”
FILE_EXTENSION = “nc”
UNITS = “MM”
+ Line terminating characters
LINE_ENDING = “”
+ Block numbering
LINE_NUMBER_START = 0
LINE_NUMBER_INCREMENT = 10
LINE_NUMBER_MAXIMUM = 999980
+ Formating for variables
VAR LINE_NUMBER = [N|A|N|1.0]
VAR SPINDLE_SPEED =
VAR FEED_RATE = [F|C|F|1.1]
VAR X_POSITION = [X|C|X|1.3]
VAR Y_POSITION = [Y|C|Y|1.3]
VAR Z_POSITION = [Z|C|Z|1.3]
VAR ARC_CENTRE_I_INC_POSITION = [I|A|I|1.3]
VAR ARC_CENTRE_J_INC_POSITION = [J|A|J|1.3]
VAR X_HOME_POSITION = [XH|A|X|1.3]
VAR Y_HOME_POSITION = [YH|A|Y|1.3]
VAR Z_HOME_POSITION = [ZH|A|Z|1.3]
VAR SAFE_Z_HEIGHT = [SAFEZ|A|Z|1.3]
+ Block definitions for toolpath output
+ Commands output at the start of the file
“[N] G54 T0[T]0[T] G00
[XH] [YH] [ZH] M03″
+ Commands output for rapid moves
“[N] G00 [X] [Y] [Z]”
+ Commands output for the first feed rate move
“[N] G01 [X] [Y] [Z] [F]”
+ Commands output for feed rate moves
“[N] G01 [X] [Y] [Z]”
+ Commands output at toolchange
“[N] G00 Z40.000 X0.000 Y10.000 M00”
“[N] T0[T]0[T] G00 [ZH] [XH] [YH] M00”
+ Commands output for a new segment – toolpath
+ with same toolnumber but maybe different feedrates
“[N] G00 [SAFEZ]”
+ Commands output at the end of the file
“[N] G00 Z40.000 X0.000 Y10.000”
“[N] G53 T0000 M30”
Thanks for any helpFebruary 27, 2017 at 8:01 pm #28615
Doesn’t look like that changes the RAPID_MOVE speeds from what is in your firmware, but it does use RAPID_MOVE. How do you have the firmware configured? If Z is set to defaults in a lot of cases that’s the same as X and Y and that would be assured to break randomly.February 28, 2017 at 4:00 am #28621
The firmware is RC7 taken from here. Could I add to this a couple lines to limit it? Or break up the XY from the Z speeds.
I’ve watched a few YouTube videos, enough to know what I think I need. But not sure how to implement it for me.February 28, 2017 at 4:13 am #28623
I have installed ESTLCAM V9.016 but a little different from the previous version.
I don’t know what I do for RAPID FEED. the new version does not (RAPID FEED Z).
can you help me?
Attachments:February 28, 2017 at 7:42 am #28633
You need the latest version. Download that (v10) and it will be there.February 28, 2017 at 4:37 pm #28646
Well, 600mm/min is 10mm/sec and IIRC the maximum speed for Z needs to be around 8mm/sec. Try setting the move speed for Z to the 480 shown for rapid.March 1, 2017 at 4:14 am #28669
That’s just it. I’m not sure where you are seeing the speeds. “480 shown for rapids”. I’ll edit this file, if I know what to edit. I’m clueless with this processor stuff.March 1, 2017 at 8:53 am #28677
Brian it’s shown in the picture above 222.jpgMarch 1, 2017 at 11:13 am #28684
That was another fella asking about Estlcam. I may have it. I found a youtube video that helped. I added
To the post processor and it appears to have separated the rapids for the X&Y and Z However I do still see one entry for Z at 1200.00 (haulin azz) so we’ll see.March 1, 2017 at 11:22 am #28686March 1, 2017 at 2:30 pm #28691
Ryan, this is NOT for Estlcam! I am trying to fix rapids for Vectric Aspire.
And scratch the previous post about may have it working. I still see [F] 1200.0 in the gcode. I dont know what I’m looking at but I’ve learned enough to know thats not rightMarch 1, 2017 at 2:31 pm #28692
My bad.March 1, 2017 at 2:32 pm #28693
It’s all good, I’m just getting flustered since I have no clue WTH I’l doing lol
You must be logged in to reply to this topic.