[Davey Boy]

Hello Folks,
I am in the process of integrating Kmotion into a lathe style metal spinning machine I am building.

Until this week, I have been using Mach3 with a Smooth Stepper board and a C25 BOB. I have read various instances of Mach causing concern and having what appear to be bi-polar type control issues. Also the inability to customize some of the functions within Mach for my purposes is a problem.

The DynoMotion solution seems to be a more flexible and robust solution on all fronts, with the little issue of needing to know some C programming being a bit scary. I do have some programming experience with other similar languages and am confident that I can learn the necessary steps to achieve my goal. In fact, I found what seems to be a very in-depth C tutorial on the web this morning (400+ pages) and if others are interested, I will post a link to it.

I downloaded the Kmotion software in preparation for moving to that system (once I pass my credit card statement date ) and have been exploring. This morning I opened KnotionCNC and loaded one of my Gcode programs previously created with CamBam and run by Mach. When I hit the execute button, I got a message that the radius to the end of an arc differs from the radius to the start. I suspect that there is a rounding error (existing Gcode is 4 decimal places) and that Kmotion has detected this error. Is there a way to adjust the sensitivity within Kmotion, if this is what the problem is?

Thanks in advance.

[jthornton]

Silly question but why use Kmotion where you have to program in C when there is LinuxCNC where no programming is needed with the setup wizards. Even if you need to customize your configuration it is simple see spot run one line additions that if you ask on the LinuxCNC forum you can get all the help you need.

John

[Davey Boy]

John, I believe your question is a fair one, not silly at all.

More than twice over the past few years and as recently as two months ago I have tried the Linux system. Ubuntu was the most recent try and to be perfectly honest, I got tired of my computer locking up when it was least convenient.

If a computer could be totally devoted to such a system then perhaps it could be made more stable, but running Linux in a shell hasn't worked for me yet.

I need flexibility within my design and if it means learning which C code to cut and paste, I am willing to make that commitment.

[TomKerekes]

I got a message that the radius to the end of an arc differs from the radius to the start. I suspect that there is a rounding error (existing Gcode is 4 decimal places) and that Kmotion has detected this error. Is there a way to adjust the sensitivity within Kmotion, if this is what the problem is?

The radius tolerance variation is currently hard coded at 0.0005 inches and 0.005mm and hasn't been a problem. Is your GCode actually off by more than this?

In fact, I found what seems to be a very in-depth C tutorial on the web

Yes please post any good C references you find.



Here are some C reference links in a previous post:


Here are some videos:

Most of the on-line videos assume you will be running C on the PC where there is disk and keyboard and a PC based Compiler. KFLOP is a bit different environment but the basic C syntax of the language is the same. His videos that closely apply to KFLOP programs would be:

#3 Constants

#4 Operators

#5 Variables

#6 Outputting (printf)

#8 Conditions

#9 If statement

#10 if else

#11 if else if

#12 while loop

#13 for loop

#14 do while loop

#23 Functions

#24 Function Arguments

#25 Returning values

Regards

[Davey Boy]

The geometry was built with a CAD system using object snaps to line and arc endpoints, so I would expect it to be accurate. Any CAD I have used is typically calculated at around 17 decimal places, but I have to confirm that is the case here. I will see if I can open up the Gcode dimensions to another decimal place, but .0005 shouldn't be an issue (I am using inches).

This code has been run on Mach and produced parts previously.

The C reference is at:

www.iu.hio.no/~mark/CTutorial/C-Tut-4.02.pdf

Thank you for the links,
DB.

[jthornton]

John, I believe your question is a fair one, not silly at all.

More than twice over the past few years and as recently as two months ago I have tried the Linux system. Ubuntu was the most recent try and to be perfectly honest, I got tired of my computer locking up when it was least convenient.

If a computer could be totally devoted to such a system then perhaps it could be made more stable, but running Linux in a shell hasn't worked for me yet.

I need flexibility within my design and if it means learning which C code to cut and paste, I am willing to make that commitment.

Yea, to run a CNC machine in real time you need a dedicated computer. The Intel 525 motherboard is a current favorite and it sells for $80.

I'm not sure what you mean by installing in a shell... I do know of VM something but you can't run real time in it.

John

[TomKerekes]

Any CAD I have used is typically calculated at around 17 decimal places, but I have to confirm that is the case here.

It should be easy to look at the line of offending GCode and see if the error is in the GCode or not. The I J values determine the starting radius. But then to get the final radius the I J values must be added to the starting position (to get the center) and then subtract the final position. Maybe we have a bug or need to open up our allowed tolerance.

Thanks for the Link
Regards

[TomKerekes]

Yea, to run a CNC machine in real time you need a dedicated computer.

Our KFLOP controller unburdens the PC from the real-time activity so the restrictions on the PC are a lot less.

Regards

[Davey Boy]

It should be easy to look at the line of offending GCode and see if the error is in the GCode or not. The I J values determine the starting radius. But then to get the final radius the I J values must be added to the starting position (to get the center) and then subtract the final position. Maybe we have a bug or need to open up our allowed tolerance.

Thanks for the Link
Regards

