[RCaffin]

some of my programs have hundreds of segments per inch.

That would be typical wood router territory? 5 million data points from a 3D map? I am not familiar with that class of program. I'll pass.
Instead I tend to go for engineering designs, where a 50 mm circle can be machined with one or two lines of code.

This does raise a point about lines/second. My CNC can only machine a few lines/second, as each line is quite long. It is possible that the PC could limit the machine speed IF it went through the PP. I use an ESS, which can turn lines/second into lines/millisecond. Having an external engine for the pulsing is so very helpful for speed. Mach, UCCNC and LinuxCNC (and others too I imagine) can all do this today. Here's to FPGAs!

Cheers
Roger

[ihavenofish]

I use an ESS, which can turn lines/second into lines/millisecond.

no, no it cant. the only thing that can do that is processing power and clever trajectory planner. pulses per second only determine how fast your motor can go. fpga dont do squat (when used this way anyway). the fastest contouring controls on the market right now can process about 2000 blocks per second. the typical control you might find on a new lower end vmc is around 50-200 blocks per second. theres no definitive numbers for mach or linuxcnc as the hardware is variable, but they should land somewhere in between.

on a metal milling machine, your bottleneck is usually mechanical. you can only cut metal so fast with the small tools used in these high definition programs. in wood, the bottleneck is block processing because you can pretty much cut as fast as the mechanical limits of the machine allow. a high definition 3d contouring program will hit the limits of most controls easily.

[daniellyall]

keep it to hobby, jerk control with CV is very interesting to set up, but having jerk control does make cornering a lot better, it's a differences you can hear more than see.

the other way is to get a good cam program that has corner rounding compensation, that makes Mach3 a lot better to use as you can set the speed to a speed you know the machine will be fine going around a corner. doing 3D cuts it makes it take a bit more time but the outcome is a lot better and less clean up work.

[OlfCNC]

There is no CAM program which will fix you the no deviation control and broken CV planner problem.

[daniellyall]

did I say fix NO, makes it BETTER batman will win

[OlfCNC]

The Mach3 trajectory planner is a black box so you can only assume it will make it better, in my experiences in 3D works using different CAM settings or milling strategies will mostly make no difference. It gives no solution or workaround.

[daniellyall]

I have used it and done it and it works well else why would I say it, if you drive mach3 slowly it goes around corners quite well, if you go fast it is crap at it so if you slow down then go around the corner then speed back up it makes it better ai.

all you have to do is find the speed that it corners ok, then you set that speed as the speed to use then it is better. and no it does not fix it how can it it lessons the problem with corners. I know how mach 3 trajectory planner works the man who did it explained it and what is wrong with it.
so that gives you what to do to minimize the problem

quite simple ai so spider man will get his arise kicked by captain america

[RCaffin]

There are several sorts of 3D machining. My interest is in the engineering style. Others may differ.

Attachment 321988
All these parts have been made by Mach3 for handling the connection to a propane/butane canister. You need some fairly high precision to avoid leaks. Leaks, near a flame, are embarrassing.

Attachment 321990
These parts are machined on all 6 sides and are also bored out in a complex manner, also by Mach3. Again, some precision is needed as they too are handling propane.

This is very different from making table legs or carving faces on a piece of wood. Yes, this engineering stuff can be done slower - in fact it needs to be done slower. Accuracy is not in question, but close tolerances and precision are essential. Mind you, I would imagine that UCCNC and LinuxCNC could do just as well.

Horses for courses?

Cheers
Roger

[G59]

I would imagine that UCCNC

I guess I'll never know. When installed it throws out unhandled exception and does'nt start.

Right o way, that turns me off. In this day and age a demo crashes. Win 7 64 bit. Come on................

[OlfCNC]

I'm running UCCNC around 6 months now on 2 machines, never threw an exception, never missed a beat, can't tell the same about Mach3, used it for a longer time.

[ger21]

You have an issue with your PC.
It's run for me on XP, 7, 8.1 and 10, with no problems.

