Messages

691

General Mach Discussion / Re: Constant Velocity problem with 4th axis

« on: April 13, 2010, 09:55:28 PM »

I believe you may be seeing the effects of a long-standing bug in Mach3.  If you have two axes in-motion, and then transition to a 3-axis move, the acceleration setting of that third axis will be ignored, and it will be expected (more like required) to accelerate at the same rate as X/Y.  This can be easily demonstrated by setting your Z axis accleration to a very low value, as compared to X and Y, then doing a move that transitions to a helical move in X/Y/Z.  The Z axis will lose position at the entry to the 3-axis move.  This is a known problem, and will be fixed someday, but it's not high on the priority list.  This gave me fits when my mill was capable of 3-- IPM on X & Y, but only 50 IPM on Z.  At present, the only work-around is to run in Exact Stop mode.  It would not surprise me a bit if there were a related problem occurring when moving a rotary axis in concert with linear axes.

Regards,
Ray L.

692

General Mach Discussion / Re: Mach3 4.0 Rev Update

« on: March 18, 2010, 11:07:23 PM »

Looks like Mach3 4.0  may miss its first anniversary party. 

Maybe....  But it'll be worth the wait....

Regards,
Ray L.

693

General Mach Discussion / Re: Tormach TTS Belleville Spring Washer Deflection (Not Force)

« on: March 16, 2010, 10:19:22 AM »

But, as I've just returned to work, following 19 months of unemployment, I have very little time to get out to the shop....

Good on ya, Ray!  I hope to be in that position myself really soon now (17 months and counting of unemployment for me...)

I think yours is the first motor-driven drawbar that I've heard of.  Scott_M over on CNCZone has a new handlever-operated hydraulic-force-multiplier TTS drawbar, but of course the Tormach doesn't have a quill...

Randy

Randy,

Yes, no quill makes it a LOT easier.  I wonder how that lever-operated one will wear with use.  There's a LOT of pressure on those little cams and levers.  It wouldn't surprise me if they wore and loosened up over time.  Very nice execution though!

Regards,
Ray L.

694

General Mach Discussion / Re: Tormach TTS Belleville Spring Washer Deflection (Not Force)

« on: March 15, 2010, 09:38:15 PM »

Ray, did you ever post pictures of your final configuration?

Randy

Randy,

Not really.  I abandoned the Belleville drawbar, because it just wasn't practical to get enough tension to properly hold a tool in a collet.  For a while, I used an impact wrench drawbar, but HATED the racket, and the wear on the drawbar and socket, so I removed it after a few months.  My "final" approach is a stepper motor with planetary gear reducer.  This will provide MORE than enough torque (up to 75 ft-lbs!), and allow the drawbar to be loosened just a few turns (for Tormach-style holders), or unscrewed completely, under software control.  But, as I've just returned to work, following 19 months of unemployment, I have very little time to get out to the shop.....

Regards,
Ray L.

695

General Mach Discussion / Re: Tormach TTS Belleville Spring Washer Deflection (Not Force)

« on: March 13, 2010, 03:55:11 PM »

0.100" is plenty.  0.050" will do it in most cases.

Regards,
Ray L.

696

General Mach Discussion / Re: Whose Fault Is ThIs?

« on: February 13, 2010, 10:05:53 AM »

Aaaargh!

I just ran into this bug!

Mach is losing steps in Z when doing a ramping helical interpolation in certain scenarios. It actually appears to handle arc center at X,Y of 0,0 just fine, but certain values of x & y causes it to lose steps... and it loses it exactly the same way and place every time.

I've attached a code segment that performs a finishing cleanup on a parabola which triggers the problem for me. Just to make sure I was sane, I put a digital counter on the z step pin and mach is simply not sending enough steps but it displays that it's in the correct position.

If I had to put money on it, whatever algorithm that was used to calculate the number/timing of Z step pulses during the ramping helical interpolation is running into either a casting or flooring issue.

Any time you run CV mode, and have a move in X/Y followed immediately by a helical move in X/Y/Z, you have the potential for the Z acceleration limit to be exceeded.  If X/Y/X all have the same acceleration capability, there should not be a problem, but if Z is less than X/Y, then its acceleration limit WILL be exceeeded, and it will probably lose steps as a result.  This has *always* been a  bug in Mach3, and has not yet been fixed.  The work-around is to run in exact stop mode.

Regards,
Ray L.

697

