Hello Guest it is March 29, 2024, 06:40:14 AM

Author Topic: Mach3, Delta ASDA-B2, ESS. 12 straight hours working on this. could use assist..  (Read 8290 times)

0 Members and 1 Guest are viewing this topic.

Hi,
and note the default setting of P2-35 is 480,000 encoder counts, that's three revolutions!!!!

Craig
'I enjoy sex at 73.....I live at 71 so its not too far to walk.'
Hi,
my servos are direct connected to 5mm pitch ballscrews, so if I leave the Excessive Error Warning Condition at its default of 480,000 counts or three
revolutions that is a linear equivalent of 15mm.

So the axis could lag by 15mm BEFORE the alarm was asserted. That's way WAY too much, I would expect my machine to fault 'Following Error'
at no more than 15um....not 15mm!

So I'm going to set my Excessive Error Warning Condition parameter to 480,000 / 1000 =480 counts. If that works OK and I don't get any/many
faults I'll try narrowing the window some more.

Just goes to show that you cannot leave this parameter at default......it will most likely be wildly different to what you actually require in practice.

Craig
'I enjoy sex at 73.....I live at 71 so its not too far to walk.'
Interesting.  For my purposes I don't think Excessive Error is an issue, at least as far as accuracy is concerned.  The machine is under high load (I assume inducing Excessive Error?) when roughing but I usually keep 0.05" off the part surface for this pass, then do a 2nd semi-rough to .02", then go to a surfacing technique to +0 using usually one pass.  Point being, the machine (servo error + frame spring) isn't under much load in the final passes when accuracy matters.  I do increase feed / reduce rpm to keep chipload up on final passes, but the apparent machine load is still relatively low.  A good thing to keep an eye on though, definitely.

In my (limited) experience his usually gets me to +/-0.0025" on flat surfaces but I'm getting tessellation artifacts on curves.  When I try to combat them by tightening my CAM tolerance it results in machine hitching, another thing I'm trying to combat by using a new controller.  I'm aiming to get tolerance to .001.  Not sure if it's lookahead controller CPU or link bandwidth bottleneck, but I guess that's a topic for a different thread.

Are you using the Delta ASDA software's 'scopes' functions for monitoring & tuning?  I still have a lot to learn about this.  Thinking of buying a cable for each driver so I can just monitor them all realtime, at least while tuning.

Anyway, like I said, my primary goal is to avoid repeating a crash situation where a servo alarms, releases the brake & shuts down, allowing the bit to get traction and suddenly rapidly feed into the material and the kinetic energy had nowhere to go, which I'm pretty sure is what happened.  LSTP (P1-32) was set to 00 on the servos which should have hit the servo brakes on alarm but this didn't happen for some reason, the servos were free to spin post-crash.  I can't explain this.  Do you have any ideas what might have happened?

Looking at the fault records (P4-01 thru P4-04), I see repeating fault codes 0003 (undervoltage), 0022 (input power phase loss).  Since all drivers are seeing the same errors, I surmise these are power on/off errors and can be safely ignored. (??)  Unfortunately any interesting fault codes from the crash have scrolled out of history and are lost.

Ok, I ordered a 1/2 watt resistor assortment pack, will probably just inline them on the cable.  Or at least take a look at current hogging current flow using a resistor as a temporary shunt.

Thanks again for the valuable advice, Craig.
Think twice before you G0 -Z...
So I'm going to set my Excessive Error Warning Condition parameter

FYI I was just looking at the ASDA software's scopes capabilities and it looks like you can monitor Position Error (PUU).
Think twice before you G0 -Z...
Hi,

Quote
Interesting.  For my purposes I don't think Excessive Error is an issue, at least as far as accuracy is concerned.

How can you possibly say that? If the Excessive Error Warning is set too high then the servo will lag a considerable distance
WITHOUT faulting. You must know and control that parameter, it is the most significant performance parameter of the whole
lot.

Excessive Error Warning Condition = Following Error.

If you nominate Excessive Error Warning Condition to be 100 then if the servo lags from its commanded position by 100/160,000 x360=0.225 degrees
or 13.5 arc min then the alarm is activated and your machine will shut down.

