Messages

1241

General Mach Discussion / Re: Mach3, Delta ASDA-B2, ESS. 12 straight hours working on this. could use assist..

« on: January 25, 2021, 06:17:27 PM »

Hi,

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

1242

General Mach Discussion / Re: Mach3, Delta ASDA-B2, ESS. 12 straight hours working on this. could use assist..

« on: January 25, 2021, 05:18:17 AM »

Hi,

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

1243

General Mach Discussion / Re: Computer not talking to cutter

« on: January 25, 2021, 01:01:38 AM »

Hi,
1) What PC, desktop/laptop/Windows7/Windows10/32bit/64bit?
2) What motion controller...parallel port/external controller?
3) Does the Mach3 plugin match the controller you are using?

Craig

1244

General Mach Discussion / Re: Huanyang 3kw, Mach4 mb2 ess connections

« on: January 25, 2021, 12:53:50 AM »

Hi,
what model VFD?. Most of the early model Huanyang VFDs had a non standard MODBUS protocol,
there was a special plugin to allow the Mach3 Modbus module talk to and control them. I don't know
if there is a similar plugin for Mach4.

Most people get a MODBUS compliant VFD and be done with it.

There should be nothing stopping the analogue inputs from working though.

Can you get the VFD to turn on and off....not worrying about speed control here, just can you get the VFD to
start and stop?

If you put a 10k potentiometer between the 10V output and V_com and the wiper on AV can you control the speed?
I mean there's no point in trying to get Mach to control the speed unless you can control it with a pot....that would suggest a VFD
programming error.

Craig

1245

General Mach Discussion / Re: Mach3, Delta ASDA-B2, ESS. 12 straight hours working on this. could use assist..

« on: January 24, 2021, 11:47:40 PM »

Hi,

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.

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.

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

1246

General Mach Discussion / Re: Mach3, Delta ASDA-B2, ESS. 12 straight hours working on this. could use assist..

« on: January 24, 2021, 08:32:23 PM »

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

1247

General Mach Discussion / Re: Mach3, Delta ASDA-B2, ESS. 12 straight hours working on this. could use assist..

« on: January 24, 2021, 07:59:28 PM »

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

Craig

1248

General Mach Discussion / Re: Mach3, Delta ASDA-B2, ESS. 12 straight hours working on this. could use assist..

« on: January 24, 2021, 07:57:56 PM »

Hi,
the FollowingError is called 'Excessive Error Warning Condition' in the Delta manual and is parameter P2-35.

Craig

1249

General Mach Discussion / Re: Mach3, Delta ASDA-B2, ESS. 12 straight hours working on this. could use assist..

« on: January 24, 2021, 07:48:40 PM »

Hi,

First new question, is it acceptable to tie all the ALRM outputs (DO5+ & DO5-) from all the servos together as was the machine wired by the manufacturer?  I can't seem to find anything in the manual on this.  (only stuff on cascading inputs not outputs)  I.e. these are active-low outputs, so if, say two are high and one low, will the signal go low?

Yes, I think that would be permissible. I would however put a 50-100 Ohm resistor in series with each so that one sinking output does not current hog as is common
with BJTs. And.....Yes....if one (or more)  output goes low the signal will go low, and that constitutes a wired OR function.

I see no advantage in using WARN in preference to ALRM. In my previous post I explained that I was happy with what Mach4 does already so I'm not using the
Delta supplied EMGS DI at all, if Mach EStops then all step signals cease and therefore all servos stop. There may be subtle differences between EMGS and a Mach wide
EStop, things like is the servo still on, ie the state of SON but otherwise I'm happy with how Mach does it so I see no need to use the broadly equivalent Delta supplied
functions.

Note that if you use my suggestion and wire CN1-27 to COM- and one wire from CN1-28 (per servo) then all those wires can be combined (preferably with a 50-100 ohm resistor)
as wired OR, thus all your servo alarms  behave as one alarm.

I believe HPULSE is largely a PC to servo drive signalling mechanism, capable of MHz as opposed to plain line driving of 500kHz.

The B2 series has a 160,000 count per rev encoder, and with careful use of electronic gearing I have a solution that delivers 1um resolution (linear equivalent) and still allows
me to drive the servos to 5000rpm at 417kHz pulse rate. I do not need HPULSE so I didn't bother with it. If you had an A2 series or later with an 20 bit encoder, 1,280,000
count per rev, and you want even finer resolution than I require the HPLUSE would be the only viable signalling solution.

I have not experimented with it but I would suggest to you that signalling using HPULSE at low MHz rates, which is radio frequency, in a noise prone environment
is not likely to be easy. As it is, I was doing this over the Christmas break and I had no access to parts beyond what I had in stock. Thus I used what I had,
a dozen 300Mhz UnityGainBandwidth opamps, and made my own line drivers with them. As it turns out I can get my home brew line drivers to run at 3.5MHz driving
a 270pF line capacitance....so way WAY better than I need. I have experimented with my home brew line drivers and they work perfectly, I really see no need to invest
yet more time, energy and materials into an HPULSE signalling solution.....which will not yield any real benefits when using my mill. After all I want my mill to make chips....
not fly to the moon.

The short answer to your question is I did not use HPLUSE signalling because I did not need it and I suspect would take quite a bit of messing around to signal reliably
anyway.

