Messages

1

Others / Re: Rhino: 2D path to g-code

« on: July 16, 2017, 03:51:13 AM »

There is no postprocessor. Gcode is generated during curve evaluation. If you want to customize something, open the rvb file in text editor and edit strings. If you need help with something specific, ask away.

2

Others / Re: Rhino: 2D path to g-code

« on: July 16, 2017, 03:24:21 AM »

Hi Dacicusan, I'll be very bussy 'til the end of september, and then I'll do some more work on these scripts (bugs and docs). Python conversion should be straightforward, and if I manage to re-eval latest version of rhino for testing (after 90 days plugins stop working), I'll try to do it.
cheers
m

3

Others / Re: Rhino: 2D path to g-code

« on: June 07, 2017, 11:55:39 AM »

You're welcome, I'm happy that you use them. I thought that options are self-explanatory, so I didn't write any instructions... I wrote some info for you (will do more later) and I've attached last versions of the scripts I use. There are still some bugs to work out (sort routines, HSM stuff) but they are usable if you're lucky or find a workarround - if you provide usable feedback, I'll fix them

In the meanwhile, if I can help you with something specific, please do ask.

Cheers
Mihael

4

Others / Re: Rhino: 2D path to g-code

« on: June 07, 2017, 07:07:32 AM »

yes

5

General Mach Discussion / Re: 1000 subrutines Limit ?

« on: June 19, 2016, 06:51:22 AM »

make subroutine call subroutine, for example one million calls (1000x1000):

M98 P1 L1000 (call from main program)
M30

O1 (sub that calls sub)
M98 P2 L1000
M99

O2 (sub that does the work)
... do work here...
M99

6

General Mach Discussion / Re: This GCODE make my cnc motor loosing steps

« on: September 12, 2015, 02:28:10 AM »

Hi,

I think that the answer to your questions may depend on version of mach3 you have installed (bugs).  Generally, mach3 honors motor tuning - you should not be able to jog faster than the motor is tuned(eg using shift key and cursors), but there were versions/configurations where people reported that mach3 jogs faster than tuned (v042.033 IIRC)

From my experience with v042.020: I was tuning servos for lowest possible following error, and there were few gcode samples that looked similar to your code (some shorter XY linear moves and arcs, then Z-axis only move, then longer XY move) where following error was doubled (in XY that I know of) somewhere around Z move. I had to reduce acceleration in motor tuning to get the machine to pass the test.  What I haven't tried, and it may have helped, is inserting a G4 P0 before and/or after Z axis only move.
I've also experienced some problems with feed override above 100% and G1 moves at feed rates close to limit, where machine would try to move faster than tuned, but I'm not sure which version of mach3 I was using at that time, and I learned not to do that anymore

I couldn't make much sense from the code you've posted, but the G01 Z2.5 is to be executed at F500, same as helical arcs before that Z move and the linear move after that Z move - does it actually execute faster ?

HTH
Mihael

7

Tangent Corner / Re: Machining Al-7075 and deformations

« on: September 08, 2015, 04:05:57 PM »

Thank you very much for your answer Rich. I have to machine the other side of the part, maybe it springs back

8

Tangent Corner / Machining Al-7075 and deformations

« on: September 08, 2015, 08:08:53 AM »

Hi,

can someone please suggest proper way to machine Al-7075-T651 alloy to minimize/avoid deformation?

Stock ~1000x70x25mm, was clamped to the 6 standoffs using one M6 screw per standoff, which were then clamped to the table. When I machined one side and released it from the table, the part was bent (~4mm about the middle of the part lengthwise).
I've attached some pics illustrating machining strategy and the result.
1. profile part using 6mm single flute carbide endmill, flute length 25mm (6/1/25 cem): DOC0.5mm, F3000mm/min, S13800rpm
2. clear ~550x70x8-10mm area in zig-zag pattern, using 6/1/17 cem, DOC8-10mm, WOC1mm, F875mm/min, S12000rpm
3. rough using 6/1/17 cem, climb only, waterline: DOC2-17mm, WOC,Feed and Speed variable too keep relatively constant MRR and the machine happy
4. finish using 6/3/18 cem, waterline climb in X direction + contour in Y direction combined, max DOC/WOC 2mm, step-over 0.1mm, F4000mm/min, S24000rpm
Material was never too hot to touch - it was warmest after #2 (and I suspect that was the problem). I used some WD40 on all cuts.

I've done similar parts in Al-6082-T6 ~800x80x25 and Al-6060-? ~800x70x20, using different roughing strategy (waterline 0.5mm DOC), different clamping method (normal clamps on top) and the parts turned out straight.

Thanx,
Mihael

9

VB and the development of wizards / Re: VB to change accel and de-accel for G0 and G1

« on: March 20, 2015, 04:29:43 PM »

Hi, I had similar idea, wanted to increase velocity and decrease acceleration for G0 moves and the other way arround for G1/G2/G3, but abandoned it without trying... Idea was to insert M command before each G0/1/2/3 containing SetParam commands for accel and velocity, something like:
M for rapid:
SetParam("VelocitiesX",10000)
SetParam("VelocitiesY",10000)
SetParam("VelocitiesZ",10000)
SetParam("AccelerationX",1000)
SetParam("AccelerationY",1000)
SetParam("AccelerationX",1000)
M for interpolation:
SetParam("VelocitiesX",6000)
SetParam("VelocitiesY",6000)
SetParam("VelocitiesZ",6000)
SetParam("AccelerationX",4000)
SetParam("AccelerationY",4000)
SetParam("AccelerationX",4000)
(check Mach3_V3.x_Macro_Prog_Ref.pdf, there's a link somewhere on the forum)

However, high acceleration will give you feed rate that is much closer to commanded one on short path segments, and if path consists of many small moves it may seem jerky if machine frequently changes direction... with low accel machine will not reach high feed rate on short segments so motion will be less jerky. Maybe you can just lower the feed rate for those parts of toolpath that contain small segments and solve your problem... I think that the only way to get that smooth movement with high feed rate over short segments is with S curve acceleration.

10

Brains Development / Re: DELTA-E VFD MODBUS BRAIN Help Needed

« on: February 26, 2015, 01:09:35 PM »

I'm glad you got it behaving

I suggest that you keep the brains for various VFD features in separate files. Once you got every feature working you can redo it in single file, if that's your preferred way.

To set the spindle speed, use the value from "Spin RPM - Ovrden DRO", this DRO contains actual commanded RPM including override. My spindle has max 24000RPM , and max freq 400Hz, so, for each Hz, RPM changes by 24000/400=60 - that's also my user-defined coefficient (p00.05) . To get frequency value from RPM, divide RPM by this coefficient. Frequency value for address/param 2001H can have two decimal places, so desired frequency should be multiplied by 100 to get the value that should be written. If you check my spindle speed brain, you'll see this formula (I think you can actually use that brain, just change the coefficient(60) to a value specific for your spindle).

I do not need to read actual spindle speed/freq from VFD - I've connected digital display to VFD with ribbon cable and mounted it outside the VFD enclosure, so I can see it. When I was thinking about doing it, I remember that there were some "logic" problems, so I just abandoned the whole idea.

I have two hints, first, check the Config/Spindle pulleys..., you can limit min/max RPM there (I have it set to min=4200,max=24000,ratio=1), and second, be careful when using "run from here", this feature does not execute S commands in g-code program (RPM will be read from DRO) and be sure to check "Start spindle" checkbox on "preparation move" form - it is unchecked by default (but once you check it, it stays checked).