It seems to be happening for each arc. Here is an example of the code...

G20 G90 G64 G40
T0 M6
( G2 Conv 10 )
G17
M3 S800
G0 X-0.1297 Y-6.5036
G1 F16.0 X-3.8559 Y-4.8536
G1 F6 X-3.945 Y-5.0069
G2 X-3.8329 Y-5.5008 I-4.3508 J-5.3587
G3 X-2.7549 Y-7.5021 I-0.9188 J-5.2222
G3 F16 X-3.7779 Y-5.4976 I-5.2977 J-7.5366
G3 F6 X-3.2864 Y-7.8038 I-1.0188 J-6.115
G3 F16 X-3.8096 Y-5.6093 I-5.9643 J-7.2827
G3 F6 X-3.7656 Y-8.0612 I-0.4167 J-6.7748
G3 X-3.8951 Y-5.9649 I-6.6486 J-7.1872
G3 X-4.2095 Y-8.2691 I1.2035 J-7.8341
G2 X-4.2928 Y-7.3956 I-2.3001 J-7.6463
G1 X-3.7808 Y-5.3781
G3 X-3.9455 Y-4.9988 I-4.2427 J-5.3533
G2 X-3.8363 Y-5.5133 I-4.3643 J-5.3565
G1 X-4.7361 Y-8.9342
G1 X-4.474 Y-9.0157
G1 X-0.1297 Y-6.5036
M5
M30

[Davey Boy]

Yea, to run a CNC machine in real time you need a dedicated computer. The Intel 525 motherboard is a current favorite and it sells for $80.

I'm not sure what you mean by installing in a shell... I do know of VM something but you can't run real time in it.

John

The computer will be dedicated to the machine, but it will also be used for other purposes when the machine is not active, such as producing Gcode from the CAD program.

My past experience has included fatal program crashes when the Linux system and the non-Linux programs fight for resources.

DB

[TomKerekes]

Hi DB,

The problem with the G Code arcs is that the arc center (IJ) is specified in absolute coordinates. KmotionCNC only accepts relative coordinates. Does your CAD system have an option for this?

Regards

[Davey Boy]

Hello Tom,

There is an option for relative or incremental coordinates. There was a problem using that method, the nature of which escapes me at the moment, so the programs were done in absolute mode.

Let me investigate further. I noticed the KmotionCNC screen has an absolute/relative selector. I guess that doesn't help?

Thanks,
DB.

[TomKerekes]

Hi DB,

The rel/abs setting on the screen corresponds to xyz positions (G90/G91). If you hover the mouse over it the tool tip will explain this. So no that wouldn't help. Another option is to use R instead of IJ and specify the Radius.

Regards,

[Davey Boy]

Hi Tom,

I have never seen an R option for Gcode, but I will see if it's available. The program paths are all based upon the imported probed profile of the die, which is itself based in absolute.

The Gcode geometry is created by offsetting probed surfaces and combining them with lines and arcs which are created by picking endpoints and in the case of an arc, dragging it until you achieve a proper "looking" curve - an arc dimension is never defined by giving it a keyboard, or input value.

I'm not sure how the code could be easily expressed in incremental (relative) terms, but I will investigate.

Thanks,
DB.

[Al_The_Man]

Something here on it.
G-Code Tutorial: Arcs With G02 and G03
Al.

[Davey Boy]

Very interesting!

Thanks Al. I will have to see if CamBam has that option.

DB

[Davey Boy]

It looks like I may need to write a new post processor for the CAD system. There doesn't seem to be an option to use radius as opposed to i & j. I'm not sure how I can integrate absolute lines with incremental rads, but I'll give it a go.

I tried changing the arcs to incremental mode but the result is a crazy arc that goes the wrong way, usually by way of the north pole by the looks of it!

[Davey Boy]

The problem with the G Code arcs is that the arc center (IJ) is specified in absolute coordinates. KmotionCNC only accepts relative coordinates.

Tom,

Do you have a Gcode spec that Kmotion uses that you can share? The CAD system I use to generate these programs claims their standard post processor conforms to "the RS274 NIST gcode specification as used by many common CNC controllers such as Mach3, EMC and USBCNC."

It allows me to set the arcs to relative mode, but when I try to set the lines to that mode, I get a message that only absolute is supported for lines.

There is the option to create a new post processor within the software, which it looks like is done in C or C++ (I can't tell the difference) :drowning: and I want to be sure that I don't introduce any more code that KmotionCNC doesn't like.

Thanks,
DB.

[Davey Boy]

I just had a scary thought as I was searching for solutions to questions I have regarding creating a Kmotion post for my Gcode generator...

Does Kmotion need the lines in relative mode too? If it does, I've got big problems since apparently the Gcode program creator doesn't support lines in relative mode!

Can someone clarify this for me?

Thanks.

[ger21]

Are you creating this with CamBam, or something else? All the code I've ever seen from CamBam used incremental IJ mode.

Does Kmotion need the lines in relative mode too?

The vast majority of CAM programs will output Absolute (G90) code with Incremental arcs by default. It's pretty much the standard that everyone uses.