Unless the load-to-motor inertia ratio is over 10-15 then self tuning should work fine. I have not experimented with my machine (still under construction) to even
know whether I could benefit from the notch filters for instance. Following error is not so much a tuning item as a machine accuracy parameter, and Delta can't set
that for you....you have to understand what it is and set it yourself to suit your machine.

Craig

1250

General Mach Discussion / Re: Mach3, Delta ASDA-B2, ESS. 12 straight hours working on this. could use assist..

« on: January 23, 2021, 03:18:28 PM »

Hi,
you are correct the manual I'm using has slightly different page numbers.

I'm using the line driver input pairs (37,39 and 41,43) but NOT the HighSpeed inputs (36,38 and 40,42).
The line driver inputs allow 500kHz signaling and yet I require 417kHz for my machine, so the 'plain' line driver inputs
are sufficient.

I have made circuit boards to interface between my BoB and the servo drives. I'll post a picture at a later date, I'm at home now and my machine
(under construction) is at work.

The wiring of CN1-11 and CN1-17 becomes clear in circuit diagram C9 on page 3-33. VDD (pin 17) is hooked to COM+ (pin 11) by a jumper in the plug.
All the digital inputs (DI's) become active low, per the example depicted in C9. In that particular case SON (servo on) is the DI depicted and if
pin 9 is pulled low (that is to COM-) then the servo is turned on. I'm using a transistor in my adaptor board to pull the input low.
Note that once you have wired pins 11 and 17 like this ALL DI's assume the same character. Thus the alarm reset signal, ARST, needs to be pulled
low, hence another transistor.

The two inputs, SON and ARST, in effect require three wires, one for each input, but also the COM- which establishes the 0V of the BoB/adaptor board
as the same potential as COM-.

But SON & ARST, on my machine nothing is connected and it works(?)

Yes, you can either hardwire SON to be permanently on, or program it to be permanently on, OR have a signal to it.....which is what I have done.
Its the norm in industrial practice to have a enable signal to each servo, and I have followed that practice, but its not strictly required.
If the servo never faults then you don't ever need to reset it and therefore ARST is not required. If the servo does fault and you need to reset it
in absence of a ARST signal you'll have to de-power then re-power the servo. I have elected to have a dedicated signal. On my Mach4 screen
I will have three LEDs indicating the fault status of each servo and a button to reset all of them.

Note that my controller has only one SON output and that enables ALL three servos. Also my controller has only one ARST signal an I'm applying
that to ALL three servos.

Each servo has its own fault signal however. If a servo faults I want to know which axis faulted, therefore combining all the fault signals together
would thwart that.

As far as the DO signal outputs. I have elected to wire CN1-27 to COM- CN1-14 and have just on wire attached to CN1-28 travelling back to my adaptor/BoB/
controller combination. You could as you say have two wires and therefore the transistor in the drive is isolated....but why? The transistor has
NO current limiting whether its isolated or not so the precaution about supplying external current limiting applies in either case. I elected a wiring scheme
that requires just one wire in the control cable rather than two, but that just a matter of preference. My scheme means that the DO is active low
which is symmetrical and 'philosophically' identical to my DIs, which is again my preference or 'style' if you will, rather than essential.

I was running a heavy roughing operation but within parameters that ran fine before - 6061-T6,  1/2" roughing mill, .2 RDOC, .5 ADOC, 20K RPM, forget exact chipload but it was reasonable, maybe .002".  My theory is a servo alarmed, but the servos being improperly connected to the cnc controller by the manufacturer caused it to continue feed instead of estop retracting and this greatly compounded the problem.  So sorry if I'm more than a little paranoid here.

A couple of things to consider here:
1) Limits. As you know the limits can be direct connected to the drive, and the drive is smart enough to stop but also prevent you from jogging even further
out of bounds to get the axis back. The drive could, if you program it, report the limit fault back to Mach and Mach could stop the other servos.
The other alternative, which seems simpler to me, and certainly more 'philosophically' familiar to me, is have the limit switches connected to Mach via the
BoB per normal and allow Mach to EStop all the servos.
2) Estop. You may have noticed there is a programmable DI called EMGS (CN1-30 by default) that if asserted will emergency stop the servo. You could wire your
machine such that if one EMGS is asserted it would stop ALL servos. I have not done so, for any particular reason, I'm quite happy with Machs EStop
arrangement as is. All my limit switches, the EStop panic button, the three servo alarm signals can individually set an EStop and the whole machine stops.

With regards the crash you had.....how have you setup the 'Following Error Window'?

A servo has a number of conditions where it faults, over-voltage, over-current and over-heat are usually immediate EStop conditions....but there are others
which are not immediate. Following Error is one.  You can program the drive to fault if the actual servo position deviates from its commanded
position by a certain amount, called Following Error. If the actual position deviates from commanded position then you will at least have an inaccurate
part but worse may be that one axis lags the other two and you end up with a crash.

When the drive comes from the factory the Following Error parameter is set very wide so that when you are tuning and setting up you do not get whole
bunch of nuisance trips. It is intended that you will narrow the window when you have tuned up. Have you done so? What may happen is that an axis
can lag 1/2 a revolution or so BEFORE an alarm condition is generated, but 1/2 a revolution could also mean CRASH.

Craig