General Mach Discussion / Re: losing probe signals with USB game controller?

« on: February 08, 2010, 09:37:54 PM »

Is this  better?  From the Mach 3 wiki:


A frequent requirement is to have to wait for Mach3 when doing several commands, to keep them executing in order. The:

While IsMoving
Wend

Loop is the typical way of doing this.

ex:

code "G0X100"
While IsMoving()
Wend

However, this causes the system to make millions of calls to the subsystem to determine if Mach3 is finished. The CPU load rises terribly. A solution is to wait for 100ms or so each time you check unless you need a very tight response time. The solution is to use a syntax as follows..

Declare Sub Sleep Lib "Kernel32" (ByVal dwMilliseconds As Long)
.
.
.
Code "G0X100"
While ismoving()
Sleep 100
Wend

I suppose its somewhat moot, since this will go away in V4.

You are correct - you should *never* use:

While IsMoving()
Wend

Rather *always*

While IsMoving()
    Sleep(10)
Wend

The length of the Sleep is not important, but having a Sleep in there is important, to avoid wasting many, many CPU cycles.

Regards,
Ray L.

698

General Mach Discussion / Re: losing probe signals with USB game controller?

« on: February 08, 2010, 10:07:25 AM »

Could well be you know something I don't, but neither Art nor Brian has ever indicated to me that IsMoving() is a *guarantee* of a UI update.  In fact, on occasion, Brian has suggested using a delay.  Certainly, if the machine is idle, a delay of 2X the update rate *should* guarantee an update has occurred, as UI updates are regular, timed events, unless the machine is too busy running a program.  But, as I said, v4 will be FAR better in this respect.  It is a little ridiculous for user to have to worry about this kind of stuff.

Ray

I wouldn't presume to think such a thing and I'd absolutely agree with what you say Art & Brian have said and I don't think I've said anything to the contrary. In an ideal world of course it would be nice if the semaphore was accompanied by the called thread's success or error status but we can't have everything.

I think you'd agree that mult-threading is not unique to Mach and I've based what I've said on the assumption that Mach implements it in much the same way as any other multi-threading application - if not then I'd be intrigued to know how and why.

Certainly if a called thread is expected to complete after a particular time, then a wait by the calling thread for some period longer than that *should* give expected results. But when a semaphore is available, I would suggest that it is better practice to use it.

The only reason I can think of where a wait might be preferable, would be if there were some concern over the reliability of the code implementing the semaphore. Not that I'm suggesting this is the case with Mach of course.

Cheers

Ian

Ian,

I agree 100% about the use of semaphores.  But, one thing I've learned about Mach3 is that many features are not implemented anywhere near the way they "should" be.  Many are basically "hacks" that sorta-kinda work most of the time.  I've come across some real doozies where I can only scratch my head in disbelief.  This is why v4 is taking so long - Brian is working very hard to get that kind of stuff out, and the deeper he digs, the more he finds that just needs to be ripped out and re-done from the ground up.  He's already completely re-architected many whole major sections of Mach3.  v4 will be MUCH better in all respects.

Regards,
Ray L.

699

General Mach Discussion / Re: Prox Switches

« on: February 07, 2010, 08:06:38 PM »

Hi Ray:
Could you draw me a schematic of what you are referring to? Thanks.
Charlie

This problem is typically handled by putting a resistor in series with the 12V signal, to limit current into the BOB or PC.  Just limit the current to a few milliamps.  The resistor limits current flow from the 12V supply to the 5V supply of the PC or BOB.  A diode connected from the BOB input pin to its 5V supply ensures the voltage on the input pin cannot exceed the supply voltage.

You might want to take a look here:  http://cnc4pc.com/Tech_Docs/C11R9_3_USER_MANUAL.pdf starting on page 9....

Regards,
Ray L.

700

General Mach Discussion / Re: losing probe signals with USB game controller?

« on: February 07, 2010, 02:26:08 PM »

Other than potentially unnecessary delays in the scripts, do you know of any other impact V4 will have on scripts or addons?

Also, any idea about the target date for when v4 will be available?

v4 scripts will be almost completely different - almost nothing will carry over, unless you run in "legacy mode", in which case you will not get any of the benefits of all the v4 changes.  The v4 scripting environment will be a HUGE improvement over v3 - simpler, more consistent and predictable, but with greatly expanded functionality.  It will be much easier to learn, MUCH easier to use, and capable of doing many things v3 simply can't.

Regards,
Ray L.