As an example: my machine has direct coupled 5mm ballscrews so the linear error of  100/160,000 x 5 =3.125um will cause the 0009 alarm to go off.

Having said that the fault record suggests that you are losing your  power supply, that's what fault codes 0003 and 0022 indicate.
How have you wired the input power......could excessive current be causing the power supply to 'brown out'?

I haven't used the oscilloscope function but I think you be expecting more that it can deliver. If my understanding is correct the scope can and indeed does monitor and
display following error but with a given range of input signals, steps, ramps etc. It does not follow general signals that you would encounter in a tool path or if it does
can display a few milliseconds worth at best.

Quote
Thinking of buying a cable for each driver so I can just monitor them all realtime, at least while tuning.

I don't think thats quite going to work. The data link is so slow that you cannot really hope to have a realtime scope. Its more for seeing how a servo responds to a test
signal, like a step change in position. Very useful for tuning parameters to adjust overshoot, oscillation and speed of response etc.

I have a data cable that allows me to program the drives. Do you not have one? I consider  it essential, trying to program a drive by pushing buttons like a microwave
is a nightmare and error prone. If you don't have a programming cable.....do yourself a favor and get one.

Quote
Ok, I ordered a 1/2 watt resistor assortment pack, will probably just inline them on the cable.  Or at least take a look at current hogging current flow using a resistor as a temporary shunt.

Just put the resistor inline in each of them, don't try any parallel resistances.

Craig
'I enjoy sex at 73.....I live at 71 so its not too far to walk.'
Sorry, it's late and I have to be at work tomorrow at 8AM so I have to be brief.

On Excessive Error, perhaps I'm misunderstanding or over-simplifying things.  My understanding comes from a background in Kalman Filters as implemented for stabilization & navigation in drones.  (My background these days involves a lot of drones, my home project is focused on building parts for really large drone prototypes)  I interpreted Excessive Error as being the delta between current state & desired state.  Why else would the default be so high?  My assumption is/was that if the driver is behind in steps, this is not a good thing but probably not fatal as long as it doesn't overcompensate in increasing feed rate in an attempt to catch up.  My guess (?) is that this might result in a stop short of the final desired move but little more.  And Excessive Error would primarily occur under high-load scenarios like roughing that would be compensated for in later passes.  Isn't this 'undershooting' is one of the things the 2nd rough pass targets before moving to finishing tools for a final pass?

You might be right about power supply.  My home machine is powered by residential single-phase 240AC wired directly the the main breaker panel.  I don't recall the gauge the electrician pulled, but it was overkill for 15/20A service.  I don't think I can improve the power situation for the machine.

My point on the scopes, I'm interested in getting a feel for the orders of magnitude for various dynamic parameters & perhaps some logging, not trying to react in realtime or anything like that.  For example, watching this Position Error as the machine is roughing.  But again I'm the n00b here, haven't even tried it yet.  I'd just like to get my material removal rates as high as I safely can, this seems to be a good way to get a feel for things besides just listening for spindle bogging.  The parts I run are big, roughly star-shaped so are problematic, they need a lot of material removed.  Even with aggressive params a part takes about 90 minutes per setup and there are two setups per part.  and I need to make a lot of these parts.

Yes, I have a cable...  Its been a long day I may be missing your points yet again, sorry if thats the case.  Thanks for the feedback will update this might take a day or two.
« Last Edit: January 25, 2021, 04:14:01 AM by machiavellian »
Think twice before you G0 -Z...
Hi,

Quote
I interpreted Excessive Error as being the delta between current state & desired state.  Why else would the default be so high?  My assumption is/was that if the driver is behind in steps, this is not a good thing but probably not fatal as long as it doesn't overcompensate in increasing feed rate in an attempt to catch up

That understanding is close. The servo drive enacts a closed loop trying to reduce the delta between the actual position and the commanded position.
If the servo is lagging the control loop will increase the drive current in order to catch up, if its leading the command the control loop will reduce or even
reverse the current to reduce the error. The position closed loop bandwidth is of the order of 500Hz and so the servo follows the commanded path with
plenty of'get up and go' and very quickly. This correction happens in milliseconds.

