Mechanoman

Im a bit confused about your A axis rotation. In my setup A20 rotates the axis 20 degrees, not 20 rotations.

Just FYI, I ran the machine A coords up into the 10's of millions so there is a lot of room there before you need to worry about zeroing it out.


Someting I sould recommend to anyone having stalling problems os to open the task manager in windoes and watch the perfomance monitor. If you get too close to 100% CPU utilization, you are going to stall. An interesting test is to grab the Task manager itself and just drag it quickly around the screen while your g-code is running. If you are marginal on processing power, that will put it over the edge and the motors will stall.

Another general tip: don't assume that because your computer can pass a driver test at 60,000 that it can run Mach successfully at that speed.
 

Im a bit confused about your A axis rotation. In my setup A20 rotates the axis 20 degrees, not 20 rotations.

You can configure it any way you want by changing the number of steps in a "unit".  For a direct-drive stepper with a 10x microstep driver, that would be 2000 steps per "inch" in the Motor Tuning.  In fact, IIRC it wasn'teven possible to accurately use degrees at all because that would be 5.55555555555555(repeating) steps per "inch" to get A1=1 deg. 
The 360 rollover will not work correctly unless A1=1deg.  But we have to disable that for lathing purposes because otherwise it is limited to one turn per line, and IIRC some problem existed even with the direction it was going to turn.

Just FYI, I ran the machine A coords up into the 10's of millions so there is a lot of room there before you need to worry about zeroing it out.

The bug will occur without the A-axis going into high values.  The zeroing is necessary to make the code readable and maintainable.

Someting I sould recommend to anyone having stalling problems os to open the task manager in windoes and watch the perfomance monitor. If you get too close to 100% CPU utilization, you are going to stall. An interesting test is to grab the Task manager itself and just drag it quickly around the screen while your g-code is running. If you are marginal on processing power, that will put it over the edge and the motors will stall. 

Another general tip: don't assume that because your computer can pass a driver test at 60,000 that it can run Mach successfully at that speed.

The A-motion-induced stall bug has NOTHING to do with processing power.  It can happen running at 25khz on the parallel.  It will happen at the same time on a SmoothStepper which has no processing limits.  In fact, if you DO exceed the processing limits with a SmoothStepper, the buffer underrun will be recognized and it will halt on that.

What it's clearly doing is having a math error and sending out a completely off-the-wall number for speed between two normal speeds.  The speeds requested were well within capability AND the difference in speed- acceleration- on the commands is very minimal.  There's nothing exceptional in the code.  The only way it could stall with a SmoothStepper is asking for pulses to create 5ipm one moment, then like -999ipm, them 5ipm: a glitch.  If I could snoop and record the bus or brain traffic I'd know better what it actually did.
 

It just seems to me that if you have A1 being a complete revolution, there is not much accuracy in your axis, but then I don't know what your objective is.

If I understand your comments correctly, you are saying that you are limited to one revolution per line of code? Why would that be?

If you're writing code for lathing with a lot of rotations, it is more readable to have A27= 27 rotations.  I guess I could write A[27*360] everywhere, but you can't even enter 5.5555555(repeating) into the pulses-per-inch field anyways because it's an irrational number.

Oh wait, NOW I remember.  I seem to recall that when fractions were entered into the Pulses-Per-Inch field, something about Mach3 broke badly.  5 would work.  6 would work.  5.55555... caused something horrible.  But I don't recall what.  Boogey Man reaches out and grabs your face?  No, I don't recall, but it did something totally erratic and inexplicable.

you are saying that you are limited to one revolution per line of code? Why would that be?

Because IIRC, if you DO use the Rot 360 Rollover in General Config, all entries into the A-field are interpreted as modulo 360.  So if you start at 0 deg, A3600  deg doesn't do 10 turns- it does zero.  Actually if you do A270 deg, it doesn't do 3/4 turn, it goes backwards 1/4 turn.  So I was wrong, it actually it limits each line to 1/2 turn.  This is not practical for lathing operations, a single move with 100 turns would have to be expanded into 200 lines.  Actually it's even worse because IIRC it wasn't clearly specified if a 180 deg turn was guaranteed to be performed going forward or backwards, so it might have to be expanded into 60 deg steps- 3 lines per turn- to clearly guarantee the turn direction.

I wish it would be that it rolled over the CURRENT position only, so A3600 is 10 turns in one direction and A-3600 is 10 turns in the other direction BUT at the end it would turn the A-DRO to 0 since 3600=0.  THAT makes sense.  Maintaining a DRO >+360 or <-360 on a rotary axis is nonsensical.  But wanting to rotate +3600 deg on a G1 move makes perfect sense.  Modding the end A-DRO value makes perfect sense. 

MechanoMan
 I have never had that stalling problem on my coil winder but then I only have one other axis other than the A. I have mine set as 1 rev being one unit.
With the other axis I had a step per unit being a repeating decimal, .33333333 or .66666666  if I remember correctly and still didnt have an issue.

Hood

