[cwm9]

UPDATE

Suspected SolidCAM Bug. See post #5.


Original text

I've been trying to get solid cam to output 4 digits of precision (1/10000 inch), but no matter I do it refuses to give any x/y values more precise than 1/1000 inch...

Here's what I did. In my .GPP code I entered the lines:

numeric_def_f = '5.4'
xpos_f = '5.4'
ypos_f = '5.4'
zpos_f = '5.4'

Arc radii are in 5.4 format, but I always end up getting lines like

N36190 G0 Z0.406

instead of

N36190 G0 Z0.4064


Is there something I am doing wrong?

-cwm9

[Brakeman Bob]

Yes, try this

{nb, 'G' gcode' X' xpos:xpos_f, ' Y'ypos:ypos_f,' Z' zpos:zpos_f}

If that doesn't work, try this

' X'(xpos):'+ 5.4 (P)

[cwm9]

Sadly neither of Brakeman's changes altered anything.

I tried xpos_f = '5.4/4' and got an extra 0 trailing everything. That seems to imply that SolidCAM only calculates to 1 mil internally. I was surprised, so I tried:

xpos=xpos*10
ypos=ypos*10
zpos=zpos*10

at the front of every function as a quick double check, and sure enough I only get data in the hundredths place after that.

That seems to confirm SolidCAM has a maximum internal precision of 1 mil. I searched though the settings, but couldn't find any way to increase the resolution to 1/10 mil. I don't understand why they'd intentionally limit the precision like this.

If anyone knows a way around this, please do tell.

