Inaccurate feedrate

[Bohemund]

Sheesh, I thought you nailed it on that one. I went thru and editted all \73=100 in the startup.fil, gcode.fil, and macro.fil to read \73=143... all 33 places I changed.. And yes, it takes 85 seconds exactly to travel the 10 inch movement. Still no difference in speed.

I also do have a feed-rate slider on the CNC.EXE program interface. I varied that slider from 6% to 150%...no difference, so that isn't overriding my program speed...

*calling CamSoft*

[HuFlungDung]

I don't know if you've gotten around to inquiring from the Galil card, any of its settings. In cncsetup diagnostics window, you can send commands to the Galil card, I can't recall off the top of my head where the response comes back. Anyways, issue a command (in cnc professional) like
COMMAND TM n?

The card will return a response and by default, it should be 1000. If yours is out of wack, then perhaps it will return 1430 or something.

If you cannot see where the response comes back in camsoft diagnostics, then I would run the Galil terminal program and do the test there. Don't screw up your installation by installing Galil terminal program. I warned you

Let us know what the solution is

[Bohemund]

Talked with CamSoft...

After resetting my CBK to one they suggest, since I have the touchscreen model, I sent them my logfile.fil to them for analysis and awaiting their response.

Although I didn't solve my feedrate inaccuracy (yet), testing of my system with the CamSoft guy, I discovered by my replacing the 73 for 143 (and any number besides 73) in the CNCsetup program under the FEEDRATE variable disabled the sliderbar. So with my new CBK in effect with the new interface I can use my sliderbar to increase or decrease my feedrate, with 143% giving me exactly 10 IPM as indicated in a previous post.

[Bohemund]

After answering a few of Camsoft's questions, it's been determined that our lead configuration on our motors has (more than likely) caused the feedrate discrepency. Our motor user-manual instructs us to reduce current by 30% to reduce heat. The series configuration we're using gives us more torque at the low speeds we run our motors at.

It just so happens that the current reduction of 30% is the same % less distance travelled by our motors in my speedtests.

More on how we overcome that soon....

[HuFlungDung]

So these steppers somehow operate at a reduced speed because of reduced current? I thought a step was a step, but never thought about the time factor before.

Does the maximum current cut in only for rapid motion? If I were running a stepper, I would want full power for motion, and have the amp cut back when the motor is merely holding position. Having the current reduced all the time seems like a step backwards from a design standpoint.

[Karl_T]

So these steppers somehow operate at a reduced speed because of reduced current? I thought a step was a step, but never thought about the time factor before.
...

Hu, I don't see where he states stepper motors. I agreee, this wouldn't make sence for steppers.

In re-reading my posts, I see I've made a mistake on file extensions that has added confusion, sorry. The extension on startup is .FIL (not .ini)

You're not yet ready for this trick but I'll show you for the future (my way of explaining why I forgot the file extension)

Here's a screen shot of my control. I make the control window less than full screen. Then drag shortcut links from all the files that will need editing to the open area. No more wondering through the computer to get to them.

I just use Notepad as the editor (NO wordwrap). You must remember to close and restart CNC.exe for a change to take effect. AND you must go to CNCSetup to save your change to a .cbk

When you start refining logic, this shortcut saves a lot of time. Just click on the file and look at logic while the control is running. Make an edit, restart, evaluate.

Karl

[Bohemund]

We do indeed use stepper motors. We reduced the current to the motors as the manufacturer of the motors suggests for our lead configuration, so that's correct.

One thing I discovered, thanks to CamSoft support, is the need to remove the onscreen sliderbar that adjusts the feedrate. It seems that was overriding the increase in speed directive I was giving. After changing the \73=100 to \73=143 in the startup.fil I now go the proper speed with 2 axis activated.

With further tests another problem seems to have cropped up which may override the current reduction to the motors as the main problem...the more axis I have moving, the slower the motors go.

Just FYI I've been doing all these previous tests with 2 axis moving at once.

So...after doing further tests, I started from scratch with no modification to my speed, \73=100 again and using only 1 axis this time. With only 1 axis commanded to go, the single motor has travelled the correct speed, 10 inches takes 60 secs; with 2 axis, 85 secs like all my previous tests; and with 3 axis 104 secs.

We're using an ICM2900, an optical isolation device that feeds all 3 drivers, that may be causing a problem, not sure yet. We'll be calling the manufacturer of the unit to see if thats a typical occurance.

[Al_The_Man]

The ICM2900 Only provides isolation for the I/O, the analogue and the encoders are passed straight through.
Al.

[HuFlungDung]

Interesting.

Just to be clear on this, if you are doing 2 axis tests, and moving from X0Y0 to X10Y10, you are moving a distance of 14.14 inches and it should take longer than a single axis movement to X10 or Y10

[Bohemund]

*bonks self on head*

OMG how stupid of me. So it would seem everything has been working fine from the start with no problems whatsoever. I'm sure thats it. Only by revealing how my speed-tests were done were you guys able to solve this for me. It was so bad, I was starting to dream of motors and computers at night...lol.

THANK YOU!

I feel this may become one of those tricky textbook CNC problems somewhere if it isn't already.

[HuFlungDung]

[Karl_T]

The ICM2900 Only provides isolation for the I/O, the analogue and the encoders are passed straight through.
Al.

Al, Is there a version of Galil I/O boards that gives Opto Isolation on both Encoders and Analogue? The 1900 boards I'm using pass this thru also. I've thought this was an unavoidable weakness of Galil.

Karl