[G59]

Attachment 321992

Details....................

See the end of this message for details on invoking
just-in-time (JIT) debugging instead of this dialog box.

************** Exception Text **************
System.AccessViolationException: Attempted to read or write protected memory. This is often an indication that other memory is corrupt.
at OpenTK.Platform.Windows.Functions.DescribePixelFor mat(IntPtr deviceContext, Int32 pixel, Int32 pfdSize, PixelFormatDescriptor& pixelFormat)
at OpenTK.Platform.Windows.WinGraphicsMode.ChoosePixe lFormatPFD(IntPtr device, GraphicsMode mode, AccelerationType requested_acceleration_type)
at OpenTK.Platform.Windows.WinGraphicsMode.SelectGrap hicsMode(ColorFormat color, Int32 depth, Int32 stencil, Int32 samples, ColorFormat accum, Int32 buffers, Boolean stereo)
at OpenTK.Platform.Windows.WinGLContext.SetGraphicsMo dePFD(WinGraphicsMode mode_selector, GraphicsMode mode, WinWindowInfo window)
at OpenTK.Platform.Windows.WinGLContext.TemporaryCont ext..ctor(INativeWindow native)
at OpenTK.Platform.Windows.WinGLContext..ctor(Graphic sMode format, WinWindowInfo window, IGraphicsContext sharedContext, Int32 major, Int32 minor, GraphicsContextFlags flags)
at OpenTK.Platform.Windows.WinFactory.CreateGLContext (GraphicsMode mode, IWindowInfo window, IGraphicsContext shareContext, Boolean directRendering, Int32 major, Int32 minor, GraphicsContextFlags flags)
at OpenTK.Graphics.GraphicsContext..ctor(GraphicsMode mode, IWindowInfo window, Int32 major, Int32 minor, GraphicsContextFlags flags)
at OpenTK.WinGLControl.CreateContext(Int32 major, Int32 minor, GraphicsContextFlags flags)
at OpenTK.GLControl.OnHandleCreated(EventArgs e)
at System.Windows.Forms.Control.WmCreate(Message& m)
at System.Windows.Forms.Control.WndProc(Message& m)
at System.Windows.Forms.ScrollableControl.WndProc(Mes sage& m)
at System.Windows.Forms.ContainerControl.WndProc(Mess age& m)
at System.Windows.Forms.UserControl.WndProc(Message& m)
at System.Windows.Forms.Control.ControlNativeWindow.O nMessage(Message& m)
at System.Windows.Forms.Control.ControlNativeWindow.W ndProc(Message& m)
at System.Windows.Forms.NativeWindow.Callback(IntPtr hWnd, Int32 msg, IntPtr wparam, IntPtr lparam)


************** Loaded Assemblies **************
mscorlib
Assembly Version: 2.0.0.0
Win32 Version: 2.0.50727.5420 (Win7SP1.050727-5400)
CodeBase: file:///C:/Windows/Microsoft.NET/Framework/v2.0.50727/mscorlib.dll
----------------------------------------
UCCNC
Assembly Version: 1.0.0.0
Win32 Version: 1.0.0.0
CodeBase: file:///C:/UCCNC/UCCNC.exe
----------------------------------------
System.Windows.Forms
Assembly Version: 2.0.0.0
Win32 Version: 2.0.50727.5420 (Win7SP1.050727-5400)
CodeBase: file:///C:/Windows/assembly/GAC_MSIL/System.Windows.Forms/2.0.0.0__b77a5c561934e089/System.Windows.Forms.dll
----------------------------------------
System
Assembly Version: 2.0.0.0
Win32 Version: 2.0.50727.5420 (Win7SP1.050727-5400)
CodeBase: file:///C:/Windows/assembly/GAC_MSIL/System/2.0.0.0__b77a5c561934e089/System.dll
----------------------------------------
System.Drawing
Assembly Version: 2.0.0.0
Win32 Version: 2.0.50727.5420 (Win7SP1.050727-5400)
CodeBase: file:///C:/Windows/assembly/GAC_MSIL/System.Drawing/2.0.0.0__b03f5f7f11d50a3a/System.Drawing.dll
----------------------------------------
OpenTK
Assembly Version: 1.1.0.0
Win32 Version: 1.1.1664.6217
CodeBase: file:///C:/UCCNC/OpenTK.DLL
----------------------------------------
癠䣿ᅯ鞎䃃�뿛
Assembly Version: 0.0.65535.65535
Win32 Version: 1.0.0.0
CodeBase: file:///C:/UCCNC/UCCNC.exe
----------------------------------------
OpenTK.GLControl
Assembly Version: 1.1.0.0
Win32 Version: 1.1.1664.6217
CodeBase: file:///C:/UCCNC/OpenTK.GLControl.DLL
----------------------------------------

