Messages

1

Galil / Re: Plugin sets Encoder as type 12 (CE12), I need normal quadrature (CE0)

« on: October 08, 2013, 03:28:04 PM »

I got it going thanks to smurph.

I'll assume he won't mind if I cut'n paste his reply here since it might help someone else in the future. In the end, since I have two machines hooked up (a PC for Mach and another running galilsuite) over ethernet, I turned off mach and was able to update the CE values and burn it. Mach didn't clear it when it restarted. Yay!

Ken,

We don't change many of the values on the Galil.  About the only thing we do is MT (motor type) and the I/O config.  Otherwise, if you change something, you need to burn the value to the controller with the BN command.  Issue a CE0,0,0,0; BN to do this. 

I think what was happening was CE12 was burned into the controllers NV ram and when you ran the Galil plugin, we do a reset which put the NVRAM config back in place.  Because we never issue a CE command to the controller at all in the plugin.

For the Galil, 98% of the setup is done in the terminal using Galil commands.  PID values, etc...  Even the motor type should be setup in the Galil via MT and burned.  We allow changing the motor type and a few other things in the plugin, but that is more for testing.  The Galil plugin config and the NVRAM config really should match so that the plugin doesn't really change anything for a production system.  Because if the control gets reset, it really needs to come back up in a working config so that nothing unexpected happens. 

2

Galil / Plugin sets Encoder as type 12 (CE12), I need normal quadrature (CE0)

« on: October 04, 2013, 12:29:24 AM »

Hi, I just got everything working, but the plugin is forcing the encoder type as 12 (Reversed pulse and direction)

CE*=? returns

12, 12, 12, 12

Forcing CE to 0,0,0,0 doesn't work since it gets reset almost immediately back to 12s.

I don't see anywhere in the plugin where I can configure this.

3

General Mach Discussion / Re: Whose Fault Is ThIs?

« on: February 29, 2012, 06:47:50 PM »

Test it out on a sample code and it worked! Here's to crossing my fingers that the problems gone forever!

Odd. I have been using helical cutting and thread milling with CV for ages with the lock-down version. No problems at all.

Cheers

That would depend on your definition of ages! Also, you might not have noticed! The errors accumulated slowly. I only noticed when I was doing a very precise cut on a reflector mold!

Last time I tried it was 5 or 6 months ago and it still didn't work. If you look at when I posted, and the rest of the thread you'll see that the bugs always been around!

4

General Mach Discussion / Re: Dynamic Trajectory Distortion

« on: February 27, 2012, 12:51:27 PM »

It looks to me (without having seen your machine) that you're running into backlash.

5

General Mach Discussion / Re: Whose Fault Is ThIs?

« on: February 27, 2012, 12:42:58 PM »

Wow... Does that mean the one thats currently out?  Mach3 R3.043.058?

If so, you guys are moving to my new happy list.

6

General Mach Discussion / Re: Whose Fault Is ThIs?

« on: February 23, 2012, 02:26:46 AM »

Checking back in to harass ya guys that exact stop is not a solution

In fact helical ramp is critical to speed! I haven't been able to recommend mach to folks because of it.

Basically it kills thread milling, advanced troichiodal milling, cutting out reflectors, etc.

Please fix it as I'm forced to use software that has subpar user interfaces because of it.

7

General Mach Discussion / Re: Whose Fault Is ThIs?

« on: September 13, 2010, 02:06:55 AM »

Hmm, that makes sense, but if the only problem was acceleration, then it should put out the correct number of pulses, just very fast and it isn't. I put a nice counter on the Z axis step line and did a helical ramp and the count value was consistent but wrong. I would also think that in the case of an acceleration bug, it would "skip" steps only during the initial acceleration and I see consistent skips throughout the entire path, for example during thread milling.

During normal linear movements the counter indicates that mach is dead nuts accurate, during a helical ramp with all acceleration set to very safe and identical values, it is off by a thousandths or two, with acceleration of the ramp set to a different value, it has massive problems... surprisingly, if the arc center is (0,0) it behaves itself which is why I never caught the problem before starting a production run.

8

General Mach Discussion / Re: Whose Fault Is ThIs?

« on: September 13, 2010, 12:30:19 AM »

Thanks HimyKabibble, I looked into it myself looking for a workaround and the problem seems to be, from what I can tell from purely external testing, is that mach chops the less significant decimal points that don't fit in the DRO and works off that "massaged" value. This probably helps at the end of a move so you don't have weird ceiling/floor reversals as a response to commanded values, but for "advanced" moves such as a helical interpolation with Z component with differing acceleration, it has a tendency to accumulate errors. Basically rounding off the floating point numbers while within the iteration.

Personally, I could very easily deal with an "out of band" g-code command that says "Set acceleration to the slowest value for all axises" and another one that restores standard values. Or any workaround of that nature. Exact-stop by its very nature defeats the entire purpose of any operation that requires a helical ramp.

Here's to hoping for v4.

9

General Mach Discussion / Re: Whose Fault Is ThIs?

« on: September 12, 2010, 10:48:37 PM »

Nope... I've waited for months for a fix or workaround but at this point I've given up on Mach and am using EMC for now. Its a shame since I ended up buying a couple licenses for Mach before I found out that my parts were coming out
wonky. I'm just crossing my fingers and hoping that they'll fix it sometime in the next few years.

I've run into it during thread milling, Running the 4th and 5th axis, etc... The same bug affects other obnoxious places and everyone always says "It's not a bug its a feature OR just use exact stop" Neither of which are reasonable suggestions. It was while I was doing internal thread milling that I just said screw it and built an EMC box.

I've only seen very few mills that would optimally use the same acceleration for all axises. I have a Bridgeport CNC with the Elrod quill drive and ballscrews on all axises, and the X&Y can support a much greater acceleration than the quill.
AND the bug still exists if you set the acceleration the same, my system is running 0.0001 glass scales and I can still see the problem, it's just not catastrophically major if you don't care about a thousandth loss here or there.

Before people say it's my machine, Mach works great for everything else and EMC has no problems running the same code with no problems.

10

General Mach Discussion / Re: Whose Fault Is ThIs?

« on: February 13, 2010, 04:22:59 PM »

Hmm... thanks for the suggestion but that's really too bad  

The problem with exact stop is that it will definitely introduce a perceptible point of entry during the finish pass of the reflector. I absolutely needed to have it to have a consistant surface finish and so I even have the software compute the arc length during the ramp to change feedrate and spindle speed to create a consistent surface and also maintain an effective z plunge feedrate and the entry point.

As an added bonus, After I changed to code from a "plunge then pocket" per iteration to the helical ramp to pocket with a helical return to center turned a 45 minute job into 15 minutes.

The only thing I discovered was that as long as I keep at least one of the axises (axii?) of I/J at zero from out outset everything works peachy.

Any other workarounds or alternatives anyone can think of would be highly welcome.