Well it's not a solid problem where it never works.  Something like 1 out of 100 moves fail.  Your coil winder probably only has one big move, doesn't it?  It'd be unlikely to see.  A more significant profiling job with lots of little moves makes it likely.

One of the coils I do has 20,000 turns and that equates to 45 layers so the X axis is back and forth, have done over 50 of these particular ones. Also lots of others some with only 20 layers, some 10 and some only 4. Coils range from 45mm long to 500mm long.
Maybe it needs movement in more than two axis for the problem to show.
Hood

It doesn't require long movement, and long movement seems to be no more likely.  In fact, the problems I hit often seemed to be where there was a big A-rotation followed by a small one, such as where it backs the cutting head off the material but keeps turning.  And there were like 2 times when it happened specifically at the end of the code immediately before M5 (stop spindle), which was quite suspicious, but it also happened mid-code with no remarkable circumstances.

My theory is on a numeric integrity problem, where the acceleration or velocity is so low at one point in the calculation that a divisor got rounded to zero or simply got rounded to a point where it has harmful effects.  If any one axis runs into an acceleration or velocity limit from MT, then it has to scale all the steps on all axes to guarantee the specified move is followed.  And the feedrate is funky when we blend high A-rates with low XYZ rates.

Or it's having glitches due to, AFAIK, it's trying to make a vector sum out of X Y Z and A to compare to the Feedrate.  That's actually complete nonsense in reality.  When you specify F10 in an XY move, that limits the lateral cutting rate which directly sets the chip load and controls the bit stresses and degree of finish on the resulting cut.  On an X Y A move with A being a rotary axis, there's no telling what tool-vs-work velocity results from this command.  If the tool is far from the center of the A axis it is a high physical surface "feedrate" and if it's close then it's low.  So there's no way the code can actually generate a real surface feedrate off of this.  I think somewhere in the code it's confused as to what it's doing to implement this confused concept.

Hood,

It took a bit of dinking around with the macros and the A has to home pretty slowly in order to be repeatable, but I got everything working and ran a workout program in an endless loop for about an hour. So far, so good.

FWIW, Mach has a bug in it where it will occationally refuse to run a macro . .  or maybe it just does not like MY macros . . .     I used M950 for my 'unswap and home' macro. Sometimes Mach will just get stubborn and it goes past the macro but does not execute the code. Close Mach and reopen it and it's fine again. That's not good from a reliability standpoint, however, so far if I just start Mach and load and run a program with the macro in it, everything goes well.

MechanoMan,

I'm having a hard time seeing the purpose of using the 360 rollover if the objective is to have continuous rotation. It's your call, but in my opinion, you are just making a lot more work for yourself using a mode that seems unsuitable for your application. It seems to me that I saw a 'radius compensation' or similar parameter associated with rotary axis, but I haven't had time to go back and research it. The software obviously needs to know how big your part is in order to calculate meaningful feed rates on the A axis circumference. I had no trouble using repeating decimals for steps. Lastly, I do know there are math problems within Mach evidence by a rather severe sidestep at arc tangents when using tool comp. In my example .008 caused a significant side step, yet .009 was perfect.

My comment on computers was general and not directed at your particular issue. I will add, however, that if you are doing all of your trouble shooting on the same computer, assumming your stalls have nothing to do with the computer, you are mistaken. There are numerous examples on this forum of people changing computers and starting to have trouble or of changing computers and their problem disappears. I recently changed from an old dual 850mhz P3 server running Win2k to a Pentuim 1.6ghz running XP. The 'better' computer had constant lock-ups with Mach and all of the motors were stalling like crazy. That computer runs everythig else fine and has for years. It just doesn't like Mach AT ALL!  I'm back now on the old server, but I can't use the XBox controller unless I have XP, so  . . .






 

I'm having a hard time seeing the purpose of using the 360 rollover if the objective is to have continuous rotation. It's your call, but in my opinion, you are just making a lot more work for yourself using a mode that seems unsuitable for your application.

I had no trouble using repeating decimals for steps. Lastly, I do know there are math problems within Mach evidence by a rather severe sidestep at arc tangents when using tool comp. In my example .008 caused a significant side step, yet .009 was perfect.

I never said I really wanted to use Rot360Rollover, nor have I ever tried to use it.  I only said it had to be disabled because it's incompatible with the one-rot-per-A concept.  I only said it would be very useful IF it were coded completely differently than it currently is, to avoid the serious code writing and maintenance problems when using ever-increasing-A.  I cannot add a feature that uses 50 rots mid-code without having to manually add 50 to say all 100 code lines after that.  That's not very practical to code.

Actually ideally I wish I could put A alone in "Incremental" mode.  That would be nice!  But Incremental would affect all axes and it's even less practical to write the XYZ moves as Incremental.

A "repeating decimal" is an irrational number.  It's a fine point, but any number with a finite length you enter in that field is rational and thus not quite exactly the correct number.  It actually is possible for this to cause an accuracy problem, although specific circumstances have to be met.