************** JIT Debugging **************
To enable just-in-time (JIT) debugging, the .config file for this
application or computer (machine.config) must have the
jitDebugging value set in the system.windows.forms section.
The application must also be compiled with debugging
enabled.

For example:

<configuration>
<system.windows.forms jitDebugging="true" />
</configuration>

When JIT debugging is enabled, any unhandled exception
will be sent to the JIT debugger registered on the computer
rather than be handled by this dialog box.

[G59]

You have an issue with your PC.

Always something.........

[ger21]

Try updating your video card drivers. Looks like a graphics error.

[ihavenofish]

Try updating your video card drivers. Looks like a graphics error.

does seem to be yes.

[Jon.N.CNC]

A lot of it may come down to motion control, I was recently donated a 6040 and have put it the task of cutting foam tool control inserts. I have attached an image of two version, one cut by Mach 3 and another using same bob only plugging in a uc400 and using uccnc. The only difrence in toolpath is that radius are turned off in pp to support uccnc. I set the cv angle and distances the same in both Mach 3 and uccnc and the motor tuning the same. The rough version was Mach 3.

[Jon.N.CNC]

A lot of it may come down to motion control, I was recently donated a 6040 and have put it the task of cutting foam tool control inserts. I have attached an image of two version, one cut by Mach 3 and another using same bob only plugging in a uc400 and using uccnc. The only difrence in toolpath is that radius are turned off in pp to support uccnc. I set the cv angle and distances the same in both Mach 3 and uccnc and the motor tuning the same. The rough version was Mach 3.

For some reason I cant attach file on phone without replying with quote,

Images attached:

[RCaffin]

Interesting.
The left hand one looks as though it had CV off, but I know so little about foam cutting.
Were the total times and speeds the same?

Cheers
Roger

[Jon.N.CNC]

Interesting.
The left hand one looks as though it had CV off, but I know so little about foam cutting.
Were the total times and speeds the same?

Cheers
Roger

Nope settings were identical. Both took just over an hour, I didn't log the times stupidly but if there was any difrence it could have only been a minute or two. The motion control and tragectory planning of uc hardware and software smoothed motion considerably and i believe that is what can been seen.

Cutting foam is a pain, especially if cutting pockets as close together as I am in these. Have to treat it delicately and you have to employ both climb to rough and not clog the bit, and conventional to get a finish (use adaptive clearing if you get issues with standard pocketing pulling in foam). You can spot an error in the uccnc version on first stubby spanner where foam pulled into the bit even though same speed this didn't happen on rough version. So kind of things you have to deal with. Solution is go slightly slower.

[ihavenofish]

yeah theres something going on there thats not mach3 "accuracy". any so called path deviation in mach would if anything result in a smoother (but incorrect) shape. youve got something else going on there.

you are aware i assume that when you first instal mach, often times cv is explicitly disabled in the xml and isnt turned on by g64 in the program or by any setting in the setup page. theres one parameter that has to be changed (i cant remember which offhand, ive written about it on here before.

though even with cv off, thats bizarre, unless the machine is quite floppy with high acceleration and its just shaking to death.