=(

[Brakeman Bob]

Have you tried altering the value "Rounding" in "Menu - SolidCAM - Settings - Units"? That defaults to 3 places on installation has influence on the CAM output to post processor.

[cwm9]

Have you tried altering the value "Rounding"...?

Yes, I did. No change.



UPDATE


Well, I've found a kludge solution: work in metric.

SolidCAM appears to truncate all coordinates to 3 decimal places regardless of what units you are working in.

If you work in the metric system and your coordinates are all in mm, the finest resolution you can get is .001 mm or .00004 inches.

If you work in inches, the finest resolution you can get is .001 inch.

I'm pretty sure at this point that this is a bug, and a pretty obvious one at that. Does everyone just use metric CNC? I mean, it's not like my mill is ACCURATE to 1/10 of a mil, but it can certainly resolve that, and it does make some difference in the surface quality of my small parts. OK, it's a bit picky, but come on.

You can even see the difference if you set up a 3d Milling Operation with constant-Z on the outside of a cylinder with sloping walls. Set the Z-Step to .001, and with each z-step the path should step away from the prior step since the diameter of the cylinder at that z-level is changing. If you set it to inches and zoom in you get an ungodly mess. If you set it to metric you get nice even contours.

Here's my example. First on off-axis shot of the part:



Same thing, looking straight on. I'm going to zoom in on the toolpaths to the left:



The imperial version shows contours crossing, overlapping, and uneven... what a mess!



And now the exact same imported part, with the same toolpath settings, only with SolidCAM set to work in metric units:




Here's to hoping this gets fixed at some point in a future release. Fixed point math? It's not like our PCs can't do floating point math with ease...

[Brakeman Bob]

This is intriguing. I work in metric and my post outputs to 4 decimal places if I set ROUNDING to "4".

Some questions

Were the graphics of the toolpaths created in SolidWorks or by using a backplot program? This is significant because I have had SolidWorks show me junk toolpaths at very small resolutions that when processed in CimcoEdit (and subsequently machined) were OK.

What version of SolidCAM are using and what service pack?

Have you run TRACE in the GPP file? If so, what does the raw post output show in terms of xpos etc? Also, if you are working in Imperial, is there some jiggery-pokery going on in terms of dividing through by 25.4 that is rounding the result to 3 places?

Finally, could this be a SolidWorks thing? I mean could this be a setting in SolidWorks that is rounding the co-ordinate position before it is passed to SolidCAM for processing. I am not familiar with working in SolidWorks in Imperial but I do know from creating VBA macros that in native SolidWorks in Metric coughs out 8 decimal places. So I wonder if SolidWorks is inherently metric and when set to Imperial merely multiplies / divides through by 25.4

All the best

Bob

[cwm9]

I work in metric and my post outputs to 4 decimal places if I set ROUNDING to "4".

Are you certain? I get 4 places (to the right of the decimal point) only on I and J, not X or Y. For example:

N70 G3 X12.956 Y-3.961 I-1.6664 J-5.4507

Were the graphics of the toolpaths created in SolidWorks or by using a backplot program?

By solidworks. Solidworks does produce poor quality circles and arcs, but there is also clearly some lower resolution junk going on in there. (Even the metric version shows the poor drawing capabilities of solidworks.)

...subsequently machined were OK.

The only reason I noticed was because I machined a very small part prototyping part with a very small slight vertical slope using a square end mill descending 1 mil at a time and noticed it kept going around the part over and over again without changing the diameter at all, but then would suddenly jump out and the diameter would increase. It was when I read the code that I realized that the Z-axis was going down by 1 mil but the circles around the part were identical 10 times in a row. By looking at the raw g-code I deduced this was because there were only 3 digits. That's when I started my quest to get 4 digits out of SolidCAM.

Also, if you work in metric, your parts would turn out OK because you are 25x more accurate than if you machined imperial.

What version of SolidCAM are using and what service pack?

SolidWorks 2009/SP1 (going to try updating to make sure this isn't the cause, but I very much doubt it), and the most recent SolidCAM.

Have you run TRACE in the GPP file?

Interesting thought. All three digit info, except for the resultant I and J, which now I see is because the post code is calculating from the rest of the 3 digit data supplied to it. There's a sqrt in there that's providing the extra info.

@arc ==> xpos:-5.278T ypos:6.563T zpos:10.020F feed:508.000F feed_teeth:0.127F
..> arc_direction:ccw xcenter:-2.080 ycenter:3.051 radius:4.750
..> arc_plane:xy xcenter_rel:2.156 ycenter_rel:-4.232
..> start_angle:116.995 end_angle:132.312 arc_size:15.317
..> next_direction:90.078 zstart:10.020
..> feed_type:'finish_feed' arc_feed:254.000
>
> N385 G3 X-5.278 Y6.563 I2.1561 J-4.2325

...is there some jiggery-pokery going on in terms of dividing through by 25.4 that is rounding the result to 3 places?

None that I can think of. The part was drawn natively imperial. Besides, the problem shows up on a single sloping surface, so that shouldn't have anything to do with it.

Finally, could this be a SolidWorks thing?

I seriously doubt it. Solid works has no problem making very fine details.



It sounds to me like internally SolidCAM is using high precision math, but when it spits out the raw data to the post module, it only puts out 3 digits.

[Brakeman Bob]

You were right to question, I followed my own thought process and found as you did that SolidCAM only offers 3 digit data to the post. When I tried it yesterday I saw the 4 digits in C and CC calls (Heidenhain equivalent of I's & J's and assumed that was it - 4 digit output not a problem. Probably a bug in R13 that hasn't been fixed yet. Ha! As my mate here says "Assumption is the mother of all cock-ups". I'll test a bit more before I type in future.

I'll have a chat with my support chap and see if he knows anything. I am still struggling believe that 4 digit output isn't possible.....

Have a good weekend

Bob

[mattpatt]

Bob, did you find anything out about this?

I've been making the molds for some of our latest carbon parts and I've found that the tighter the accuracy of the post then the better the finish on the part. The post is obviously a lot longer, but a small price to pay.

Example, I paid a few hundred quid for mold (acrylic I might add) a couple of years ago. I recently made the new mold myself (aluminium) and the parts popped out with a much nicer finish than the previous (contracted out) mold and I didn't even bother to polish mine.

I was particularly happy as it was the first mold of this type I had made. I had no real idea how to design it, and the guy that made the previous mold wouldn't tell me. But as I had originally modeled the part in Solidworks it was quite a straightforward process to design the mold, then tickle it a bit to how I wanted.

But anyway....yes....four digit output would be nice!

[Adam Hubert]

Can't believe you've had this very common problem this long.

I'm disappointed but not surprised that someone from SolidCAM support didn't immediately jump in and help you with this.

A missing or wrong setting in your *.mac file is causing this problem.

Fire up your mac file in a text editor and find the Epsilon settings area.

The below command needs to be there, or if already there it needs to be changed from the default value of 3 decimal place output to 4 decimal place output.

You have already experienced the fact that it makes no difference that your values in the gpp file are set as they should be 5.4. This movement_precision value in the *.mac file needs to be set to allow the 5.4 values in your gpp file to work.

The below value in the *.mac file is either not there which results in it defaulting to 3 decimal place output or the value is there and it's set on 3.

if movement_precision is there it's probably set like one of the following:

movement precision = 3 ; this forces 3 decimal place output in inch or metric
or movement precision = 0.000, 0.000 ; 1st value is metric, 2nd value is inch.

It needs to be either of the following

movement_precision = 4 ;forces 4 decimal place output in inch or metric
or movement_precision = 0.001 , 0.0001 ; equivalent to = 4 above

I can assure you that this will force it to post out with 4 decimal place output.

Another little gotcha may be there.

When your X, Y, and Z values change to 4 decimal place output that does not mean that your R (if you use R's), I, J, and K will also. They are controlled elsewhere.

In the largest portion of the the SolidCAM posts there is not an explicit definition of R, I, J, K in your *.gpp as there is X, Y, and Z.

The following in you gpp file will take care of the decimal output of your R, I, J, and K values.

in your GPP variables

numeric_def_f = '5.3' needs to be changed to '5.4'

the numeric_def setting is kind of a catch all that takes care of address values that are not explicitly defined.

Good Luck

[mattpatt]

Thanks Adam, that worked.

movement_precision = 4

Gives me output to 4 decimal places. Perfect

But....

movement_precision = 0.0001, 0.000004
or
movement_precision = 0.001, 0.00004

Will only output to three places. Not to worry, the first command works nicely.

Many thanks.

Matt.

[Adam Hubert]

Matt,

I knew this would work to get you 4 decimal places. This is very common in America that you work in 4 versus 3 decimal places. From a fundamental standpoint almost all of the controller axis position readouts on a normal mill and lathe are 4 places below the zero. I have seem this cause major grief to many of the users in the inch scene until knowing how to change this got worked out. Problems primarily were related to arcs errors and attempts to to do very fine 3D milling finishing that were erroring out or resulting in butt ugly 3D finishes.

This is something I always thought that SolidCAM handed very poorly as they began to put their product in the inch scene.

Something as critical as this just should not be hidden away and not documented to the point that you have to jump through these hoops to solve it.

[allenp]

Thanks Adam, that worked.

movement_precision = 4

Gives me output to 4 decimal places. Perfect

But....

movement_precision = 0.0001, 0.000004
or
movement_precision = 0.001, 0.00004

Will only output to three places. Not to worry, the first command works nicely.

Many thanks.

Matt.

guys I've got opposite problem, my postprocessor in solidcam is generating 4 decimal places movement precision numbers and my haas vf2 recognizes 3 digits of precision and when i transfer program to it, error occurs "bad number".

I've tried changing vmid file of my postprocessor under controller - movement precision to number 3 but that did not change number of digits.


please tell me how to change that or how to change haas to accept 4 digits precision numbers.

thanks

[Brakeman Bob]

guys I've got opposite problem, my postprocessor in solidcam is generating 4 decimal places movement precision numbers and my haas vf2 recognizes 3 digits of precision and when i transfer program to it, error occurs "bad number".

I've tried changing vmid file of my postprocessor under controller - movement precision to number 3 but that did not change number of digits.


please tell me how to change that or how to change haas to accept 4 digits precision numbers.

thanks

You need to edit your gpp file. Go to the section "@line and check out the xpos, ypos and zpos values for something like this

Xpos:xpos_f

Where the stuff after the colon is a declared string constant in @init_post. If it isn't there add this string to the positional variables not forgetting to put a colon between the variable and the string. If it is there, edit the declared string to look

'3/3.3z(pd)'

Take a look in the GPP help under "generating G code" for the full gen on display formatting

Sent from my SM-T550 using Tapatalk

[allenp]

thanks bob,
my solidcam post looks like this:

@line
; Handle GPP direct call to Line Movement (G01)
; We not use this procedure to output code
; We create our own procedure for this so that we may...
; Sync with @line, @line_5x, @line_4x, @line4x_polar, @line4x_cartesian
call @usr_line
endp

@usr_line
; Handle output for line movement (G01)
if bFeedoutput
change(feed) = true
bFeedoutput = false
endif
iMotionmode = 1
{nb,['G'iMotionmode:mcode_f ' '],['G'iMplane' '],['G'iDiametercomp' '],[cWo,iWorkoffset' '],['G'iAbsincmode ' ']}
{['D'iDiameteroffset' '],['X'xpos ' '],['Y'ypos ' '],['Z'zpos ' '],['F'feed ' ']}
change(cWo) = FALSE ;!@#$%AC Fix for ChangeBit Intermittent problem
endp

so there is no exact line which you mentioned, but there is this similar one so what should i do

[allenp]

found it!
it was in the beginning of the gpp file thanks brakeman bob!!