Ideally the servo would follow the commanded position exactly but inevitably it will lag a little behind. The Following Error Window, or Excessive Error Condition
as Delta call it, is the limit on the error before we decide that the machine has failed to follow the toolpath and the machine must EStop.

You may recall that when we used open loop steppers that if a stepper lost a step, or several, the machine would carry on assuming that the stepper was
following the correct toolpath despite the fact that it  is not, by virtue of those lost steps. We always wished that Mach would stop so we could correct
the lost steps rather than carry on making a bad part.  This is the meaning of Following Error....it allows us to program the 'number of steps gained/lost
before Mach Estops'

So to make accurate parts we want the Following Error Window to be a small as possible, and could therefore be assured that the machine is very closely following
the commanded path. If we make the window too small, then the servo will frequently slip just outside of the Following Error Window and fault out.
In order to have the servo follow a toolpath we wish that it have high acceleration, which is synonymous with torque, which is synonymous with current.
We also want the servos to rotate at high speed so that it may track a rapidly moving toolpath and speed in synonymous with applied voltage, given
that the applied voltage must overcome the back EMF.

A good means of measuring how hard a servo is working is to monitor its current. If the current is high its because its trying to accelerate to catch up.
A good means of measuring a servos speed is to monitor its applied voltage. Fortunately Delta has provided the means to monitor those
quantities as an analogue voltage. Thus you could have two meters which would monitor current and voltage in real time without a scope.
Would that be adequate?

The problem about trying to minimize cycle time is as much about good CAM and speeds and feeds as about servos. The idea is that you run the toolpath
but slowly increasing the feedrate (with the override) until the spindle is at some comfortable level short of max current. Having a toolpath that does not have
occasional short bursts of extremely heavy cutting is essential here, otherwise a heavy cutting event will occur on top of a high continuous load and the
spindle will overload and stall. You have to have good Gcode to do it.

Craig
'I enjoy sex at 73.....I live at 71 so its not too far to walk.'
Only have a few minutes but on my lunch I tried ganging the ALRM outputs on DO5 from the drivers together and they appear to be ANDing the output, not ORing them like I need.

I called the Delta technical support number (great idea suggested by a colleague!) and spoke with an excellent engineer about the question of whether this is valid and if not what to do about getting all DO's into a single PLC input.

The short version of the discussion is he suggested trying flipping the signaling to normally low (alarm pulls high), this should get the OR effect I'm looking for.  But he's going to get back to me with the 'official' (supported) way to accomplish this.  I'm going to try to get out in the garage-shop late tonight after work and give it a try.  Will post back if/when that happens & what Delta says.
Think twice before you G0 -Z...
Hi,

Quote
I tried ganging the ALRM outputs on DO5 from the drivers together and they appear to be ANDing the output, not ORing them like I need.

By ganging them together as I have suggested the ALRM signal is ACTIVE LOW. Thus with all alarms off the pull up resistor on the ganged terminal will
be high, whenever an ALRM goes low then the ganged signal will also go low.

Craig
'I enjoy sex at 73.....I live at 71 so its not too far to walk.'
Sorry about the delay.  Been a busy week.

FYI the recommendation from Delta Electronics is to wire the alarms together in series, just like you would fail-safe NC switches like home switches, etc.  In hindsight it's obvious (at least to me) this the correct circuit improvement, I should have seen this but got caught up in powering the circuit, etc.  I tested it, it works fine.  No parameter default overrides, nothing exotic required.

For those looking for the short answer on how to hook up servo alarms:  Just hook the alarms all in series, power with +24V, hook to an input and trigger active-low.

I've kind of come full-circle here, am back to considering adding the estop button to the circuit and calling that estop so the machine just retracts & stops on an alarm, no plugins, no brains, it just works.  On the other hand, it would be nice to somehow differentiate alarm vs. estop somehow so the (semi-intelligent) operator (me) doesn't just override an estop by hitting start twice.  Like I have in the past...

Craig, your thoughts?
Think twice before you G0 -Z...